Problem described in ENG-2427.
Probably we want to investigate deeper, maybe there is no need for invariant in other usages of getStateFromNavigatorRoute - if yes I can create an issue.
Details
Invariant should not crash app in dev mode while ThreadScreenPruner is rendered but NavState wasn't fully propagated, e.g. because App Navigator isn't the top of the stack
Diff Detail
- Repository
- rCOMM Comm
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
I think PossiblyStaleRoute is not typed correctly... based on the Linear comment I seem to remember @kamil making, I think it was possible for state to not be set in some circumstances where our types think it must be set. We should fix this
This diff is still a good idea, but it should be forced by Flow types. Let's follow-up on that
native/chat/thread-screen-pruner.react.js | ||
---|---|---|
54–57 | This seems to be more or less equivalent to |
rebase
native/chat/thread-screen-pruner.react.js | ||
---|---|---|
54–57 | Definitely, but looks like flow has a different opinion than we do 😄 Cannot get chatRoute?.state because property state is missing in StaleLeafRoute [1]. [prop-missing] |
I thought putting an invariant here was a reasonable trade-off vs. refactoring the types in the fullStateSyncActionType payload (specifically StateSyncFullActionPayload which is derived from ClientFullStateSync which is derived from BaseFullStateSync) which are used across clients and keyserver.
Open to re-exploring if that would be preferred.