3 ms·

My observation is that going with local state is going to bite you sooner than later and in most cases having it in Redux Store from beginning is a good idea.

by methyl 10y ago

Mikhail_Edoshin 10y ago
I recently made a slider in React/Redux. Imagine a slider that has a width of 200px but needs to report values from 0 to 100. (The width is governed by external factors, e.g. other sliders nearby that need to report a widger range, but must visually be of the same width.) This means that sometimes you may move the slider just by a pixel and need to register the movement, but the underlying value won't change. I.e. you have the slider offset and the actual value. The slider offset is a very transient variable that is not really important. Next time you load an object from the database you'll just convert the value to a slightly different offset and nobody will notice. Are you going to store the offset in the big store?
kerkeslager 10y ago
This has not been my experience. I wrote a good amount of React before introducing any Flux at all, and I've been bitten far more by my mistakes where I added things to stores unnecessarily than I have been by cases where I kept things in component state. Your experience might be different from mine. It's my impression that a lot of people are coming from a Angular or Ember-ish background where they're building what amounts to single-page web applications. I'm building multi-page apps that have heavier-lifting back-ends, and React fills the space of building components that can be composed and embedded in the page. When you're building a single-page app, stores make a great deal of sense. But when you're embadding components in a page, it doesn't make sense to use stores. Not only do I not want to have my components interact, I want to actively avoid having them interact, because that coupling would make the components non-reusable. So tying them to a global state presents serious issues for that model. It occurs to me that this might account for our difference in perception of the importance of stores. P.S. It's also worth noting that moving state out of a component and into a store is fairly painless. The reverse is not true; moving state out of a store and into component state is an extremely painful and error-prone process. So it makes sense to start with component state and move things into stores only as needed.

My observation is that going with local state is going to bite you sooner than later and in most cases having it in Redux Store from beginning is a good idea.

by methyl 10y ago

My observation is that going with local state is going to bite you sooner than later and in most cases having it in Redux Store from beginning is a good idea.

Mikhail_Edoshin 10y ago

I recently made a slider in React/Redux. Imagine a slider that has a width of 200px but needs to report values from 0 to 100. (The width is governed by external factors, e.g. other sliders nearby that need to report a widger range, but must visually be of the same width.) This means that sometimes you may move the slider just by a pixel and need to register the movement, but the underlying value won't change. I.e. you have the slider offset and the actual value. The slider offset is a very transient variable that is not really important. Next time you load an object from the database you'll just convert the value to a slightly different offset and nobody will notice. Are you going to store the offset in the big store?

kerkeslager 10y ago

This has not been my experience. I wrote a good amount of React before introducing any Flux at all, and I've been bitten far more by my mistakes where I added things to stores unnecessarily than I have been by cases where I kept things in component state. Your experience might be different from mine. It's my impression that a lot of people are coming from a Angular or Ember-ish background where they're building what amounts to single-page web applications. I'm building multi-page apps that have heavier-lifting back-ends, and React fills the space of building components that can be composed and embedded in the page. When you're building a single-page app, stores make a great deal of sense. But when you're embadding components in a page, it doesn't make sense to use stores. Not only do I not want to have my components interact, I want to actively avoid having them interact, because that coupling would make the components non-reusable. So tying them to a global state presents serious issues for that model. It occurs to me that this might account for our difference in perception of the importance of stores. P.S. It's also worth noting that moving state out of a component and into a store is fairly painless. The reverse is not true; moving state out of a store and into component state is an extremely painful and error-prone process. So it makes sense to start with component state and move things into stores only as needed.