redux: Various small prep changes for multi-org support #5016

This doesn't have any callers.

This thunk action reportPresence is in much the same situation as most of our other thunk actions: it's meant to act on a single account's data; it acts on the active account's data; it has a bug where if the active account changes while its network request is pending, it can apply the response to the wrong account's data; and it can't do much if there is no logged-in active account. It had been unusual in that it checked at the top for a logged-in active account, and bailed out silently if there was none. That's because it's unusual in that it's called from a spot that starts operating before the user logs in, and keeps operating if they log out. But ever since we overhauled the presence-reporting code in 6efc449, that caller (PresenceHeartbeat) already checks whether there's a logged-in active account, and only invokes this action if there is. So it can go ahead and make that assumption exactly the same way that the bulk of our thunk actions do. That will simplify bringing it along with the rest when we make them act on a specific account they're dispatched for. Also add a couple of related notes for that future migration.

All of these are in per-account contexts: the main UI, or a server fetch (indeed the initial fetch.) None of them need the whole Account object. That object includes the API key, which is a good reason not to pass it around where we can avoid it; and it has both the user's identity on the server and miscellaneous bits like the server version, which might get rearranged to separate places in the future, so it's convenient to put those through separate indirections like getIdentity and getServerVersion.

This is really just an internal helper for sendOutbox -- the body of its retry loop.

I don't really know what this parameter means, so can't evaluate if false is the right value for it. The history doesn't seem to be enlightening; we've had it this way since early on. Also make the other argument `isActive` non-optional. The existing call site passes a value for it explicitly, and this will keep it that way.

These are all module-private helpers that get these parameter's types inferred from their callers. (Those callers ultimately get the types via ThunkAction.) We'll be changing the definition of ThunkAction, and it's helpful to have fewer redundant references that need to be updated at the same time.

We've just eliminated all the other references to this. We used to have them all over our thunk actions. We recently switched to annotating those with ThunkAction, and we've just gone and eliminated the remaining references, which were on thunk-action-like helpers.

This module hasn't needed a Redux `dispatch` since 543c07c, when we stopped using Redux for dispatching navigation actions. So, simplify by not taking one in the first place.

We haven't needed this since we upgraded off of react-navigation v1, in 98836b8 two years ago.

These are all bags of React props, so they should indeed be read-only object types.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

redux: Various small prep changes for multi-org support #5016

redux: Various small prep changes for multi-org support #5016

Commits on Sep 21, 2021