Marty.js – A JavaScript library for state management in React applications

Nice documentation, and dev tools is a big plus.<p>The beauty of flux + react is, it&#x27;s so simple and flexible.<p>I&#x27;m developing a fairly complex application with flux + react, (no flux frameworks, just facebook&#x27;s dispatcher and stores&#x2F;actions modelled after facebook&#x27;s flux examples), and it seems I&#x27;ve implemented lots of things in marty.js. I also started using mixins for subscribing views to stores, immutable data in stores (so undo&#x2F;redo is available without much work), loading data into stores from different sources etc.<p>I believe, in the following months, a de-facto flux framework will emerge, and marty looks so close to being that framework.<p>A few tips to fellow developers want to try react and&#x2F;or flux:<p>- React is just the view part. Integrating it with other frameworks is easy, and integrating other js libs with react is also easy.<p>- OTOH, if you want to build a whole complex app with react, use something like flux with it, since there isn&#x27;t a flexible way to modify the app state from child components with react.<p>- Immutable data structures really goes well with react + flux. I haven&#x27;t been able to get the immutability&#x2F;functional style before, and react + flux really helped with that.<p>Thanks again for the great tools.

I&#x27;m scanning the documentation for this now and the &quot;state sources&quot; concept looks useful. Stores seem to be a bit cleverer than in other Flux implementations too.<p>The fact it&#x27;s got a Chrome extension and what appears to be comprehensive documentation bodes well. I&#x27;m currently using reflux because I like its simplicity (no dispatcher and no action creators) but Marty has definitely piqued my interest.<p>Edit: Question for the author. Any thoughts on isomorphic apps with Marty? Edit2: Answering my own question: <a href="https://github.com/jhollingworth/marty/issues/13" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jhollingworth&#x2F;marty&#x2F;issues&#x2F;13</a>

One thing I would love to see some guidance on with Flux (and potentially with the patterns expressed in Marty.js) is how to handle the use case of Stores for a collection of items as well as a single item.<p>Right now, if I create a Store for a collection of Users and I want to be able to mutate these User objects then I create actions for each CRUD mutation and then plumb that change through to the in-memory object inside my collection as well as persist the change to my server.<p>But as soon as I click on a specific User and load up a new page for that User, for example, then I need to create an all new Store just for a single User, which has all of the same mutations&#x2F;actions available to it as the previously-mentioned collection Store (except now I don&#x27;t need to pass the ID to every action payload).<p>The best approach I&#x27;ve seen on this topic is in this example&#x27;s Readme: <a href="https://github.com/gaearon/flux-react-router-example" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;gaearon&#x2F;flux-react-router-example</a><p>Does this approach make sense&#x2F;jive with the Marty.js way of handling Stores, State Sources, etc?

Out of curiosity, for those of you building stuff with Flux: Which library do you use? Or do you just use your own implementation?<p>We recently went with Reflux[1] for our first big React app after reading about it here[2], and I&#x27;ve been pretty happy with it so far.<p>[1] <a href="https://github.com/spoike/refluxjs" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;spoike&#x2F;refluxjs</a><p>[2] <a href="https://reactjsnews.com/the-state-of-flux/" rel="nofollow">https:&#x2F;&#x2F;reactjsnews.com&#x2F;the-state-of-flux&#x2F;</a>

This looks great. The docs really are terrific, too.<p>Personally, I&#x27;ve been playing around with Bacon.js (or RxJS) instead of the Flux dispatcher. Using `Bacon.update` in conjunction with Facebook&#x27;s Immutable.js seems really promising. The outcome is a far more functional approach.<p>A quick and dirty example: <a href="https://gist.github.com/rattrayalex/dee40d86813bcaa9de80" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;rattrayalex&#x2F;dee40d86813bcaa9de80</a>

I&#x27;m using react quite a lot, but with my own API &#x2F; storage solutions. So far I&#x27;m not really familiar with flux, and also with this, just quickly looking at it, I don&#x27;t understand if&#x2F;why I would need it. I can&#x27;t really wrap my head around what exactly all this allows me to do and can&#x27;t bring up the effort to read all the docs. I think I&#x27;ll read more about flux first at some point, and if I&#x27;ll ever want to use that, come back and check Marty :) Happy to see active react development though

This looks to be a well-put-together implementation of flux. I recently looked over around 20 or so flux libraries to use for a react app I had started, and found only a couple that I liked. I would put this one near the top, but the one I ended up choosing has been <i>great</i>, but no one seems to know about it!<p>If anyone is interested: <a href="https://github.com/kjda/ReactFlux" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;kjda&#x2F;ReactFlux</a><p>It&#x27;s very similar, but I think I like how Actions and subscriptions to actions are handled with it better.

In Marty: since you attach a Store to a React via a Mixin that looks for a singleton, can you have a dynamic number of stores when you have a dynamic number of React components of the same type?

I&#x27;ve contributed to this project on the state sources.<p>For me Marty is the best Flux implementation available right now. When reviewing other frameworks I found them to be either too restrictive by imposing non-flux limitations or the complete opposite by not implementing the flux principles well enough.

I&#x27;ve been using fynx[1], and it seems to work for me so far.<p>What attracted me to fynx was that it uses Facebook&#x27;s immutable-js[2] for its stores.<p>It would be nice to get an updated version of this comparison of available flux libraries[3].<p>1: <a href="http://foss-haas.github.io/fynx/" rel="nofollow">http:&#x2F;&#x2F;foss-haas.github.io&#x2F;fynx&#x2F;</a> 2: <a href="https://github.com/facebook/immutable-js" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;facebook&#x2F;immutable-js</a> 3: <a href="https://reactjsnews.com/the-state-of-flux/" rel="nofollow">https:&#x2F;&#x2F;reactjsnews.com&#x2F;the-state-of-flux&#x2F;</a>

This seems very similar to Fluxxor, but solves some of the pain points.<p>Stores need to be extendable, and the Mixin concept (as used in React Elements) are a very useful way to do it. In this way, one can easily implement Marty&#x27;s &quot;State Sources&quot; concept. I released a fork of Fluxxor a while ago with Mixin support [1] but it is unlikely to make it until 2.0.<p>The other nice parts to my eyes are:<p>State Mixins - sort of a hybrid between Fluxxor&#x27;s StoreWatchMixin and Fluxxor-autobind [2]<p>Constants - This is a new one, I like it. Will have to play with it to see if it truly solves any problems; I&#x27;ve found that when I need to know what actions are available, I scan my actions files, simple as that.<p>Marty seems a little more &quot;batteries included&quot; than the other Flux implementations on the scene. This is a good thing, so long as it is easy to extend. Unfortunately I still don&#x27;t see Mixins in Marty Stores either. In my opinion they are required for non-trivial apps.<p>1. <a href="https://github.com/STRML/fluxxor/tree/storeMixins" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;STRML&#x2F;fluxxor&#x2F;tree&#x2F;storeMixins</a><p>2. <a href="https://github.com/STRML/fluxxor-autobind" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;STRML&#x2F;fluxxor-autobind</a>

Nice documentation. But I don&#x27;t see anything groundbreaking here. The whole rationale for Flux is to unidirectional state flow, and it does that quite well. A lot of library creators have focused on the tiny quibbles with &quot;ease of use&quot; around stores and constants –– &quot;state management&quot; is a good euphemism for this need –– but that&#x27;s not really a bottleneck for me. I can manage my constants manually with Flux, and add listeners myself. If I need to indicate a dependency between to stores, I can use a waitFor in the switch&#x2F;case block. It&#x27;s that simple. Why should I learn a bunch of abstractions that make only an incremental difference?<p>My only pet peeve with Flux is that it does not let me dispatch from within an ongoing dispatch, which is not a huge deal yet because you can just defer the callback to the next event loop, but it&#x27;s not allowing me to pipeline actions as I thought it should. I have to wait for the stack to empty out before I can dispatch a new action, which sucks. Also, there is no indication as to when a dispatch is over, so I am deferring dispatches by instinct –– or wrapping them in a promise might be the same thing.

Even if HN readers are getting tired of all the new &quot;Javascript librairie de jour&quot;, it&#x27;s really exciting to see how new techniques are refined and improved in a fast tempo. Keep them libraries coming!

I really want to use React in my next application, but I&#x27;m lost on how to do visual things like animation (like a carousel), drag-drop, typeahead.<p>Do you have any suggestion on the best practice on doing those heavy DOM stuff in React?<p>I know I can use jQuery for that, but it feels wrong to me.<p>Also how do you handle integrating React with command based JS library, where your only interface to it is to call mutating functions, such that you cannot blindly rerender the whole things.<p>Suggestions on these two issues would help me greatly.

In <a href="http://martyjs.org/guides/flux/index.html" rel="nofollow">http:&#x2F;&#x2F;martyjs.org&#x2F;guides&#x2F;flux&#x2F;index.html</a> it says<p>&gt; thanks to action types being strings you have a loosely coupled Law of Demeter architecture which is easy to grow without increasing the complexity of the code base.<p>I don&#x27;t see the connection between cause and effect, unless this is saying &quot;since everything is in the global state there is no coupling&quot;. Seems odd.

This looks really neat, and the documentation does seem nice. What I would absolutely <i>love</i> (and I&#x27;m sure many others as well) is a tutorial that shows how to build a very simple app from scratch... like a list of records and then click on a record to bring up an edit form (something super basic, but a tad more complex than TodoMVC). The problem I have is wrapping my head around how I put all the pieces together. Thanks!

I hope all the virtual-DOM based library comes to concensus with one based virtual-DOM library, or that it becomes part of the browser standard.<p>I don&#x27;t mean the whole React library, I mean just &quot;this a the DOM before, here&#x27;s the change, now patch it&quot; part.<p>More and more framework and UI library are going to be built around vritual-DOM concept. I don&#x27;t want integration nightmare of UI-libraries working only on some React-like library.

Does marty.js support the concept of an app context? The only implementation i know of is Yahoo&#x27;s fluxible (<a href="https://github.com/yahoo/fluxible" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;yahoo&#x2F;fluxible</a>). This is mainly useful when you&#x27;re trying to render your flux app on the server.

Slightly OT but has anyone tried Marionette + React as a combo? Would be very interested to hear how smoothly (or not) it went.

Can&#x27;t see a difference between marty and fluxxor.<p>The examples look for me the same, except some additional functions to declare things.

Congrats, the site looks really nice and the devtools feature is great!

This looks fantastic. Great work on the documentation too!

Make for building — interesting.

I 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.