[jrochkind1]

> Next, plan your Redux store ahead. I feel like I made the mistake of overusing it. Almost every property of my app is managed by Redux and this results in large reducers and many many actions to control all that. It’s very important to figure if some prop will be needed outside a certain component or not and, if not, keep that inside that component.

How can you possibly know _in advance_ if a prop will be needed outside a certain component (you haven't written yet) or not? This seems to imply a suggestion to completely architect the entire app (what components exist, how they relate) before you write much code. And then somehow being correct, even as you develop the app and add new features etc.

I haven't done anything with React Native, and am only a beginner at web React, but this kind of data management architecture has definitely been one of my biggest challenges. I find it hard to change things once they're there, but hard to know what should be there up front.

[user5994461]

>>> How can you possibly know _in advance_ if a prop will be needed outside a certain component (you haven't written yet) or not? This seems to imply a suggestion to completely architect the entire app (what components exist, how they relate) before you write much code. And then somehow being correct, even as you develop the app and add new features etc.

In engineering, that's what we call the design phase.

[dsego]

That's cool, is there a "user story" for that?

[djtriptych]

Just draw what you're building on a piece of paper. That's going to force you to think through a lot of it. Amazing how few FE engineers will do this.

[abledon]

Tutorial link for executing this type of 'drawing'?

[faitswulff]

I can't even find the API docs for drawing to "paper." They need to work on the usability and make it a proper open standard, like HTML Canvas!

[RubenSandwich]

Redux has a great piece of their tutorial that deals with this problem:

http://redux.js.org/docs/recipes/reducers/BasicReducerStruct....

Here are a few gotchas to avoid:

1. Define your state shape in terms of your domain data and app state, not your UI component tree.

2. Your reducers do not need to have a 1 to 1 mapping to actions. If you need to fire multiple actions to change the data you need then rethink your reducers.

[jrochkind1]

"Define your state shape in terms of your domain data and app state, not your UI component tree."

I'm not sure that's what OP is recommending though? In fact, that redux doc seems to me to making an opposite suggestion to the OP -- it seems to be suggesting you should put domain data, app state, and UI state all in the store, but "define your state shape in terms of your domain data and app state, not your UI component tree." OP seems to recommend trying ot keep app state and UI state _out_ of the store if you can.

I think people in practice have a lot of trouble with this, and making it successful, even after experience.

But apparently a lot don't too?

[swsieber]

I would interpret the comment as by default, don't use the redux unless you need it. And when you go to use it, think about it.

[ruimagalhaes]

You can make that effort of thinking the component architecture ahead and that will definitely help. To be honest I was thinking more about props that you'll know will live inside a component but end up on the redux store anyway. I made this mistake with forms on my first react native app by having any field value on the store. I didn't really need to that and the store got bigger and bigger because of that first choice.

[jrochkind1]

Then we also get the opposite advice, above, _don't_ think about your component architecture when defining state! "Define your state shape in terms of your domain data and app state, not your UI component tree."