A space to discuss and keep up software development and manage your software career
An inclusive community for gaming enthusiasts
News and discussion of science and technology such as AI, VR, cryptocurrency, quantum computing, and more.
From composing and gigging to gear, hot music takes, and everything in between.
Discussing AI software development, and showing off what we're building.
A general discussion space for the Forem community. If it doesn't have a home elsewhere, it belongs here
Movie and TV enthusiasm, criticism and everything in-between.
Memes and software development shitposting
Web design, graphic design and everything in-between
A community of golfers and golfing enthusiasts
Your central hub for all things security. From ethical hacking and CTFs to GRC and career development, for beginners and pros alike
For engineers building software at scale. We discuss architecture, cloud-native, and SRE—the hard-won lessons you can't just Google
Discussing the core forem open source software project — features, bugs, performance, self-hosting.
A collaborative community for all things Crypto—from Bitcoin to protocol development and DeFi to NFTs and market analysis.
A place for parents to the share the joys, challenges, and wisdom that come from raising kids. We're here for them and for each other.
A community for makers, hobbyists, and professionals to discuss Arduino, Raspberry Pi, 3D printing, and much more.
Start without it, but use functions to get shared state. The functions will make transitioning to a state machine easier down the line.
Add redux/some-statemachine when/if the situation starts warranting it.
I love the reducer/redux/flux/(what do we actually call it?) pattern, but I never use it while prototyping.
Also if the implementers dont know functional patterns already, then the learning curve to efficient use is gonna be that much steeper.
Flux is amazing. I think the structure of separating everything (actions, reducers) in different files has made Redux complex. Otherwise, it's good
I rarely put related code in different files when using redux.
That usually only happens when i hit the ~180 line limit or if i have lots of smaller definitions in it. :)
Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink.
Hide child comments as well
Confirm
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Start without it, but use functions to get shared state. The functions will make transitioning to a state machine easier down the line.
Add redux/some-statemachine when/if the situation starts warranting it.
I love the reducer/redux/flux/(what do we actually call it?) pattern, but I never use it while prototyping.
Also if the implementers dont know functional patterns already, then the learning curve to efficient use is gonna be that much steeper.
Flux is amazing.
I think the structure of separating everything (actions, reducers) in different files has made Redux complex. Otherwise, it's good
I rarely put related code in different files when using redux.
That usually only happens when i hit the ~180 line limit or if i have lots of smaller definitions in it. :)