What kind of data should be in redux about my-life-as-a-programmer

[Edza]

Hi,

Interesting topic. Gonna offer my ideas as well.

With Vue and Vuex I found out that you want cross-component dependencies to be kept in the store. Anything that can't be a direct prop down or an event up.

In my experience for huge enterprise application the benefit/cost ratio for keeping EVERYTHING in the store might not be worth the extra man hours. But personally, I'm still forming my opinion about this.

[Nothing-Works]

@Edza I also think that keep all the state in the store is a little bit weird (from my experience), we have a data center but it does not mean that we have to use it everywhere. especially when it comes to form data, is it necessary we call to update the store on every keystroke? Personally, I doubt it. I think when it comes API fetch we may keep all the data in the store so we have a single place shows all the data from outside, just easy to read I guess? but again I do not know the best practice, I am still learning. btw, I really like VUE, will give VUE a try in my next project.

[fChristenson]

Hi m8!

You are touching on a interesting topic that can be confusing to a lot of people so let me share some thoughts on this.

Lets forget about React for a moment and ask the fundamental question, what is the hard part about having a big JavaScript application with many different components?

The biggest issue is generally considered to be state management which means that sharing state updates between different node trees so the UI can reflect those changes.

Notice that the problem is sharing state updates between components but holding state for a single component is not much of an issue.

In React the state is there to help you with holding a component level state where there is no need to share updates with other components or at the very least any updates can be passed down to a child component, this is "simple" even in vanilla JavaScript.

Redux allows you to dispatch messages that have the ability to notify components regardless of where in the node tree they are found at the cost of passing these message through the entire tree.

So why do we want to do this?

Well we want to do this because we want to be able to tell a component that something changed and that is often very hard with just using the state so it stands to reason that data that needs to be shared with other components should be on the store while data that can be stored internally and has no impact on anything outside the component or its direct children can stay outside the store.

Other factors that need to be considered is if you need to keep the state after a component is unmounted from the node tree to later be reattached again.

A good rule of thumb is that for state that doesn't need to live beyond the life of the component and doesn't need to be shared it makes more sense to store it on the state but for shared data or data that needs to be cached beyond the life of the component use the store.

Have a great day!