Rebase

Rebase

Refactor the code

Make the logic a lot safer.

Rebase

Rebase

Fix eslint

Update effect cleanup function

Do not pass invite links to subchannels. Update return type to mixed.

Fetch all the fields

Add newline

Fix the light mode

In D7726#229991, @kamil wrote:

I think this is a bit vulnerable, we fetch all the links to the client - which means if the user is not part of a given community can get possession of the invite link and join the community when I think only members of the community should invite others. Fetching invite links to communities in which the user is a part will help.

Not a huge deal but I think worth improving.

Return only the invitations where a user is a member. Tested this by creating a new
community with a primary link - the endpoint doesn't return its link.

Rebase

Are you sure this is correct? Shouldn't we also convert a response from the server?

Use onFirstLaunch effect

In D7658#229577, @kamil wrote:

@tomek questions you added are valid but those are questions to the redux-persist author. I wanted to copy-paste code from source code to preserve old logic, as this returns function which will be used inside redux-persist logic. I only updated from the sync function which returns a promise - to implicitly return a promise from the async function (which will allow us to put await before any migration).

Any additional modification could cause some undefined behaviors, but if you feel strongly about investigating, I can try to improve this code in our use case.

In diffs like this a test plan has to contain a description of what you have done to make sure that all the necessary changes were made. Without this it is impossible to verify that all the changes are there.

Given the number of corner cases here, I think we should strongly consider moving to the overlay solution (referred as option 3). It seems like it might be cheaper than fixing the current approach, but what is more important, it is a lot more maintainable. The current solution requires having changes in a couple of places, and remembering about adding additional handlers when introducing some new routers / navigators.

Wondering if this is the best solution. How about having two separate storage engines, one with only db and one with redux storage? Then we could conditionally set one or the other, but each of them would be a lot simpler.

Should be ok both ways, but having a separate action is safer - the typesystem checks if all the required fields are set. And on native, not setting some fields, is probably an error state. We can also consider keeping one action but typing it safer, e.g.

+payload: {
  +platform: 'native'
  +currentUserID: ?string,
  +drafts: $ReadOnlyArray<ClientDBDraftInfo>,
  +messages: $ReadOnlyArray<ClientDBMessageInfo>,
  +threadStore: ThreadStore,
  +messageStoreThreads: $ReadOnlyArray<ClientDBThreadMessageInfo>,
} | {
  +platform: 'web'
  +currentUserID: ?string,
  +drafts: $ReadOnlyArray<ClientDBDraftInfo>,
}

I've left some comments with an alternative approach. Do you think it is more readable?

In D7641#227458, @ashoat wrote:

Sorry, this should have been explained in the diff. The main reason we're doing it this way are the issues in ENG-3252. Many of us (myself included) are currently unable to use the avatars feature because the request consistently times out when we open the app

I don't think this is the best approach - ideally, we should change feature flags configuration by setting the flag for everyone (with appropriate code versions) to true. The benefit is that if we discover a serious issue with the feature, we could quickly disable it. After it is hardcoded, we will have to release a new version for that purpose.

Thanks!