Live data from Hacker News

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

martyjs.org

11–20 of 95 posts

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

#11
Nice 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 stores (so undo/redo is available without much work), loading data into stores from different sources etc.

I believe, in the following months, a de-facto flux framework will emerge, and marty looks so close to being that framework.

A few tips to fellow developers want to try react and/or flux:

- React is just the view part. Integrating it with other frameworks is easy, and integrating other js libs with react is also easy.

- OTOH, if you want to build a whole complex app with react, use something like flux with it, since there isn't a flexible way to modify the app state from child components with react.

- Immutable data structures really goes well with react + flux. I haven't been able to get the immutability/functional style before, and react + flux really helped with that.

Thanks again for the great tools.

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

#12
I've been using fynx[1], and it seems to work for me so far.

What attracted me to fynx was that it uses Facebook's immutable-js[2] for its stores.

It would be nice to get an updated version of this comparison of available flux libraries[3].

1: http://foss-haas.github.io/fynx/ 2: https://github.com/facebook/immutable-js 3: https://reactjsnews.com/the-state-of-flux/

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

#13
In http://martyjs.org/guides/flux/index.html it says

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

I don't see the connection between cause and effect, unless this is saying "since everything is in the global state there is no coupling". Seems odd.

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

#14

Can't see a difference between marty and fluxxor. The examples look for me the same, except some additional functions to declare things.

Author here. 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 fetching data asynchronously without callbacks http://martyjs.org/guides/stores/fetching-data…

Thanks, i will have a closer look.

The integrated data fetching and data flow extension sounds interesting, at the moment i use superagent with the mentioned callbacks and events to visualize (it is not comfortable).

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

#15
This 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

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

#16
Out 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/

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

#17

Out 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 really like Reflux as well. In a recent project I used Bacon.js[1] to create my own implementation that ended up looking similar to Reflux.

The project involved asynchronous requests triggered by the actions, and transforming & aggregating the returned data. Compared to Reflux, Bacon made it very easy to do this by composing small functions that are applied sequentially to a stream of actions.

[1] https://baconjs.github.io/

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

#18
post #15

This 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

Thanks for posting that, I've just been trying to get something similar to work using Bacon, and was looking for some examples of how to approach it.

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

#19

Out 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 using Reflux for now, though I'm tempted to switch to something more FRP like Bacon, f, or RxJS. I find that I end up making stores for both AllThings and CurrentThing, and it should be easier to express that relationship with FRP.

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

#20
post #8

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?

This sounds like a line from a movie for a character which is the nerd/genius in the movie. I'm not very technical, by the way.

I try to do my best to follow the trends in JavaScript development and do mostly develop with JavaScript and even I can't keep up with the new terminology these days. When looking at marty.js documentation, I was constantly trying to map the new concepts to the ones I already know about.
Post reply on HN