Standardize state management with React

[diegonvs]

When writing up some React applications, here at Recife we noticed that we needed to use Redux instead of simpler Context API to manage some states.
Context API has some limitations depending project's scope. e.g When trying to traverse more than three levels in components.
Would be a good idea to use redux only if you need and create some use cases when you need or when you shouldn't need? We could use useReducer hook with Context API that empowers developers but I don't know if this utilization covers all use cases.

/cc @oliveiraaraujo @phcp @brunobasto @matuzalemsteles

[bryceosterhaus]

With the new hooks API I think we should always default to using useReducer and useContext and falling back on redux in the very edge cases if there is one. I've yet to see a use case where reacts API won't work just as well as redux. I think redux can be a bit of overkill for most use cases.

[wincent]

@julien might have some thoughts on this too, and this article is good food for thought. The TL;DR is that React comes with a number of built-in state-management tools, and we should try to get the maximum mileage out of them before going to a higher-level tool.

One Redux-like library I really like because it is simpler and has rock-solid type support (for TypeScript and Flow) is Undux. It is almost, but not quite, zero-dependencies (it depends on "rxjs-observable"). But, obviously, Redux has massive adoption (50k stars on GitHub), and Undux has 1.2k. Of course, this isn't a popularity contest, but still...

[julien]

I totally agree with what you all said.

[p2kmgcl]

I also prefer relying on hooks for state management. Even when you have a big state I think it would be easier to maintain if you try to split the state more isolated states that having a big one with subtrees.

Moreover, I tried to use redux with typescript, and adding full typing when you try to manage a big state + using action creators + doing async stuff becomes really complicated.

[boton]

Totally agree with the article that @wincent linked.
Trying to avoid complex state management in the first instance sound good to me.

[p2kmgcl]

Just discovered this state management library. It uses react hooks API and looks quite beautiful:

https://easy-peasy.now.sh/

[boton]

@p2kmgcl looks great, https://github.com/jamiebuilds/unstated-next works in this way too but I have not tried it yet.

[wincent]

Cross-linking some work that we are doing in the React rewrite of the layout-content-page-editor module (started here). This uses only React built-in hooks to do Redux-like data management. It is early stages yet, but I think it shows how even complex requirements — in this case, thunks, combining multiple dynamically loaded reducers, using middleware etc — can be met without using Redux.

[wincent]

Just saw this pop-up: https://recoiljs.org/

Used at FB — and that doesn't mean it's used everywhere there — but could be interesting.

(Not advocating for it; haven't even looked at it yet!)

[bryceosterhaus]

just watched the recoil video and seems like solid approach, curious to play with it a bit.

[brunobasto]

looks very interesting.. although being under /facebookexperimental/recoil probably means we need to wait a year or two before considering it?

[wincent]

A lot of the stuff under "facebookexperimental" is there because individual engineers working on a project push for it to be open source; they're often projects started and used by one team, that maybe see some adoption by other teams, but there are thousands of engineers and many hundreds of projects — so you can imagine the number or random projects that people want to share with the world. "facebookexperimental" is really just a valve to let off some of the pressure; stuff in there still needs to get legal approval (etc), but doesn't necessarily have to have proved itself to the point where it gets recognition as a (or the) "blessed" solution. Some of them end up spreading and becoming defacto standards, but in reality most are competing there for marketshare just like any package on NPM would within an ecosystem. In addition to Recoild, I bet there is still a bunch of code at FB using Flux, Redux, Relay, and Undux for state management, along with team-or-org-local solutions that have never been open sourced.

So I'd say it's not a question of waiting for something that may never happen (eg. "graduating" from facebookexperimental to the facebook org — something which I see pretty unlikely as Facebook is very heavily invested in Relay for state management right now), but rather evaluating any given tool on its merits and making a decision based on that. This library is pretty small and might be a useful source of ideas even if we don't actual try out or adopt the library itself.

[jbalsas]

I think this is a good Twitter thread clarifying this a little bit:

I’ve seen some folks misunderstand Recoil and spread that confusion so I feel the need to clarify.

Recoil is not in any way an “official” state management library for React. And neither is (or ever was) Redux.

The only “official” state library for React is React itself.

The reality is that some people built something, found it useful, and shared it with the world. No grand narrative.

[brunobasto]

Yeah, I see. The reason I thought that was because our vetting process to adopt new dependencies. But I guess we could use it as a useful source of ideas / inspiration.

[wincent]

I was delighted to stumble on these tweets from Dan Abramov (creator of the initial version of Redux) the other day (he actually posted these last year, but I just saw them now):

Reading some Redux example code I wrote four years ago and I have no effing idea what's going on there

11:47 PM · Nov 4, 2019

I just want to fetch some datas jeez

11:48 PM · Nov 4, 2019

Why is this stuff in five different files and constants SHOUTING at me

11:49 PM · Nov 4, 2019

That’s literally the reason I’m going to Hell

12:19 AM · Nov 5, 2019

😂

[wincent]

GitHub seems to have dropped the transfer job on the floor 😢

Most of the comments did not make it over to the transferred issue (liferay/liferay-frontend-projects#349).

Oh well, going to close this anyway because I want to clean this whole repo of issues before requesting that it be archived.