6 ms·

A cartoon guide to Flux

198 points by snehesht 11y ago

cocoflunchy 11y ago
I haven't tried using Flux yet as I haven't really felt the need... Does anyone have insight on how to use it with React Native? Do you have a single action creator / dispatcher for your whole app? It feels messy since my screens in the app are usually pretty independent (but maybe I haven't written a complex enough app yet... hard to tell).
- cel1ne 11y ago
  Go for Redux instead: http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial.html http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial...
- kcorbitt 11y ago
  I recommend redux, like sibling commentor cel1ne. You should just use a single store for everything, as is recommended in the Redux docs, and then if a particular view of your app only needs a subset of all the data, just "connect" it to the subtree that's relevant using react-redux. I use it with React Native and it works great. Just be sure to use the react-redux instructions for React Native. The best thing about Redux (for me) is the ecosystem. There's tons of active development around middlewares (logging, persistence, routing, etc) and best practices. Its recent popularity means that you really can follow the beaten path and have a sane, performant app. EDIT: If you're interested in an example React Native/Redux app, you can check out the toy HN reader I'm working on[1]. There are some critical missing features that make it not yet effective as an HN reader, but it's a decent React Native for Android tech demo. [1]: https://github.com/corbt/HNReact https://github.com/corbt/HNReact
valisystem 11y ago
To those who don't want to be tied to a specialized library, you can architect an app like that way (unidirectional data flow) quite easily if you use KVO properly.
- myko 11y ago
  Is KVO common in JavaScript? I've only ever used it in the Cocoa realm.
  - debacle 11y ago
    IMHO a KVO programming style in JavaScript would be very error prone since there's no typing.
sktrdie 11y ago
Redux to me is the most exciting part of patterns like Flux. Specifically the idea of immutable state where to change the state you replace the current state with a new object. This allows to do really cool things such as undo/redo of actions. Check this simple video out to understand the power of Flux + immutable state: https://www.youtube.com/watch?v=jWq_3EH_mpg&feature=youtu.be https://www.youtube.com/watch?v=jWq_3EH_mpg&feature=youtu.be
- robmcm 11y ago
  > This allows to do really cool things such as undo/redo of actions. It makes it easier for sure, but undo/redo isn't dependent on immutability.
  - andy_ppp 11y ago
    It's much more complicated to build a system that can do undo without immutability IMO. Redux requires that you never mutate the global state object and things tends to be faster on large numbers of operations/clonings if you use something like Immutable.js.
    - deleted 11y ago
      [deleted]
    - gambler 11y ago
      You could store your state in DOM and serialize the entire page. Not very elegant, but it works and is relatively straightforward. Although, the mental leap required to represent your state via attributes is probably higher for most devs than even immutable data structures.
      - andy_ppp 11y ago
        Sounds prone to bugs and very slow to me.
TheAceOfHearts 11y ago
Another commenter mentioned it, but I'm going to +1 using Redux [0] as well. If you need to pick up a framework, Redux is a great choice to consider, it's tiny and very simple. It pushes you towards keeping a lot of your business logic as pure JS, so testing your code tends to be really easy (and it means your code is re-usable, it's not tied super tightly to X or Y framework!). If you use it with React it's also a joy to test. Something that Redux doesn't solve is data fetching, caching, and mutations. If you have a reasonably sized application, you'll end up having to implement a lot of logic surrounding data fetching and caching by yourself. The suggested solution is to store your resources normalized, indexed by id, and create selectors to get the data in the shape you want. This works out alright, but it's tedious and during your first few iterations on it you'll probably find yourself with a lot of boilerplate code. Facebook released Relay [1], which gives you the solution for data fetching and caching. If you give it a try, you'll be amazed by how much mental overhead simply disappears. You want data? You get it, that's it! But then your new problem is that you need a GraphQL server, and since it's a new technology that's not very mature (outside of Facebook at least), it means you'll have to do a reasonable amount of exploring. (I should really clarify that this is in no way the fault of the Facebook teams that put out Relay and GraphQL, both tools are amazing! It's simply that the ecosystems needs time to evolve and adapt.) I'd say that in one or two years from now a formidable amount of frontend app will be using some variation on Relay and GraphQL. [0] https://github.com/rackt/redux https://github.com/rackt/redux [1] https://facebook.github.io/relay/ https://facebook.github.io/relay/
- meowface 11y ago
  Is there any decent framework that combines the models used by these technologies all into one? It seems a bit unwieldy to have to juggle between React, Redux, and Relay, while also throwing GraphQL into the mix.
  - angeloashmore 11y ago
    Relay is basically the framework that brings everything together. Relay handles data fetching, storage, and mutations using a central store and GraphQL. If I'm understanding it correctly, Redux is replaced by Relay.
mpweiher 11y ago
You kind of had me at "Models pass data to the view layer." Those who don't understand MVC are bound to reinvent it...and invent fancy new names for it. EDIT: just in case it wasn't clear, not pushing data from the model to the view, but instead letting the view pull it from the model as needed is pretty much the core feature of MVC.
- jeremiep 11y ago
  That's not the issue. Whether its being pushed or pulled isn't relevant at all either. The issue is when your views start pushing changes to the models and you then jump into a recursive cascade of updates. This is the control-flow equivalent of letting a thousands ping-pong balls loose and trying to predict where each and every one of them will end up. I don't think its "MVC vs new fancy techs" as you make it sound but rather adding constraints to MVC in order to make it scale.
  - mpweiher 11y ago
    >The issue is when your views start pushing changes to the models and you then jump into a recursive cascade of updates. No. You can only get into a recursive cascade of updates if your model pushes changes to the views in response to changes occurring on the model. Otherwise the two are decoupled. In a typical MVC app, there are at least two phases: first you react to events and make updates to the model and send out change-notifications that invalidate those parts of the view(s) that represent the bits that have changed. In a second phase, you update the bits of the view(s) that were invalidated. Repeat. No update cycles, as long as you only invalidate in the first phase, and only repaint in the second phase. EDIT: The temptation is huge to "optimize" this process by having the invalidation notification do the actual work of repainting. That's where you get into trouble, you need to keep it decoupled.
mynegation 11y ago
On a high-level, I am still struggling to understand the real difference between two-way data flow and unidirectional data flow. Sure, it is actions, and dispatchers, and stores, but if you collapse them into one block, it is still two-way. What is possible with this setup that two-way data flow could not do?
- KurtMueller 11y ago
  Well, for one, you don't have to rely on observers/watchers anymore. You also don't have to pass functions back up scopes/templates/components. It's also really easy to keep your code organized (since data can only go one direction, in a big circle, it's much easer to follow the flow of logic).
JulianMorrison 11y ago
If you're willing to wait for JSON to schlep to the server and query updates to schlep back, using the change feed feature on RethinkDB gives you this with essentially no boilerplate. Your DB becomes the "dispatcher" and "store", write queries are "actions" and read queries (with change feeds) are the updates from the store to views. And your web page just displays the most recent state.
danvesma 11y ago
didn't get to the end, but your writing and graphic style are excellent and very readable
drinchev 11y ago
I still remember the first day when I decided to check out "Flux", I was googling for half a day, before I realise that it's "just an idea" how to manage your application flow. So far I'm using yahoo fluxible as an implementation and it works pretty well in my new isomorphic app.
findjashua 11y ago
I really like the philosophy of Redux (app state in a single object, pure components w only props, no state), but still think implementing this idea with observables would lend a couple extra benefits: 1. no magic or monkeypatching ( like connect does to container's props) 2. combine/merge make data dependencies much easier to reason about that a single node's state being updated by multiple 'case' statements. ps: as a poc, I put together a tiny snippet the other night (http://plnkr.co/edit/JIm88A7k7O0TCgfZ0O9f?p=preview http://plnkr.co/edit/JIm88A7k7O0TCgfZ0O9f?p=preview).

198 points by snehesht 11y ago

I haven't tried using Flux yet as I haven't really felt the need... Does anyone have insight on how to use it with React Native? Do you have a single action creator / dispatcher for your whole app? It feels messy since my screens in the app are usually pretty independent (but maybe I haven't written a complex enough app yet... hard to tell).

cel1ne 11y ago
Go for Redux instead: http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial.html http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial...
kcorbitt 11y ago
I recommend redux, like sibling commentor cel1ne. You should just use a single store for everything, as is recommended in the Redux docs, and then if a particular view of your app only needs a subset of all the data, just "connect" it to the subtree that's relevant using react-redux. I use it with React Native and it works great. Just be sure to use the react-redux instructions for React Native. The best thing about Redux (for me) is the ecosystem. There's tons of active development around middlewares (logging, persistence, routing, etc) and best practices. Its recent popularity means that you really can follow the beaten path and have a sane, performant app. EDIT: If you're interested in an example React Native/Redux app, you can check out the toy HN reader I'm working on[1]. There are some critical missing features that make it not yet effective as an HN reader, but it's a decent React Native for Android tech demo. [1]: https://github.com/corbt/HNReact https://github.com/corbt/HNReact

valisystem 11y ago

To those who don't want to be tied to a specialized library, you can architect an app like that way (unidirectional data flow) quite easily if you use KVO properly.

myko 11y ago
Is KVO common in JavaScript? I've only ever used it in the Cocoa realm.
- debacle 11y ago
  IMHO a KVO programming style in JavaScript would be very error prone since there's no typing.

sktrdie 11y ago

Redux to me is the most exciting part of patterns like Flux. Specifically the idea of immutable state where to change the state you replace the current state with a new object. This allows to do really cool things such as undo/redo of actions. Check this simple video out to understand the power of Flux + immutable state: https://www.youtube.com/watch?v=jWq_3EH_mpg&feature=youtu.be https://www.youtube.com/watch?v=jWq_3EH_mpg&feature=youtu.be

robmcm 11y ago
> This allows to do really cool things such as undo/redo of actions. It makes it easier for sure, but undo/redo isn't dependent on immutability.
- andy_ppp 11y ago
  It's much more complicated to build a system that can do undo without immutability IMO. Redux requires that you never mutate the global state object and things tends to be faster on large numbers of operations/clonings if you use something like Immutable.js.
  - deleted 11y ago
    [deleted]
  - gambler 11y ago
    You could store your state in DOM and serialize the entire page. Not very elegant, but it works and is relatively straightforward. Although, the mental leap required to represent your state via attributes is probably higher for most devs than even immutable data structures.
    - andy_ppp 11y ago
      Sounds prone to bugs and very slow to me.

TheAceOfHearts 11y ago

Another commenter mentioned it, but I'm going to +1 using Redux [0] as well. If you need to pick up a framework, Redux is a great choice to consider, it's tiny and very simple. It pushes you towards keeping a lot of your business logic as pure JS, so testing your code tends to be really easy (and it means your code is re-usable, it's not tied super tightly to X or Y framework!). If you use it with React it's also a joy to test. Something that Redux doesn't solve is data fetching, caching, and mutations. If you have a reasonably sized application, you'll end up having to implement a lot of logic surrounding data fetching and caching by yourself. The suggested solution is to store your resources normalized, indexed by id, and create selectors to get the data in the shape you want. This works out alright, but it's tedious and during your first few iterations on it you'll probably find yourself with a lot of boilerplate code. Facebook released Relay [1], which gives you the solution for data fetching and caching. If you give it a try, you'll be amazed by how much mental overhead simply disappears. You want data? You get it, that's it! But then your new problem is that you need a GraphQL server, and since it's a new technology that's not very mature (outside of Facebook at least), it means you'll have to do a reasonable amount of exploring. (I should really clarify that this is in no way the fault of the Facebook teams that put out Relay and GraphQL, both tools are amazing! It's simply that the ecosystems needs time to evolve and adapt.) I'd say that in one or two years from now a formidable amount of frontend app will be using some variation on Relay and GraphQL. [0] https://github.com/rackt/redux https://github.com/rackt/redux [1] https://facebook.github.io/relay/ https://facebook.github.io/relay/

meowface 11y ago
Is there any decent framework that combines the models used by these technologies all into one? It seems a bit unwieldy to have to juggle between React, Redux, and Relay, while also throwing GraphQL into the mix.
- angeloashmore 11y ago
  Relay is basically the framework that brings everything together. Relay handles data fetching, storage, and mutations using a central store and GraphQL. If I'm understanding it correctly, Redux is replaced by Relay.

mpweiher 11y ago

You kind of had me at "Models pass data to the view layer." Those who don't understand MVC are bound to reinvent it...and invent fancy new names for it. EDIT: just in case it wasn't clear, not pushing data from the model to the view, but instead letting the view pull it from the model as needed is pretty much the core feature of MVC.

jeremiep 11y ago
That's not the issue. Whether its being pushed or pulled isn't relevant at all either. The issue is when your views start pushing changes to the models and you then jump into a recursive cascade of updates. This is the control-flow equivalent of letting a thousands ping-pong balls loose and trying to predict where each and every one of them will end up. I don't think its "MVC vs new fancy techs" as you make it sound but rather adding constraints to MVC in order to make it scale.
- mpweiher 11y ago
  >The issue is when your views start pushing changes to the models and you then jump into a recursive cascade of updates. No. You can only get into a recursive cascade of updates if your model pushes changes to the views in response to changes occurring on the model. Otherwise the two are decoupled. In a typical MVC app, there are at least two phases: first you react to events and make updates to the model and send out change-notifications that invalidate those parts of the view(s) that represent the bits that have changed. In a second phase, you update the bits of the view(s) that were invalidated. Repeat. No update cycles, as long as you only invalidate in the first phase, and only repaint in the second phase. EDIT: The temptation is huge to "optimize" this process by having the invalidation notification do the actual work of repainting. That's where you get into trouble, you need to keep it decoupled.

mynegation 11y ago

On a high-level, I am still struggling to understand the real difference between two-way data flow and unidirectional data flow. Sure, it is actions, and dispatchers, and stores, but if you collapse them into one block, it is still two-way. What is possible with this setup that two-way data flow could not do?

KurtMueller 11y ago
Well, for one, you don't have to rely on observers/watchers anymore. You also don't have to pass functions back up scopes/templates/components. It's also really easy to keep your code organized (since data can only go one direction, in a big circle, it's much easer to follow the flow of logic).

JulianMorrison 11y ago

If you're willing to wait for JSON to schlep to the server and query updates to schlep back, using the change feed feature on RethinkDB gives you this with essentially no boilerplate. Your DB becomes the "dispatcher" and "store", write queries are "actions" and read queries (with change feeds) are the updates from the store to views. And your web page just displays the most recent state.

danvesma 11y ago

didn't get to the end, but your writing and graphic style are excellent and very readable

drinchev 11y ago

I still remember the first day when I decided to check out "Flux", I was googling for half a day, before I realise that it's "just an idea" how to manage your application flow. So far I'm using yahoo fluxible as an implementation and it works pretty well in my new isomorphic app.

findjashua 11y ago

I really like the philosophy of Redux (app state in a single object, pure components w only props, no state), but still think implementing this idea with observables would lend a couple extra benefits: 1. no magic or monkeypatching ( like connect does to container's props) 2. combine/merge make data dependencies much easier to reason about that a single node's state being updated by multiple 'case' statements. ps: as a poc, I put together a tiny snippet the other night (http://plnkr.co/edit/JIm88A7k7O0TCgfZ0O9f?p=preview http://plnkr.co/edit/JIm88A7k7O0TCgfZ0O9f?p=preview).