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

51–60 of 95 posts

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

#51

Post by fisherwebdev »

eric_bullington wrote: post #29
picardo wrote: post #24

Nice documentation. But I don'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 "ease of use" around stores and constants –– "state management" is a good euphemism for this need –– but that's not really a bottleneck for me. I can manage my constants manually with Flux, and add…

The Flux pattern contains too much boilerplate and indirection for small or quick one-of web apps. If Marty helps to abstract some of that out, it's more than welcome to me. Frankly, for small apps, I think you can get 90% of the benefit of Flux by using the pubsub solution of your choice and taking care about only subscribing from top-level components and passing state change down to their children. Immutable cursor…

I find that small apps tend to turn into big apps over time, and Flux lets us build with the confidence that, as new features are developed, our apps won't have to be deeply rewritten. New, unexpected features tend to fall into place with Flux, with a minimum of effort. I have seen this time and time again in working with Flux.

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

#52

Post by grandalf »

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 challenge with these kinds of apps comes at that next tier of complexity... it's trivial to do a clean TODO implementation that doesn't do anything with server data in nearly any framework).

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

#53

Post by bsimpson »

jfhollingworth wrote: post #26
bsimpson wrote: post #23

Earlier quoted context omitted.

Like many others, I've been using Reflux because it seems to be the easiest to understand and to work with by reducing the surface area of concepts you need to understand to just: 1) actions 2) stores. In Reflux, a store is effectively just a variable you want your component(s) to be able to access and an action is a function that tells the store what to change about its state. For instance, I might have a CurrentUse…

That's what I tried to do with this page http://martyjs.org/guides/flux/index.html . Let me know how I could improve it

I see a Get Started Now button on the home page (I didn't see it the first time through). I'd add a How It Works button right next to it that links to that Flux page. It's definitely helpful, although the constants and dispatchers feel like implementation details that most developers shouldn't have to think about.

You switch between "actions" and "action creators" in this paragraph, which makes it hard to follow:

> Action Creators are where any changes to your applications state starts. Actions are functions that are responsible for coordinating changes to local and remote state. Actions have a type which is a string describing the action (e.g. "UPDATE_USER_EMAIL").

I thought the Action Creator was a function and the Action was the act of invoking it, but that's not clear in the quoted section.

-----

I think your documentation is a bit hard to follow because you're using JavaScript in unexpected ways. For instance, it's a bit weird that your constants are invokable:

    updateUserEmail: UserConstants.UPDATE_USER_EMAIL(function (userId, email) {
and I think the line after it mixed constants and action creators:

> In the above scenario, UserConstants.UPDATE_USER_EMAIL creates an action creator which, when invoked, will create an action with type UPDATE_USER_EMAIL.

-----

You're missing a ( here:

    UserActionCreators.updateUserEmailthis.props.userId, email);
-----

In the next example, you use the method name as a key and the constant that triggers it as a value:

    handlers: {
      updateEmail: UserConstants.UPDATE_USER_EMAIL
    },
Since the convention in all the libraries I've seen is to use type as the key and the callback as the value, most developers are going to be immediately tripped up by this unless you call it out in the documentation.

-----

Marty has some interesting ideas. Thanks for sharing them, and for taking the time to make a website explaining them.

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

#54

Post by sun_zoo »

rpwverheij wrote: post #41

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, co…

I found this react-flux implementation much more approachable: https://github.com/kjda/ReactFlux

I've added an isomorphic design to it as a starting point for what will eventually be a fantasy draft application: https://github.com/rblakeley/fifa-heroes

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

#55

Post by sun_zoo »

peterjmag wrote: post #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/

https://github.com/kjda/ReactFlux is really approachable, but not an entire framework. It has been a great starting point for what will become a fantasy draft app: https://github.com/rblakeley/fifa-heroes

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

#56

Post by tel »

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.

Obligatory Bacon.js and RxJS are not FRP but merely RP statement.

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

#57

Post by kaonashi »

Touche wrote: post #37
hakanderyal wrote: post #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 st…

If you want a framework with immutability you should probably just use https://github.com/Raynos/mercury as it gets rid of React's unnecessary component state.

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

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

#58

Post by malandrew »

kaonashi wrote: post #57
Touche wrote: post #37

Earlier quoted context omitted.

If you want a framework with immutability you should probably just use https://github.com/Raynos/mercury as it gets rid of React's unnecessary component state.

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 observ-varhash. Serialization and hydration works basically out of the box.

My reaction to the marty stuff is that it's trying to moved towards an architecture that mercury already has out of the box and that you don't have the unnecessary component state stuff the parent comment mentioned.

The component state stuff is probably my biggest gripe with the way react is architected.

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

#59

Post by btown »

jfhollingworth wrote: post #33
colinramsay wrote: post #2

I'm scanning the documentation for this now and the "state sources" concept looks useful. Stores seem to be a bit cleverer than in other Flux implementations too. The fact it's got a Chrome extension and what appears to be comprehensive documentation bodes well. I'm currently using reflux because I like its simplicity (no dispatcher and no action creators) but Marty has definitely piqued my interest. Edit: Question f…

Isomorphic apps are the next big challenge. Right now the biggest blocker is that everything's a singleton. I'm working on an internal container which should hopefully mean existing apps can be made isomoprhic without a change to the API

I've found that contexts are a good way to handle this - they're basically invisible props that get implicitly passed down the component tree, and mixins can whitelist which parts of the context they want to be able to use. They're undocumented, but they're used quite widely in React, so I doubt they're going anywhere. You can have a top-level component instantiate new dispatchers and stores and expose them as i.e. "this.context.userStore", "this.context.dispatcher" to mixins and component code. And this can be done concurrently in the same Node process without needing VMs/sandboxing. Your state mixin API might need to change a bit, but it can be substantially the same:

var UserState = Marty.createStateMixin({ listenTo: "UserStore", getState: function (UserStore) { return { users: UserStore.getAll() }; } });

A reference: https://www.tildedave.com/2014/11/15/introduction-to-context...

Fluxxor, FYI, bundles all of this in context.flux: https://github.com/BinaryMuse/fluxxor/blob/master/lib/flux_m...

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

#60

Post by lumpypua »

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.

shrug They address different problems. Reactive systems are great but they aren't an overall architectural approach. You have to come up with that yourself.

Flux is an architecture.

I used BaconJS and I found that my overall page event and data flow ended up being reactive spaghetti. Architecture is not my strong suit. One of the great things about flux is having extremely strong conventions about where everything goes:

- All interactions are through actions.

- All state is in stores.

- No mutable state in the actual UI.

- etc.

What's your overall dataflow architecture look like using RxJS or BaconJS?

Post reply on HN