Open stratospark opened 8 years ago
Not sure if you saw redux-elm
examples using flow, you can find them in redux-elm-skeleton/examples-flow
Frankly, we are always using redux-elm
with Flow and we are getting pretty close to Elm compiling experience. Unfortunately, docs are already overcomplicated for some people and therefore involving Flow would simply be way too much.
But the idea is that people should use Flow
Anyway, back to your questions:
Exhaustive pattern match cases on the Updater/Reducer so we make sure to handle each type?
I've been trying to solve this for quite a long time since this would be super cool and unfortunately came to a conclusion that this is simply not possible (definitely not with some drawbacks).
Type checking the Views so that only explicitly declared Action types can be dispatched
That would be definitely cool too, and IMO also probably doable as we could potentially make view
wrapper generic - accepting action type union
...
So far, our support is limited to typed Models, we'd like to change this and support typed actions too - need to investigate more though.
+1 to including typed Actions in the way proposed in the tutorial!
@ryyppy could shed some light onto this, especially how much possible would it be to have type checked view
wrapper.
eg.
type IncrementAction = {
type: 'Increment'
};
type DecrementAction = {
type: 'Decrement'
};
type CounterActions = IncrementAction | DecrementAction;
const Counter : view<CounterActions> = view(({ dispatch }) => (
<div>
<button onClick={() => dispatch({ type: 'Increment' })}>Increment</button>
<button onClick={() => dispatch({ type: 'Decrement' })}>Decrement</button>
<button onClick={() => dispatch({ type: 'NonExistingAction' })}>Should raise an error</button>
</div>
));
I will have a look into that as soon as I find time this week... but I am sure there is an elegant solution. (also I wanted to take a look into your build system on how you distribute your flow types)
Okay, I kinda forget to do anything here, but there are currently some interesting flow PRs pending, making it very easy to create .js.flow
files of existing dist files (https://github.com/facebook/flow/pull/2184) ... also I was not sure how and when your major changes to this project will take effect (project renaming etc.). Any thoughts on that?
Doesn't make any sense to flow type stuff which is changed very soon anyways :-)
@ryyppy https://github.com/facebook/flow/pull/2184 is supercool, this will help us a lot with proper typing.
I am currently in the middle of quite complex rewrite and separation of concerns, so it would probably make sense to wait until version 3.x is released.
After major v4 rewrite, we have decided to re-write the library in TypeScript, so typings are also included and library should be fully-typed.
What are some other ways to take advantage of static types?
Are any of these possible?
I am trying to evaluate the state of Redux/Flow integration. I've seen this tutorial that provides stronger type checking: http://dchambers.github.io/articles/redux-flow-tutorial/. However, I see the value in the fractal components of redux-elm.