Home > Software engineering >  Can you bypass state management for simple objects? (global shared state)
Can you bypass state management for simple objects? (global shared state)

Time:03-24

Can you globally instantiate a class and that will be reliable on react-native? i.e.

// logs.ts
const instance = new Instance()
export { instance }

// something.tsx
const Component = () => {
   instance.method()
   ...
}

If method were to increment a property by 1 would that property always have been incremented the number of times method was called throughout the project?

The primary benefit here is simplicity. For example, it's easier to define

class SomeClass {
  constructor(properties){}
  addProperty(key,value){ this.properties[key] = value }
}

than it is to do the equivalent in redux. Why don't people do the above more often?

CodePudding user response:

Just changing the value on some object will not result in state changes/cause a component to re-render. You still need a state provider to have the state set to. If you want to change the state of that Provider you'll need to run setState (or dispatch and useReducer) which means you'll need to pass the dispatch of that function around to all of its children. As your app grows larger you'll definitely want to/need to useReducer and perhaps even several providers, you'll be re-implementing redux which is only about 200 lines of code anyway. So the question will become why did you re-implement redux which is such a popular library that most people know exactly how to use and there is plenty of documentation for, in favor of your homegrown version of redux which doesn't provide much additional value?

In redux a primary benefit is the tooling like redux-logger, redux-thunk, redux dev tools and time travel and others etc which allows you to replay the changes made or undo them. Sure it is easy to modify an object but using redux allows you to testably and consistently see how an object (the redux state) changes over time and undo them. You can test that action creators return the correct actions. You can separately test that given specific actions the reducer behaves as expected and replay that with mockStore. In short, using redux you get the enterprise version supported by a large community of experts who have helped improve and implement essentially the simple class that you demoed.

CodePudding user response:

Although you can do this, it breaks away from the point of redux. Redux is meant to be a centralized state management store, and therefore, allow components to

  1. access shared state from a single location and analyze shared states, because it comes from one place.
  2. track history and actions taken to get state there
  3. makes maintaining, debugging and collaborating on a codebase much easier.

Doing the first option, all these benefits are lost.

That said, if you have multiple components in one file, and you want them all to share that same global state (not exporting it), using the class constructor to do so isn't a big deal, as long as the project isn't being worked on by other developers.

However, it would make more sense in that case to make an overall component class, and pass state down, as that is the point of React. Declaring a class outside and trying to manage state in the first way, would be a declarative approach, which is what React doesn't want developers to do (i.e there is a better way, like creating a hierarchy of components). That way, components re-render on a change in value, and no weird bugs arise

  • Related