Ask HN: How do you manage redux at scale?

4 pointsadambratt8y ago1 comments

Question for all the redux or Rx.js users...

How do you efficiently manage your state/actions when it gets super complicated?

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.

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.

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.

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.

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

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.

tl;dr keep me from switching back to vanilla js and the stone age

1 comments

namuol8y ago

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:

DON'T use actions like methods or setters.

DO try to think of actions as simple events.

DON'T describe the -effect- of an action in its payload.

DO describe the -cause- of potential effects in the payload, and let your reducers handle the rest.

DON'T think of stores as singletons that you can poke at from the UI.

DO think of stores as convenient "views" into the full history of events in your app.

DON'T use actions as a way of announcing that some piece of state has changed. That's what `subscribe` is for.

Here's a great talk about scaling Flux: https://youtu.be/Dm9NgjR5Jn4

j / k navigate · click thread line to collapse