-1

I have seen it is becoming mandatory to use state pattern i.e mobx or rudux etc for building any react application. I am concerned that how much it is necessary to use these patterns. like if i have an application and have some pages in it each one is populating data with calling some restfull. So we can have handle it by adding some of optimization techniques like useEffect, usememo and usecalback and obviously custom hooks etc. Shouldn't it must be cleared before starting development application that how much we want to track changes in applications and how much global state we want to use. it we want only one global state ie auth status. we can use simple context and doing all with having simple techniques. So that our application become less dependent upon these libraries. If it is not like that which are the requirement that must be cleared before starting an application to decide whether to use state pattern or going with simpler version of react

Jahangir Hussain
  • 391
  • 1
  • 4
  • 10
  • Personally i had 2 different projects, developed for a half of year each using [context](https://reactjs.org/docs/context.html) only. 1 context for auth, 1 context for app global things, 1 context for Twilio handling, 1 context for firebase, etc. Contexts down the tree can interact with their parent contexts. For API i had a folder with Services, also folder for Models for each service, RequestModel, ResponseModel interfaces/classes (for typescript). Contexts can bloat a bit, but custom hooks can help to reduce the sizes. – Sergey Sosunov Sep 04 '22 at 12:35
  • @SergeySosunov if we go toward custom hooks. it always create new instances -- as per my knowledge about them-- every where we use it like useAuth() etc. so how can we say custom hooks are alternative to context ones. or you means to say handles contexts in every respective custom hooks. – Jahangir Hussain Sep 04 '22 at 13:58
  • My message about custom hooks is about extracting logic from Context and moving it to hook and just using them in Context. Because Context can grow pretty big in terms of code lines and it will be hard to support it due to few people will contantly push changes to it. Example: AuthContext that has a useEffect that loads current userData from firebase, why not extract this one useEffect + useState into custom hook 'useUserData()' that will have this logic inside and just returns a loaded object and use this hook in the Context it was before, almost in same place. – Sergey Sosunov Sep 04 '22 at 14:04
  • Alright. That has given sufficient justification. – Jahangir Hussain Sep 04 '22 at 14:59

1 Answers1

0

It's not mandatory. In fact, my startup's codebase doesn't use any state management library. Just useState and for a few special cases we rely on useContext. React even offers useReducer (which is a simplified Redux).

I used Redux for a project and I hated it. If you're going to use it, follow the rules. Redux should be side effect free and immutable. When needing async data, you often have to use complicated middleware and other libraries (e.g. Redux-Sagas).

The good thing is that you can use a state management library for a part of your app. Maybe even another state management library for a different part.

In some cases, it might be useful to use a state management pattern. Certainly when it allows you to make some logic more understandable, readable or testable.

My take away: Always try to keep it simple

Hans Ott
  • 599
  • 7
  • 11
  • Following your narration "The good thing is that you can use a state management library for a part of your app. Maybe even another state management library for a different part." would it not be an overkill if we are handling things using context and implement state pattern for the other part. So we can use same pattern alternative to the context. would it be beneficial we are implementing two techniques like context for the simpler ones and other for the complex ones. I am wanting to do the things whether by only using react things or to add third party. – Jahangir Hussain Sep 04 '22 at 13:49
  • can we say that it depends upon the api set we are implementing. like if we have set of all apis for every other corresponding component. Then we can go with simple ones like for each component it will set against each data returning by respiective api call.if we are getting all data from one api. on the other hand. we want its parts/slices like post in one component and comments in other components and need to change track then we may move toward implementing patterns. – Jahangir Hussain Sep 04 '22 at 13:55