3 ms·

Is there a way to get rid of flux boilerplate? I don't want to write three different files (a file with actions, another file with constants, and the actual sto

by sepeth 12y ago

Is there a way to get rid of flux boilerplate? I don't want to write three different files (a file with actions, another file with constants, and the actual store). For example, I can achieve the same effect with just a simple array and some functions to modify it. I guess I know what the benefit of embracing flux is, but it still looks too much, and I am mostly lazy.

veeti 12y ago
Reflux is a Flux library without the dispatcher boilerplate.
- nwienert 12y ago
  Fynx reduces it even more if you use immutable data. You only worry about the actions.
- cnp 12y ago
  +1 On Reflux. They have an awesome new async api now, too.
jonpaine 12y ago
Sure - just use what you want. Outside of the dispatcher, flux is mostly a design specification for clientside information flow. Actions, stores, etc aren't native to flux - they're just approaches for accomplishing the desired information flow. Check out the examples closer - they aren't react classes. That said, my personal opinion: the deeper you get into a big project the more you'll see the incredible value of the approach. The breakeven between the overhead of learning the approach vs the productivity (and performance improvement) of using it comes pretty early on, in my opinion. With a lot of software, the more I get deeply into a project the more I feel I'm battling the artificial constraints of the tools I'm using. Flux is exactly the opposite. The deeper I get in, the more I feel it's working for me (and I'm not even using their dispatcher - since I had written my own initially before flux came out, so I can't speak directly to their dispatcher, just the Flux design styling within a React project).
benihana 12y ago
You just articulated all the issues I have with these frameworks (Backbone is another one that comes to mind) - the boilerplate code violates the hell out of YAGNI, which for me is a core principle of my development style. You end up building a ton of boilerplate code that is capable of handling anything your system evolves into, but most of it is wasted because each part of the system typically only uses a small subset of functionality of the framework. So you're left with a bunch of big crufty systems laying around. When I want to be the most lightweight and agile and capable of changing my direction is at the beginning of a project when I'm still learning how the system will work. These frameworks make it really tough (at least for me) to do that so I end up not using them.
igvadaimon 12y ago
I am currently using alt: https://github.com/goatslacker/alt https://github.com/goatslacker/alt It's very small and removes boilerplate, but still isomorphic.
- jbhatab 12y ago
  yup, also liking alt.
- mcx 12y ago
  I'm also using alt and enjoying it. I like that it sticks close to the FB implementation of Flux but there is less boilerplate along with utilities such as bootstrap, snapshot, etc.

by sepeth 12y ago

veeti 12y ago

Reflux is a Flux library without the dispatcher boilerplate.

nwienert 12y ago
Fynx reduces it even more if you use immutable data. You only worry about the actions.
cnp 12y ago
+1 On Reflux. They have an awesome new async api now, too.

jonpaine 12y ago

Sure - just use what you want. Outside of the dispatcher, flux is mostly a design specification for clientside information flow. Actions, stores, etc aren't native to flux - they're just approaches for accomplishing the desired information flow. Check out the examples closer - they aren't react classes. That said, my personal opinion: the deeper you get into a big project the more you'll see the incredible value of the approach. The breakeven between the overhead of learning the approach vs the productivity (and performance improvement) of using it comes pretty early on, in my opinion. With a lot of software, the more I get deeply into a project the more I feel I'm battling the artificial constraints of the tools I'm using. Flux is exactly the opposite. The deeper I get in, the more I feel it's working for me (and I'm not even using their dispatcher - since I had written my own initially before flux came out, so I can't speak directly to their dispatcher, just the Flux design styling within a React project).

benihana 12y ago

You just articulated all the issues I have with these frameworks (Backbone is another one that comes to mind) - the boilerplate code violates the hell out of YAGNI, which for me is a core principle of my development style. You end up building a ton of boilerplate code that is capable of handling anything your system evolves into, but most of it is wasted because each part of the system typically only uses a small subset of functionality of the framework. So you're left with a bunch of big crufty systems laying around. When I want to be the most lightweight and agile and capable of changing my direction is at the beginning of a project when I'm still learning how the system will work. These frameworks make it really tough (at least for me) to do that so I end up not using them.

igvadaimon 12y ago

I am currently using alt: https://github.com/goatslacker/alt https://github.com/goatslacker/alt It's very small and removes boilerplate, but still isomorphic.

jbhatab 12y ago
yup, also liking alt.
mcx 12y ago
I'm also using alt and enjoying it. I like that it sticks close to the FB implementation of Flux but there is less boilerplate along with utilities such as bootstrap, snapshot, etc.