-
-
Notifications
You must be signed in to change notification settings - Fork 849
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
Improve Flow types #232
Improve Flow types #232
Conversation
53401cd
to
a3c4242
Compare
You shouldn't need to rebase, since you're not touching any of the same files as #231 |
@aleclarson, sweet! Let me know if there's anything else you need from me 😄 |
@mweststrate won't be maintaining much in the next 2 weeks, and we need him to review this PR. Therefore, I moved this PR to v1.7.5 instead of v1.7.4. |
fb96eda
to
2dcede1
Compare
The CI failed, I guess this still needs rebasing? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Flow type updates look correct to me, approved that part
- Build is failing, needs to be rebased on master?
- The changes in this MR are more than just the flow typings, was this PR based on a not-yet-merged branch? If so, we need to make sure that one get's first
@mweststrate This PR was put up before I removed failing tests from master with a rebase (naughty, I know). |
@mweststrate, thanks for the review! Rebasing now. |
a3c4242
to
204d3c5
Compare
@migueloller, some tests are failing in the CI. Probably locally as well. Could you look into this? |
@mweststrate, I spent a bit looking at the failing test and realized a few things.
I want to spend some more time to address these issues but I'm extremely busy with my day job at the moment. I will push new changes ASAP. |
Flow will now include warnings when running (i.e., unused supression comments). Flow will also fail if there are any warnings. This fixes broken Flow tests.
Adds better Flow support. Now, if the return type of the recipe never returns `undefined`, it can be guaranteed that `produce` won't return `undefined`. This allows compatibility with other types, like Redux's `Reducer` type. i.e., ```js type Reducer<S, A> = (S | void, A) => S declare var reducer: Reducer<State, Action> // This is now possible! Before it would fail, as the return type of // produce would be `State | void`. const initialState: State = produce(reducer)(undefined, action) ```
204d3c5
to
46d9db7
Compare
Merged into 3.0 branch |
Undid that :) |
Closing for inactivity |
Adds better Flow support. Now, if the return type of the recipe never returns
undefined
, it can be guaranteed that produce won't returnundefined
. This allows compatibility with other types, like Redux'sReducer
type.i.e.,