5 ms·

Several reasons why it's popular: - It has helped many developers organize their "write logic" and state management, and made it easier to test that code - Ti

Several reasons why it's popular: - It has helped many developers organize their "write logic" and state management, and made it easier to test that code - Time travel debugging is a fantastic tool for understanding what happens in your application - One of my favorite quotes: "Redux is a generic framework that provides a balance of just enough structure and just enough flexibility. As such, it provides a platform for developers to build customized state management for their use-cases, while being able to reuse things like the graphical debugger or middleware." - And it doesn't hurt that Dan Abramov is a well-known figure in the React community, and an incredibly helpful and friendly person too. No, Javascript doesn't have immutability built-in (sadly), but that doesn't mean you should totally give up on applying those principles in Javascript code. There's WAY more developers writing JS than Clojurescript, and those devs can still make use of tools like Redux in their applications. Besides, there's a variety of approaches for handling data immutably, whether it be `Object.assign`, the Stage 3 object spread operator, Immutable.js, or the many immutable update utility libraries out there. Your comment about speed doesn't make sense. A few function calls and switch statements will execute quickly overall, and perf benchmarks will show that your reducer logic is almost never going to be the bottleneck in a Redux application. Some links for further related reading: - https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4... - http://redux.js.org/docs/faq/Reducers.html#reducers-use-switch http://redux.js.org/docs/faq/Reducers.html#reducers-use-swit... - http://redux.js.org/docs/faq/Performance.html#performance-all-reducers http://redux.js.org/docs/faq/Performance.html#performance-al... - https://github.com/markerikson/react-redux-links/blob/master/immutable-data.md https://github.com/markerikson/react-redux-links/blob/master... - https://github.com/markerikson/redux-ecosystem-links/blob/master/immutable-data.md https://github.com/markerikson/redux-ecosystem-links/blob/ma...

gyrgtyn 9y ago
When do you get to write `a.b = c` in react? Not with `setState`
- noncoml 9y ago
  Don't you use `setState` only for UI state, i.e. react components? As far as I understand it with redux you end up having all of your application's state in the store. Unless you split it?
  - acemarke 9y ago
    It's up to you how much of your data you put into Redux. Quoting the Redux FAQ at http://redux.js.org/docs/faq/OrganizingState.html#organizing-state-only-redux-state http://redux.js.org/docs/faq/OrganizingState.html#organizing... : > Using local component state is fine. As a developer, it is your job to determine what kinds of state make up your application, and where each piece of state should live. Find a balance that works for you, and go with it. Some common rules of thumb for determining what kind of data should be put into Redux: > - Do other parts of the application care about this data? > - Do you need to be able to create further derived data based on this original data? > - Is the same data being used to drive multiple components? > - Is there value to you in being able to restore this state to a given point in time (ie, time travel debugging)? > - Do you want to cache the data (ie, use what's in state if it's already there instead of re-requesting it)? I've seen some people say that you should put literally every single value in your app into Redux. You certainly _can_ do that, but I would see it as overkill. I'm much more pragmatic about it - put it into Redux if it makes sense to, per the rules of thumb in the FAQ.
    - noncoml 9y ago
      > Some common rules of thumb for determining what kind of data should be put into Redux: > > - Do other parts of the application care about this data? > - Do you need to be able to create further derived data based on this original data? > - Is the same data being used to drive multiple components? > - Is there value to you in being able to restore this state to a given point in time (ie, time travel debugging)? > - Do you want to cache the data (ie, use what's in state if it's already there instead of re-requesting it)? Won't having half your state outside the store and the other half inside add unneeded complexity and make your code even more difficult to read?
kevmo 9y ago
Dan Abramov is one of the most actively helpful open source authors I've even encountered. He debugs basically every Github issue that gets opened against his libraries.
- boobsbr 9y ago
  Dude must have at least 3 clones to handle all the stuff the does. Amazing person.
weq 9y ago
I think immutability is actually the crux of the problem here. Why is it used? So the UI knows when to update... Redux applies layers of complexity just to know when ur UI is going to update (efficiently)... Thats a scaling issue! So ur store cant scale to large data-sets because of immtability, and your app cant properly model ur domain, because it needs to be flat to support updates. That shouldnt be an afterthought for a state management library that uses the principles of event sourcing to create a state tree. I think its these two ideas clashing that causes the verbose code, the community complaints, and slow code as described in the post. Why should i need to mutate references? IMO it would be alot more palatable if redux persisted events, not the store. And was opined about the event structure, instead of everything else. ie. Use inheritance/events to then control UI updates. ie. NOT Comment_Added { postId:.., comment: .. } rather Comment_Added : PostDomainEvent {comment: ..} now on the page where i am viewing a current_post, i can simply connect to my state, and re-render whenever i see a PostDomainEvent of id == current_post_Id. I can also buffer re-renders based on the amount of postDomainEvents i see per second. This way, as someone using the library, my events are my focus, not my store. I dont need to remember to mutate this, or do that. I get precise control, and anyone can implement the store in any technology they want. sure i need an "unreduce" to get time-travel debugging, but thats not a trade-off thats forced on ppl who dont need it.
- acemarke 9y ago
  For what it's worth, immutability matters for more than _just_ having React-Redux properly update. It also matters for time-travel debugging, and to some extent for proper reducer testing. I'd very much disagree with the phrases "can't scale to large data-sets because of immutability", and "app can't properly model your domain". If you follow the suggested pattern of normalizing your state like a database [0], then modeling relationships between data types is entirely feasible, AND you can update the individual items efficiently (and if you don't want to write that code manually, there's a ton of addon libraries to help you manage those relationships [1] [2] [3]). At that point, the only real limit to how much data you load is browser memory, same as any other client-side framework. [0] http://redux.js.org/docs/recipes/reducers/NormalizingStateShape.html http://redux.js.org/docs/recipes/reducers/NormalizingStateSh... [1] https://github.com/tommikaikkonen/redux-orm https://github.com/tommikaikkonen/redux-orm [2] http://blog.isquaredsoftware.com/2016/10/practical-redux-part-1-redux-orm-basics/ http://blog.isquaredsoftware.com/2016/10/practical-redux-par... [3] https://github.com/markerikson/redux-ecosystem-links/blob/master/entity-collection-management.md https://github.com/markerikson/redux-ecosystem-links/blob/ma...

gyrgtyn 9y ago

When do you get to write `a.b = c` in react? Not with `setState`

noncoml 9y ago
Don't you use `setState` only for UI state, i.e. react components? As far as I understand it with redux you end up having all of your application's state in the store. Unless you split it?
- acemarke 9y ago
  It's up to you how much of your data you put into Redux. Quoting the Redux FAQ at http://redux.js.org/docs/faq/OrganizingState.html#organizing-state-only-redux-state http://redux.js.org/docs/faq/OrganizingState.html#organizing... : > Using local component state is fine. As a developer, it is your job to determine what kinds of state make up your application, and where each piece of state should live. Find a balance that works for you, and go with it. Some common rules of thumb for determining what kind of data should be put into Redux: > - Do other parts of the application care about this data? > - Do you need to be able to create further derived data based on this original data? > - Is the same data being used to drive multiple components? > - Is there value to you in being able to restore this state to a given point in time (ie, time travel debugging)? > - Do you want to cache the data (ie, use what's in state if it's already there instead of re-requesting it)? I've seen some people say that you should put literally every single value in your app into Redux. You certainly _can_ do that, but I would see it as overkill. I'm much more pragmatic about it - put it into Redux if it makes sense to, per the rules of thumb in the FAQ.
  - noncoml 9y ago
    > Some common rules of thumb for determining what kind of data should be put into Redux: > > - Do other parts of the application care about this data? > - Do you need to be able to create further derived data based on this original data? > - Is the same data being used to drive multiple components? > - Is there value to you in being able to restore this state to a given point in time (ie, time travel debugging)? > - Do you want to cache the data (ie, use what's in state if it's already there instead of re-requesting it)? Won't having half your state outside the store and the other half inside add unneeded complexity and make your code even more difficult to read?

kevmo 9y ago

Dan Abramov is one of the most actively helpful open source authors I've even encountered. He debugs basically every Github issue that gets opened against his libraries.

boobsbr 9y ago
Dude must have at least 3 clones to handle all the stuff the does. Amazing person.

weq 9y ago

I think immutability is actually the crux of the problem here. Why is it used? So the UI knows when to update... Redux applies layers of complexity just to know when ur UI is going to update (efficiently)... Thats a scaling issue! So ur store cant scale to large data-sets because of immtability, and your app cant properly model ur domain, because it needs to be flat to support updates. That shouldnt be an afterthought for a state management library that uses the principles of event sourcing to create a state tree. I think its these two ideas clashing that causes the verbose code, the community complaints, and slow code as described in the post. Why should i need to mutate references? IMO it would be alot more palatable if redux persisted events, not the store. And was opined about the event structure, instead of everything else. ie. Use inheritance/events to then control UI updates. ie. NOT Comment_Added { postId:.., comment: .. } rather Comment_Added : PostDomainEvent {comment: ..} now on the page where i am viewing a current_post, i can simply connect to my state, and re-render whenever i see a PostDomainEvent of id == current_post_Id. I can also buffer re-renders based on the amount of postDomainEvents i see per second. This way, as someone using the library, my events are my focus, not my store. I dont need to remember to mutate this, or do that. I get precise control, and anyone can implement the store in any technology they want. sure i need an "unreduce" to get time-travel debugging, but thats not a trade-off thats forced on ppl who dont need it.

acemarke 9y ago
For what it's worth, immutability matters for more than _just_ having React-Redux properly update. It also matters for time-travel debugging, and to some extent for proper reducer testing. I'd very much disagree with the phrases "can't scale to large data-sets because of immutability", and "app can't properly model your domain". If you follow the suggested pattern of normalizing your state like a database [0], then modeling relationships between data types is entirely feasible, AND you can update the individual items efficiently (and if you don't want to write that code manually, there's a ton of addon libraries to help you manage those relationships [1] [2] [3]). At that point, the only real limit to how much data you load is browser memory, same as any other client-side framework. [0] http://redux.js.org/docs/recipes/reducers/NormalizingStateShape.html http://redux.js.org/docs/recipes/reducers/NormalizingStateSh... [1] https://github.com/tommikaikkonen/redux-orm https://github.com/tommikaikkonen/redux-orm [2] http://blog.isquaredsoftware.com/2016/10/practical-redux-part-1-redux-orm-basics/ http://blog.isquaredsoftware.com/2016/10/practical-redux-par... [3] https://github.com/markerikson/redux-ecosystem-links/blob/master/entity-collection-management.md https://github.com/markerikson/redux-ecosystem-links/blob/ma...