Skip to content

New Take on adding Flow Types #817

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

Closed
wants to merge 5 commits into from
Closed

Conversation

leoasis
Copy link
Contributor

@leoasis leoasis commented Sep 28, 2015

Alright, another take, but not yet complete :(

Here I mostly made the counter example work with flow types (even types for redux-thunk and react-redux, with some caveats).

I've opted for just moving on with type declaration modules instead of types in the redux src directly since I've had problems with the name_mapper flow option (more details on that particular line). When we solve that, and a couple more problems that hopefully we can all solve together, we can be ready to add Flow types to redux!

And if not, then it will be here for posterity to perhaps try again in a future Flow version.

Pending stuff here:



[options]
module.system=node
Copy link
Contributor Author

Choose a reason for hiding this comment

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

As you can see, I removed the line module.name_mapper='^\(redux\)$' -> '\1/src/index' and opted to continue with Flow declaration modules (the [libs] option) since that regex was conflicting with redux-thunk, and I was not able to create a regex that wouldn't stop that problem. If anyone can give this a try, or discuss approaches, let's start a thread here.


declare type Middleware<State, Dispatchable, DispatchableNext> = (api: MiddlewareAPI<State, Dispatchable>) => (next: Dispatch<DispatchableNext>) => Dispatch<Dispatchable>;

declare function applyMiddleware<State, Action, Dispatchable, DispatchableNext>(middleware: Middleware<State, Dispatchable, DispatchableNext>)
Copy link
Contributor

Choose a reason for hiding this comment

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

You'd need to call applyMiddleware many times to have several middleware while staying typed, right? Seems like a good enough compromise to me.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I can define a couple of overrides, was just testing with one (since the counter example just uses one middleware), but it should be possible to define multiple, as we discussed in the other thread (perhaps up to 5, 6 middleware functions)

@gaearon
Copy link
Contributor

gaearon commented Sep 29, 2015

Hey, thanks for your work on this again. I feel like we can get it right with three or four more iterations 😉 Can I ask you to write up a summary of the blocker issues in Flow that currently prevent us from finalizing this and recommending this setup to Flow users?

@@ -0,0 +1,32 @@
/* @flow */

import React, { Component, PropTypes } from 'react';

Choose a reason for hiding this comment

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

Why do you import PropTypes?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah forgot to remove this from the original example, thanks!

@leoasis
Copy link
Contributor Author

leoasis commented Sep 30, 2015

Currently the issues that are blocking us in Flow are:

The recommended setup for Flow users would be to include the module declaration files as part of their .flowconfig files (under the [libs] option). Those module declaration files should be included in each library (redux, react-redux, redux-thunk, etc)

In order to not forget to maintain these, it would be nice to type check the source code of the libraries internally and generate that declaration module, but that is currently not possible (facebook/flow#714). So I'm afraid this would be something to pay attention when changing the API of any lib :(.


React.render(
// Flow limitation: Does not detect children type if we don't explicitly
// set the `children` prop
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is being tracked here: facebook/flow#892

};
}

export default connect(mapStateToProps, mapDispatchToProps)(Counter);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Finally made this to type check!!! The $Diff type was working, the problem was that the correct flow type for classes that extend React.Component is ReactClass, so that it knows how to infer the polymorphic props and state types

@iamdustan
Copy link
Contributor

@leoasis have you looked at this more recently? I believe that the majority of those issues in flow has been fixed, in addition to the ability for flow to type check files in node_modules (files with .flow extensions)

@leoasis
Copy link
Contributor Author

leoasis commented Jan 11, 2016

@iamdustan no, haven't been able to, but will definitely try to take a look into it sometime soon. If interested, let me know and we can discuss what needs to be done to get this

@iamdustan
Copy link
Contributor

i definitely am interested, just not sure on current availability :(

@leoasis
Copy link
Contributor Author

leoasis commented Feb 25, 2016

If I could get back to this (or someone else), would you be willing to have the flow types directly in code if it were already possible? Or would you prefer to have them as external declaration files? What would you guys prefer?

@gaearon
Copy link
Contributor

gaearon commented Feb 25, 2016

I don’t care either way as long as we can meaningfully export them for consumers.

@iamdustan
Copy link
Contributor

If the source files are copied to the npm distro with .flow extensions flow will automatically pick them up. :)

@gaearon
Copy link
Contributor

gaearon commented Mar 6, 2016

I am closing for inactivity because this hasn’t been updated for quite a while.
If somebody wants to pick this up, please do, and open another pull request!

@gaearon gaearon closed this Mar 6, 2016
@jfrolich
Copy link

Interested in this as well!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants