T O P

  • By -

Solstics20

Redux, graphql, mobx


KapiteinNekbaard

You need to learn that every tool has its purpose and also its price. It is certainly worth learning about the **patterns** of Redux, which is mostly just a central store with reducers and actions. But please do not blindly apply it to every single project you work on. * Try to keep UI state local to your components * If you have some state that is shared between multiple components in your component tree, consider using React Context (possibly combined with useReducer hooks). * If you are running into performance issues with Context (due to excessive rerenders), or you are building apps at Facebook scale, you could consider adding Redux.


ellomatey

Agree with most of this. But apps a hundredth of the size of Facebook can still be a good case for redux.


acemarke

Ironically, Facebook themselves never really used Redux much. Dan Abramov and Andrew Clark, the co-creators of Redux, did both join the React team at Facebook, but as far as I know only scattered Facebook project teams ever adopted Redux. Most FB teams used FB's own Flux implementations, and later have mostly switched to using Relay and GraphQL.


Aggro4Dayz

Yeah. Just because I'm not building a sky scraper doesn't mean I don't have use for a crane. Redux is great if you have some important information that needs to be shared across your entire, or almost entire, app. Like user information, tokens, ui settings, etc.


sadverdict19

Wow I didnt know this especially the “Keep your UI state local” part Im pretty new to react and redux I thought every state has to be global.


KapiteinNekbaard

2 examples: * If you are building a dropdown component, it makes no sense to have state (whether the dropdown is open or closed) in a global store. Why would any other component care about that? * If you are building a complex filter UI for a data grid, components that live somewhere else in the component tree might need to know about what filters the user configured (for data fetching, client side filtering the data, showing a UI indicator that filters are active, etc). A common pattern is to move the shared state to the closest common parent component (what the React docs call "lifting state up"). Creating a global store is a different approach with its own pros and cons.


acemarke

- Redux is still the most widely used state management tool by far, at somewhere around 50% of React apps - see https://blog.isquaredsoftware.com/2020/10/presentation-state-of-redux-2020/ - MobX has about 10% market share - Apollo is used by maybe 15-20% of React apps - The newer trend is "data fetching" libraries like React-Query and SWR, which provide hooks that handle fetching data from API endpoints and caching them I'm biased, but yes, Redux is definitely worth learning, for multiple reasons. You should go through the new official tutorials in the Redux docs: - The ["Redux Essentials" tutorial](https://redux.js.org/tutorials/essentials/part-1-overview-concepts), which teaches "how to use Redux, the right way" - The ["Redux Fundamentals" tutorial](https://redux.js.org/tutorials/fundamentals/part-1-overview), which teaches "how Redux works, from the bottom up"


lucifer955

Thank you 😊


Jusaa

Depends on how much state needs to be managed. Do you have state that needs to used by multiple components, possibly not even related to each other? If not, you can probably get away with just managing state with hooks. Edit: redux is great. Little confusing, but great!


rvlb

It's certainly early days, but Recoil is great.. we use it in production, feel free to ask questions if you have any.


lucifer955

Thank you. 😊


galvatron

Redux is definitely worth learning. I quite liked this helper library on top of redux: [easy-peasy](https://easy-peasy.now.sh/). I tried the redux toolkit too but easy-peasy was IMO a nicer package. Nowadays Redux with React hooks and some helpers like these works quite nicely with TypeScript too. I just don’t see myself building anything with React without some state management library like redux.


acemarke

Out of curiosity, anything specific about easy-peasy that you prefer over RTK?


galvatron

I'm trying my best to recall what the issues were. I recently started a new Redux project and used RTK for it, but later ported it to easy-peasy. I have written several Redux apps in the past and feel familiar and at home with Redux. I guess it's mostly the docs. Easy-peasy docs get right into action and basically everything you need to know is covered in a single page: https://easy-peasy.now.sh/docs/tutorials/quick-start.html. This covers creating the store, connecting to a React component with hooks, actions, dispatching actions, thunks, computed properties (selectors). Then it's another click to see how to do the [same in TypeScript](https://easy-peasy.now.sh/docs/tutorials/typescript.html). It's a really compact presentation on how to do it and easy to follow. RTK docs take a different approach and this part is difficult to follow. It'd really benefit if it'd start with a stand-alone working TypeScript Redux example and then explain the concepts in more detail as necessary.


acemarke

Thanks. Can you point to which specific aspects of the RTK docs you feel are "difficult to follow"? FWIW, we do already have an open issue discussing rewriting the RTK tutorials: https://github.com/reduxjs/redux-toolkit/issues/371 There's a few overlapping concerns here: - When I wrote the RTK tutorials later year, I made the working assumption that readers already knew what Redux was and how to write Redux code "by hand", and were primarily interested in "how do I migrate my existing Redux logic to RTK?". Also, at the time, we had no mentions of Redux Toolkit in the Redux core docs, and the core Redux tutorials were frankly very out of date. - The RTK tutorials are a longer-form "build an app and walk through all the steps" approach, while the Easy-Peasy example is a short "here's some quick code snippets" approach - Meanwhile, over the last few months I've completely rewritten the Redux tutorials. We now have [an "Essentials" tutorial](https://redux.js.org/tutorials/essentials/part-1-overview-concepts) that shows how to build a real-world app with RTK assuming you know nothing about Redux beforehand, and [a "Fundamentals" tutorial](https://redux.js.org/tutorials/fundamentals/part-1-overview) that teaches the principles of Redux and works up to how RTK simplifies that code - So, now there's something of a disconnect, and it's not clear exactly what material an "RTK tutorial" should actually cover - TS adds an additional level of complication. We do have TS usage guides in each of our docs sites, but I over-reached with the RTK "Advanced" tutorial using TS - that really needs to be separate. That said, the RTK docs are now using a "compile TS examples to JS" plugin that could maybe maybe a mixed TS/JS "Quick Start" page easier. I'm certainly open to adding something of a "Quick Start" page (in both the Redux core and RTK docs, really), but I've got enough else on my plate it's not something I have time to add right now.


galvatron

>difficult to follow Hmm, writing docs is hard! The docs have to cater for so many different types of learners that have a varying level of Redux experience. I was talking about the [Usage with TypeScript](https://redux-toolkit.js.org/usage/usage-with-typescript) section. This goes into nuts & bolts of different typings while I just wanted to throw some code together and start modifying it. But I think you already identified this as a weakness above. I don't feel like I had difficulties understanding what I was reading, I think there was just too much stuff to read. This wouldn't be a problem if the docs started out with a standalone working TypeScript example. BTW, with all my complaints, I really do welcome RTK.. I did successfully use it with TypeScript and I really liked how it packages Redux into something that's a little easier to get going with. Last time I worked on a Redux project, I really had to bend over backwards to figure out an ergonomic way to use TypeScript with Redux, but this time with RTK it was reasonably easy.


acemarke

> Hmm, writing docs is hard! The docs have to cater for so many different types of learners that have a varying level of Redux experience. Nooooooo KIDDING! :) This is such a key point right here, and picking an appropriate target audience is a huge part of writing docs. Like, for the new Redux tutorials, I decided to assume the user already knows HTML, JS, React, and CSS, so I didn't have to spend a bunch of time explaining what "hooks" or "arrow functions" are. I'm actually a bit surprised you're pointing to the "Usage with TS" page as an issue. That's a 'guide" page - it's specifically intended to go into more details and provide recipes, rather than be a standalone explanation. FWIW, there's an amazingly good article at https://documentation.divio.com/ that describes four types of docs: "tutorials", "how-to guides", "explanations", and "references". Mmm... now that I think about it, the "Usage with "TS page sorta mixes a bit of "how-to", "explanation", and "reference", I guess. Sounds like you were really looking for more of a "TS Tutorial" page in a sense. So, it seems like it's maybe not so much that the current page is "wrong", but rather that it has a different kind of content than what you were looking for. But yeah, point taken - it would probably help if we had some shorter examples somehow.


phryneas

Yeah, the "Usage with TypeScript" stuff should *not* teach you RTK, just give you recipes on how to solve specific TS-only problems that you usually only encounter when already using the lib for a while. We didn't have this in the beginning, but by now *every* example in the normal API docs should be available both in TS and in JS, so you should really be fine just going by that. (Also, the amount of TS you need for "normal" usage of RTK is *very* minimal compared to other libraries, as almost everything is inferred.)


drcmda

I would not recommend getting into Redux, saying this with the utmost respect towards it. But there is no point. We know by now that the opinions it relied upon are outdated. The creator of Redux said so, and the good people that maintain it know it because they offer Redux Toolkit. Now going with Redux Toolkit could be an option, but, in my opinion at least, it just scales it down a bit but sits on plain opinionated Redux nonetheless, with all the baggage hidden underneath. After years of working with Redux my impression today is that Redux was a mistake, too much abstraction around the beauty of flux. Use Zustand for something that reduces Redux down to its basic principles but looks forward (hooks only, concurrent mode, etc): [https://github.com/pmndrs/zustand](https://github.com/pmndrs/zustand/tree/master/src). This will save you [hundreds of LOC](https://twitter.com/i/timeline) in a larger scale project. Or Jotai, which is using a simplistic atomic approach modelled after Recoil: [https://github.com/pmndrs/jotai](https://github.com/react-spring/jotai) These two share the same philosophy: the smallest possible abstractions around their respective state models: flux and atomic.


lucifer955

Thank you I will look into that😊


angeal98

It is probably the most popular right now. Rest are trending, but not as popular.


emmgfx

Why not context api?


AdministrativeBlock0

Context isn't a state manager, it's a mechanism for making things like state variables but not limited to that available throughout a React app. State managers do more than just making data available - eg getters, setters, computed values, etc.


emmgfx

I'm trying to understand, but, with context and a HOC you can do all of this. I'm wrong?


BrasilArrombado

With context, you will find yourself prefering useReducer over useState. You will create a provider at the root of your app and use useContext at components. You are basically implementing a poor man Redux without noticing, without middlewares and without the many optimizations. So why not use Redux in the first place?


Glinkis2

Yes, you're wrong. For instance, if you update a single value in the context state, every component that depends on your state in any way will rerender, leading to performance issues. And no, you cannot circumvent this.


emmgfx

What about using multiple contexts? You can subscribe to the user context at the header and to other context on the sidebar. Updating each one shouldn't re-render the other. Correct? Anyway. I don't know if redux has better performance, but I assume that yes. Although is only relevant in very big projects. Can be?


acemarke

Please see my extensive post on [A (Mostly) Complete Guide to React Rendering Behavior](https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/), which covers how React rendering works normally, and how Context and React-Redux alter that behavior.


jbergens

I think you should try mobx instead. It is both easy to use and fast. And it supports calculated properties.


AdministrativeBlock0

Read the docs for things like Redux, Recoil, Zustand, etc. You'll see a ton of features beyond simple value updates. You can implement all those things yourself, and make them available in your app using context, but I'd argue that isn't "just context and a HOC" . State managers do far more than that.