Question for all the redux or Rx.js users...<p>How do you efficiently manage your state/actions when it gets super complicated?<p>I don't mean in terms of performance though, I'm interested in terms of how you make it so your codebase is still scaleable.<p>I've worked on/built 4 front-end apps now that were 100k+ lines of code and it always seems like redux becomes a large blockade to refactoring/features at some point.<p>It seems great if you know exactly what your code should do..but when you're a startup and refactoring features every couple months, it feels like Redux can actually hurt you more than help you.<p>I just had to trace down a component interaction that bubbled up to its parent component that called an action def that then was thrown in an action func thats outcome ran through a reducer that was monitored by an rxjs observable.. And all of this was just to remove an element from a page. I've got 7 files open and it took me 10 mins to trace something trivial down.<p>In scrappier times, I'd just call the $.delete and .remove() the element. Two small pieces of code, could even stick them in a React component and call it a day. If I needed to refactor the behavior, I could just open up it up and find it in a few seconds<p>I know redux is crazy powerful and can make some things really awesome and I've seen it first hand..my last team built a dope Redux app that was handling thousands of stock ticker updates a second with crazy performance. That said... it creates such a web of structure that it feels super hard to untangle when you need to change your state structure or refactor behavior around an action.<p>tl;dr keep me from switching back to vanilla js and the stone age
It's hard to say what's going wrong without looking at actual code, but here are a few anti patterns to look out for:<p>DON'T use actions like methods or setters.<p>DO try to think of actions as simple events.<p>DON'T describe the -effect- of an action in its payload.<p>DO describe the -cause- of potential effects in the payload, and let your reducers handle the rest.<p>DON'T think of stores as singletons that you can poke at from the UI.<p>DO think of stores as convenient "views" into the full history of events in your app.<p>DON'T use actions as a way of announcing that some piece of state has changed. That's what `subscribe` is for.<p>Here's a great talk about scaling Flux: <a href="https://youtu.be/Dm9NgjR5Jn4" rel="nofollow">https://youtu.be/Dm9NgjR5Jn4</a>