I'm using react quite a lot, but with my own API / storage solutions. So far I'm not really familiar with flux, and also with this, just quickly looking at it, I don't understand if/why I would need it. I can't really wrap my head around what exactly all this allows me to do and can't bring up the effort to read all the docs. I think I'll read more about flux first at some point, and if I'll ever want to use that, come back and check Marty :) Happy to see active react development though
Marty.js – A JavaScript library for state management in React applications
41–50 of 95 posts
Re: Marty.js – A JavaScript library for state management in React applications
#42This looks great. The docs really are terrific, too. Personally, I've been playing around with Bacon.js (or RxJS) instead of the Flux dispatcher. Using `Bacon.update` in conjunction with Facebook's Immutable.js seems really promising. The outcome is a far more functional approach. A quick and dirty example: https://gist.github.com/rattrayalex/dee40d86813bcaa9de80
Have you considered omniscient with Immutable.js? https://www.npmjs.com/package/omniscient
Last time I looked the combination of all of those frameworks is quite large (like 400k+ IIRC).
Re: Marty.js – A JavaScript library for state management in React applications
#43I'm using react quite a lot, but with my own API / storage solutions. So far I'm not really familiar with flux, and also with this, just quickly looking at it, I don't understand if/why I would need it. I can't really wrap my head around what exactly all this allows me to do and can't bring up the effort to read all the docs. I think I'll read more about flux first at some point, and if I'll ever want to use that, co…
If you haven't seen it yet, they have a nice Flux write-up in the docs: http://martyjs.org/guides/flux/index.html. (I apologize if you've already seen it, though.)
Re: Marty.js – A JavaScript library for state management in React applications
#44I'm using react quite a lot, but with my own API / storage solutions. So far I'm not really familiar with flux, and also with this, just quickly looking at it, I don't understand if/why I would need it. I can't really wrap my head around what exactly all this allows me to do and can't bring up the effort to read all the docs. I think I'll read more about flux first at some point, and if I'll ever want to use that, co…
In your typical React component, you'll keep state in the parent, and pass them down as props to the children's subtrees. You also have to pass down handlers (`handleNameChange` for example) along with the props so that the child components can change the state. These handlers travel back to the parent, modify the state there, which triggers a re-render, and that travels from the parent down all the way to all the children again. This works for most use cases.
This however forces you to keep all your model logic (computation, transformation, validation and server-communication) in the parent view component. So you'll extract a Model out of it, in which you keep all this data and logic. All the handler methods in the parent component would then call the mutation methods in this model instead of changing the component state directly. But now you need to ensure that the component state is consistent with the model state, for which you hook into the Model's onChange callback in the component's `componentDidMount` method. This means whenever the Model mutates, the component state changes accordingly. For example, if you have a `setPageTitle` method in the Store (that's what we call our Models in Flux), the store would mutate the value when `setPageTitle` is invoked, and call its own `emitChange` method, which triggers the `onChange` callback on the component which was registered during its `componentDidMount`.
See: https://github.com/facebook/flux/blob/master/examples/flux-c.... You use EventEmitter (I prefer EventEmitter3) on the Store to make it an observable. See: https://github.com/facebook/flux/blob/master/examples/flux-c....
The first step in Flux is this: a simple View-Model separation using an EventEmitter store. Apart from the View-Model separation, this lets you share global state between multiple components. (Global state is bad for programmers, but the real world doesn't care. There are instances where you need to share the same data between multiple components and have them all update automatically)
In the ThreadStore example I linked to above, the `emitChange` method is called only through the Dispatcher at the bottom. This is the next step: we do not let any component modify the store values directly. Everything is channeled through a uni-directional dispatcher. The reason to do this is to avoid one Store talking to another Store talking to another, and each of these causing cascading state changes in the components that observe them. So instead of having multiple intertwined paths to the Store, you force the entire application to go through a single-channel dispatcher that process each Action in sequence.
The Actions are simply constants that are available globally to invoke specific behaviour across one or many stores. Each Store watches out for the Actions (a constant pushed into its mesage bus) they are interested in, and calls the appropriate method in its body. You push the Actions into the dispatcher, who is responsible for sending it to each Store.
The dispatcher uses the same EventEmitter observable pattern to bind each Store to the actions they are interested in.
Written in a hurry, but I hope it helps. The flux-chat repo (https://github.com/facebook/flux/blob/master/examples/flux-c...) is a great place to understand the entire pattern.
Re: Marty.js – A JavaScript library for state management in React applications
#45I'm using react quite a lot, but with my own API / storage solutions. So far I'm not really familiar with flux, and also with this, just quickly looking at it, I don't understand if/why I would need it. I can't really wrap my head around what exactly all this allows me to do and can't bring up the effort to read all the docs. I think I'll read more about flux first at some point, and if I'll ever want to use that, co…
In your typical React component, you'll keep state in the parent, and pass them down as props to the children's subtrees. You also have to pass down handlers (`handleNameChange` for example) along with the props so that the child components can change the state. These handlers travel back to the parent, modify the state there, which triggers a re-render, and that travels from the parent down all the way to all the ch…
this is really helpful. I was looking for a short from-typical-react-to-flux-example compact enough to read through at once. I get it much better now, and actually I have already a framework with models with 'global' state and use react to visualise them and have been wondering what would be the best way to do this (copy the models data into state, or try to skip state and use the model data directly). So I guess I'll have to have a better look soon. Thank you for pulling me over the line
Re: Marty.js – A JavaScript library for state management in React applications
#46I like ReactJS, but I think Flux is overhyped. One-way dataflow is much better handled via RxJS or BaconJS and as with Om thru cursors. Writing stores and dispatchers and actions is a poor substitute for FRP.
Re: Marty.js – A JavaScript library for state management in React applications
#47Earlier quoted context omitted.
Hey, author here. This is a repeat of my answer below but it's right down the bottom so might be missed: I found that no other Flux implementation really helped with fetching data in a Fluxy way. There tended to be a lot of boiler plate code for binding stores to components. Furthermore, there was a lack of tooling for debugging. Marty helps combat these issues by introducing a number of new things: - Fetch API for f…
You're right about the boilerplate. I use a wrapper around React.createClass to take care of that. Kinda similar to Marty.createStateMixin, but it's just a component factory. The Chrome plugin looks very nice, but you can do the same thing with console.log() outputs in your store. It's a nice to have, but not filling a need for me.
> The Chrome plugin looks very nice, but you can do the same thing with console.log() outputs in your store.
by that logic, you don't need a debugger with breakpoints and stack traces either.
i mean... you could use a spoon for driving nails into wood instead of a hammer, too.
Re: Marty.js – A JavaScript library for state management in React applications
#48Nice documentation, and dev tools is a big plus. The beauty of flux + react is, it's so simple and flexible. I'm developing a fairly complex application with flux + react, (no flux frameworks, just facebook's dispatcher and stores/actions modelled after facebook's flux examples), and it seems I've implemented lots of things in marty.js. I also started using mixins for subscribing views to stores, immutable data in st…
Great comment and excellent intro to React for interested devs. I've been successfully using React for small and mid-sized apps, and agree that Marty looks like it's an elegant solution to the Flux pattern. (for application state in React, I've also had some success with passing around an immutable cursor, like react-cursor[1]). One cautionary note about how easy it is to integrate React with other frameworks: this s…
I discovered your react-d3 project last week and started using it a bit. Thanks a lot for making it.
Re: Marty.js – A JavaScript library for state management in React applications
#49Out of curiosity, for those of you building stuff with Flux: Which library do you use? Or do you just use your own implementation? We recently went with Reflux[1] for our first big React app after reading about it here[2], and I've been pretty happy with it so far. [1] https://github.com/spoike/refluxjs [2] https://reactjsnews.com/the-state-of-flux/
I'm leading a mid-sized project that is using RefluxJS. We're very happy with it.
Re: Marty.js – A JavaScript library for state management in React applications
#50This looks great. The docs really are terrific, too. Personally, I've been playing around with Bacon.js (or RxJS) instead of the Flux dispatcher. Using `Bacon.update` in conjunction with Facebook's Immutable.js seems really promising. The outcome is a far more functional approach. A quick and dirty example: https://gist.github.com/rattrayalex/dee40d86813bcaa9de80
Interesting use of a bus for each action. I'm curious why you used @setProps() instead of just storing the person object in the component state? Modifying props seems a like non "Reactish".