Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

martyjs.org

Post reply on HN
Print view View original

81–90 of 95 posts

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

#81

Post by eric_bullington »

eweise wrote: post #48
eric_bullington wrote: post #25

Earlier quoted context omitted.

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.

Thanks for your comment, much appreciated!

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

#82

Post by hakanderyal »

daveidol wrote: post #72

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

The method that you linked is the one I use currently.

Another way is to use a nested immutable data structure (something like immutable.js[1], react-cursor[2]), use only one store, and make all changes on this data structure and pass accordingly.

Even if you don't use immutable.js, I strongly suggest to use immutability with react update[3] or equivalent. Things get way easier that way.

[1]: https://github.com/facebook/immutable-js

[2]: https://github.com/dustingetz/react-cursor

[3]: https://facebook.github.io/react/docs/update.html

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

#83

Post by hakanderyal »

grandalf wrote: post #52
kuni-toko-tachi wrote: post #46

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.

A few questions: - What is the equivalent of the global action bus in Flux? - How do you handle consuming data from multiple rest endpoints? - Suppose you want to restructure the components in the app into a different hierarchy, how much refactoring is involved? - Is there any open source example code of an app built this way that is more complex than a simple todo or simple async example? (I think the biggest challe…

In flux, all the data are stored in stores.

When a component needs data, it subscribes to the relevant stores, and updates itself on data changes.

When you want to mutate the data, you call an action, which in turns mutate the data in the store. Since the components are subscribed to stores, they get the new data automatically.

Stores subscribe to a central dispatcher, listening to all actions. When an action fires, they look the action's data, and mutate their data if it is relevant to them.

The data flow is action-> dispatcher-> store -> component -> action.

When you want to get data from a rest endpoint, you fire an action from the component. The action fetches the data, and pushes it to dispatcher.

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

#84

Post by STRML »

This seems very similar to Fluxxor, but solves some of the pain points.

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's "State Sources" concept. I released a fork of Fluxxor a while ago with Mixin support [1] but it is unlikely to make it until 2.0.

The other nice parts to my eyes are:

State Mixins - sort of a hybrid between Fluxxor's StoreWatchMixin and Fluxxor-autobind [2]

Constants - This is a new one, I like it. Will have to play with it to see if it truly solves any problems; I've found that when I need to know what actions are available, I scan my actions files, simple as that.

Marty seems a little more "batteries included" 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't see Mixins in Marty Stores either. In my opinion they are required for non-trivial apps.

1. https://github.com/STRML/fluxxor/tree/storeMixins

2. https://github.com/STRML/fluxxor-autobind

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

#85

Post by jfhollingworth »

STRML wrote: post #84

This seems very similar to Fluxxor, but solves some of the pain points. 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's "State Sources" concept. I released a fork of Fluxxor a while ago with Mixin support [1] but it is unlikely to make it until 2.0. The other nice parts to my eyes are: State Mixins - sort of…

Author here: Marty stores do have mixins, think I forgot to add them to the docs

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

#87

Post by STRML »

jfhollingworth wrote: post #85
STRML wrote: post #84

This seems very similar to Fluxxor, but solves some of the pain points. 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's "State Sources" concept. I released a fork of Fluxxor a while ago with Mixin support [1] but it is unlikely to make it until 2.0. The other nice parts to my eyes are: State Mixins - sort of…

Author here: Marty stores do have mixins, think I forgot to add them to the docs

Great! That's a big plus for me.

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

#88

Post by daveidol »

hakanderyal wrote: post #82
daveidol wrote: post #72

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

The method that you linked is the one I use currently. Another way is to use a nested immutable data structure (something like immutable.js[1], react-cursor[2]), use only one store, and make all changes on this data structure and pass accordingly. Even if you don't use immutable.js, I strongly suggest to use immutability with react update[3] or equivalent. Things get way easier that way. [1]: https://github.com/faceb…

Thanks for the suggestions. I've looked at immutable data structure libs some, but I haven't seen any real comprehensive examples showing the behavior you describe within the Flux pattern. Do you happen to know of any such examples?

I ask because the examples I see for react-cursor, etc typically show data being mutated directly inside the React component without using Actions/Stores/etc. Going this route means we lose the advantages such as a unidirectional data flow & the ability to centralize logic for interacting with a Store around well-defined Actions.

So if we did merge the Flux idea with Cursors, I assume we would keep a single Cursor as the underlying state inside a Store, and then use the traditional Action/ActionCreator model to allow React components/server updates to mutate this Store?

What is the big win here then vs. traditional (non-immutable) Stores (other than performance gains by using === in shouldComponentUpdate)? It seems to me you would still have to make a separate Store for editing a single item vs editing a collection.

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

#89

Post by kylemathews »

bsimpson wrote: post #40
kylemathews wrote: post #38

Earlier quoted context omitted.

I've been using a "FilteredConnect" mixin that I wrote that's solved the "CurrentThing" store problem nicely.

Interesting. Link?

Still private — need to create a pull request against Reflux.

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

#90

Post by kaonashi »

malandrew wrote: post #58
kaonashi wrote: post #57

Earlier quoted context omitted.

Gaa, another framework that's opinionated about the data structures it gets passed. No thanks.

Try those data structures out. They are based on functional lenses and are really efficient and you can get time travel for free. It's worth trying to understand the data structure and why it was used before you dismiss it out of hand. It was a very deliberate choice. There is also a very strong 1:1 mapping between plain old javascript objects and the state data structure you build up with observ, observ-struct and o…

IMHO, that sounds like more of a concern for the data structures you're using, not the view layer.

I do appreciate you taking the time to lay out the advantages, and I was rather flippant.

Post reply on HN