Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Anticipate and fix a few Flow errors we'd get with RN v0.63 and Flow 0.122. #4414

Merged
merged 6 commits into from
Jan 14, 2021

Conversation

chrisbobbe
Copy link
Contributor

On #4245, the issue for upgrading to React Native v0.63, I said:

Much of the work has already been done, but the new Flow version that we'll take along with it has lots of issues with our use of react-navigation, so I've been hoping to finish #4296 (for which #4300 is open) before taking up the RN upgrade again.

Well, #4296 has been resolved! As we'd hoped, the new Flow version (0.122.0) doesn't complain about anything that has to do with react-navigation anymore, which brings us closer to being able to take the Flow version along with RN v0.63.

This branch whittles down the new Flow version's output to the single warning below, with the helpful comment that we can remove a $FlowFixMe along with the upgrade.

Warning ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ src/presence/presenceReducer.js:30:9

Unused suppression comment.

     27│     case PRESENCE_RESPONSE:
     28│       return {
     29│         ...state,
     30│         // $FlowFixMe - Flow bug; should resolve in #4245
     31│         ...action.presence,
     32│       };
     33│

Copy link
Member

@gnprice gnprice left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great, thanks! One small suggestion -- otherwise please merge at will.

@@ -46,7 +46,7 @@ export default class SlideAnimationView extends PureComponent<Props, State> {
const { property, from, to, movement, style } = this.props;
const animationValue = this.state.animationIndex.interpolate({
inputRange: [0, 1],
outputRange: movement === 'out' ? [from, to] : [to, from],
outputRange: movement === 'out' ? ([from, to]: number[]) : ([to, from]: number[]),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this annotation be applied once to the whole expression? Would make it a bit shorter.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep! Thanks, done.

A built-in type called `Notification` [1] was being used here; we
should use our custom-defined one.

[1] https://github.com/facebook/flow/blob/v0.113.0/lib/dom.js#L4030
With the new Flow version (0.122.0) coming along with the React
Native v0.63 upgrade (zulip#4245), this would be flagged with a "Could
not decide which case to select" error.

I'm not sure why it has trouble distinguishing this array of strings
from a possible array of numbers, but it's simple enough to just
annotate it as an array of strings, so, might as well.
Similar to what we did in the previous commit.
Despite passing `undefined` as the `defaultValue` argument to
`React.createContext`, consumers will never see `undefined` as the
value for `this.context` or `useContext(TranslationContext)`.

That is, as long as `TranslationContext.Provider` is above such
consumers in the component hierarchy. From React's doc on
`createContext` [1],

"""
The `defaultValue` argument is **only** used when a component does
not have a matching Provider above it in the tree. This can be
helpful for testing components in isolation without wrapping them.
"""

Adding this annotation will satisfy the new version of Flow
(0.122.0) that we'll get along with the React Native v0.63 upgrade
(zulip#4245) soon.

[1] https://reactjs.org/docs/context.html#reactcreatecontext
This causes Flow to mark the `$FlowFixMe` on
`EventUpdateMessageAction.orig_subject?` as an "unused suppression
comment", so, remove it. In fact, I don't think a `$FlowFixMe`
really belongs here; there's no question that `orig_subject` is
sometimes missing, if only because private messages don't have
topics. The problem is in working out when it's there and when it's
not.

As I point out in the ongoing discussion [1] linked from that TODO,
there's a particular line [2] in the server code at current `master`
that I believe ensures that `update_message` events won't come to us
with an empty string for `orig_subject`.

[1] https://chat.zulip.org/#narrow/stream/206-zulip-terminal/topic/subject.20always.20present.20in.20event/near/1098954
[2] https://github.com/zulip/zulip/blob/08d716c74175a8b63bf8eb1080381c77f3f853c6/zerver/views/message_edit.py#L157
@chrisbobbe chrisbobbe merged commit e221fc1 into zulip:master Jan 14, 2021
@chrisbobbe
Copy link
Contributor Author

Thanks for the review! Merged.

@chrisbobbe chrisbobbe deleted the pr-fix-future-flow-errors branch April 20, 2021 15:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants