react-redux VS reselect

redux with react-redux

Redux

react-redux : Integration with React

You should think about using some client state management libraries like Redux. Redux gives you the possibility to encapsulate states and manipulate it through functions. https://react-redux.js.org/

`useSyncExternalStore` was shipped live in React 18.0 and is fully ready for production use.

Source: I'm the primary Redux maintainer, and worked with Andrew Clark of the React team to nail down the semantics and behavior needed by `useSyncExternalStore` in practice. They had the idea, but discussed a lot of the necessary use cases with us and other lib maintainers, and a lot of its internal implementation is directly related to how React-Redux's `useSelector` hook was implemented already.

I built the first working code that used it by prototyping React-Redux v8's switch from our own internal subscription handling to `useSyncExternalStore` instead and gave Andrew feedback:

- https://github.com/reduxjs/react-redux/pull/1808

State Management with Redux

Redux is a popular state management tool that can be used in conjunction with React to manage the state of an application. It works by implementing a unidirectional data flow, in which actions are dispatched to a central store, which then updates the state of the application and sends the updated state back to the components that need it.

tl;dr; Previously here, I wrote about how to write a modern web application using Rails as a full-stack framework. Just writing HTML and Vanilla Javascript. Now we will go ahead creating a React client App using NextJs. The existing API has the following endpoints: GET /api/kit/products(.:format) POST /api/kit/products(.:format) GET /api/kit/products/:id(.:format) PATCH /api/kit/products/:id(.:format) PUT /api/kit/products/:id(.:format) DELETE /api/kit/products/:id(.:format) Enter fullscreen mode Exit fullscreen mode In the new project, we have the same screen as before: We have a lot of customized components: src/components/ ├── Form │ ├── Actions.tsx │ ├── Input.tsx │ └── index.tsx ├── Layout │ ├── Page.tsx │ ├── Sidebar.tsx │ └── index.tsx ├── Loading.tsx ├── LoadingOverlay.tsx ├── Notification.tsx ├── Products │ ├── Form.tsx │ └── Sidebar.tsx └── SearchList ├── Form.tsx ├── ListItem.tsx └── index.tsx Enter fullscreen mode Exit fullscreen mode But our pages are simple and short. For example, take a look at the products page code: Highlights **NextJs is just a choice, not a requirement **The API made using Ruby on Rails is completely independent of the Next JS client application developed with NextJs. You could use any RESTfull client application to consume the existing API. In my project, I am using the NextJs project as a subfolder of my Rails repository, but you could put it anywhere. Why Next JS **I already worked with React Router and React Navigation, but when I knew the **Next/Router and all related features, as the **Next/Link**, I loved it. We can use partial load and caches. Get more info here. **Conventions **You can create your own convention for your own projects. But, in my opinion, it is beneficial to use a convention that is popular and validated in production by many other developers. Like Ruby on Rails, NextJs gives you a directory structure, core resources (link, routes, image, etc.) and rich documentation. **SSR **After to create a few projects using SPA, it doesn’t seem to me a good choice for big projects. So, for now, I am using SSR with NextJs. The main use of SSR is to improve the SEO, but like this approach to offer the a better UX. **React Query is the link between the Rails and NextJs **Working together with Axios (my code), it is a great option to consume the REST API (and GraphQL). You have the access to: isLoading, isError, data, error, and others. It is a very easy way to load data and rescue errors. **React Context **I don’t like https://react-redux.js.org/, it brings a complexity to the project that I don’t think soo is a good thing. But we can use the React Context and React Reducer to offer a store and events to manager states of the application. You can see the it on the project here https://github.com/raphox/rails-7-fullstack/tree/nextjs/frontend/src/contexts/products. *React components with namespace **It is something that I learned recently. I used it in my project to offer a way to override children of some components and prevent to set many properties throth the parent. Like in the following code: In the previous code, we have the namespace *SidebarPrimitive with nested Root, Header, and List components. I am using the Root component to wrap the content and I am passing the props to the respected child. **Tailwind **There are controversies related to it, but trust me, create a project using it and make sure that you don’t like or love it. Dependencies: https://tailwindcss.com/ “Tailwind CSS works by scanning all of your HTML files, JavaScript components, and any other templates for class names, generating the corresponding styles and then writing them to a static CSS file.” https://www.radix-ui.com/docs/primitives/utilities/slot “Merges its props onto its immediate child.” https://tanstack.com/query/ “Powerful asynchronous state management for TS/JS, React, Solid, Vue and Svelte” https://axios-http.com/ “Axios is a simple promise based HTTP client for the browser and node.js. Axios provides a simple to use library in a small package with a very extensible interface.” https://github.com/lukeed/clsx “A tiny (228B) utility for constructing className strings conditionally.” https://lodash.com/ “A modern JavaScript utility library delivering modularity, performance & extras.” https://react-hook-form.com/ “Performant, flexible and extensible forms with easy-to-use validation” https://github.com/jquense/yup “Yup is a schema builder for runtime value parsing and validation. Define a schema, transform a value to match, assert the shape of an existing value, or both.” The project rails-7-fullstack/frontend at nextjs · raphox/rails-7-fullstack External references: https://www.typescriptlang.org/ https://www.radix-ui.com https://reactjs.org/docs/context.html https://medium.com/@kunukn_95852/react-components-with-namespace-f3d169feaf91

Sorry, that is correct. I was combining Redux toolkit with React Redux In my head.

if you have a more complex component hierarchy, and the component who receives the DB response is not on the top, you might consider introducing a State management tool, such as Redux: https://redux.js.org / https://react-redux.js.org

reselect -> For making faster queries to store.

Reselect solves this problem by memorizing the values and only passing what’s necessary.

reselect : Selector library to optimize your store access

Reselect documentation:

Reselect is a library for creating memoized “selector” functions. Commonly used with Redux, to slice state and provide just the necessary subtree to a React component.

For the redux part, you need to use two hooks. The first one is for sending data and that is useDispatch and for getting data from redux is useSelector. This link will help you a lot. The only that left is Reselect concept. The thing with redux is that when you update one state inside of the redux store the whole thing updates itself so basically it may cause you to re-render your components. Reselect will prevent that but it's a little bit advanced topic whenever you were comfortable enough with redux I suggest you learn to use reselect. Other than these Really good work with the project.😉👍 welcome to the community. 😁

At my current client we're working on having a frontend architecture for writing SPAs in JavaScript similar to re-frame's one: an event-driven bus with effects and coeffects for state management[1] (commands) and subscriptions using reselect's selectors (queries).

Heh, it's amusing to see Redux Toolkit referenced here. I'm one of the two main RTK maintainers. My co-maintainer Lenz Weber is responsible for most of our TS type wizardry.

Agreed that writing TS types for libs can be a pain. I actually did a talk recently on "Lessons Learned Maintaining TS Libraries" [0], where I talked about some of the techniques we used, and some possible TS changes that would be helpful for us as maintainers.

As one recent example, TS made a change in a 4.8 pre-alpha that broke RTK's `createSlice` types. Lenz tried to come up with a fix, couldn't, and had to add a workaround to check what TS version is being used and specifically use an altered type. Since there _isn't_ a good way to know what TS version is being used, Lenz resorted to hacking together a new package that abuses the `typesVersions` property to define a different TS type for _every_ TS major+minor version combo, and then used that to decide what the RTK type should look like conditionally [1].

Another pain point is debugging type transformations. I reworked the Reselect types in 4.1.x to do a much better job of inferring the argument types for the final selector, based on the intersection of all the input selector arguments. This ended up as a monstrous type that does a types-level map + transpose + intersection [2]. It took me weeks to get this working right, and I frequently had to break it down into multiple small intermediate types to see how TS was processing each step.

I know that someone on Twitter was recently working on an alternate TS type-checker based on bytecode, and they said they had some kind of a working types-level debugger [3]. Having something like that officially, where I could see each step of how TS was transforming the types, would be _hugely_ valuable.

There's a couple folks like AndaristRake who are able to dig into the internals of the TS compiler itself to trace how it's interpreting the types. I definitely don't have that ability :)

[0] https://blog.isquaredsoftware.com/2022/05/presentations-ts-l...

[1] https://github.com/reduxjs/redux-toolkit/pull/2547

[2] https://github.com/reduxjs/reselect/blob/v4.1.5/src/types.ts...

[3] https://twitter.com/MarcJSchmidt/status/1539787500788613120

We do a _lot_ of this in the Redux library repos (examples: [0] [1] [2] ). We have some incredibly complicated types in our libraries, and we have a bunch of type tests to confirm expected behavior.

Generally, these can just be some TS files that get compiled with `tsc`, but it helps to have a bunch of type-level assertions about expected types.

I actually recently gave a talk on "Lessons Learned Maintaining TS Libraries" [3], and had a couple slides covering the value of type tests and some techniques.

[0] Redux Toolkit's `createSlice`: https://github.com/reduxjs/redux-toolkit/blob/9e24958e6146cd...

[1] Reselect's `createSelector`: https://github.com/reduxjs/reselect/blob/f53eb41d76da0ea5897...

[2] React-Redux's `connect`: https://github.com/reduxjs/react-redux/blob/720f0ba79236cdc3...

[3] https://blog.isquaredsoftware.com/2022/05/presentations-ts-l...

While Reselect has always been a separate library from Redux itself, it's in our Github org. The previous maintainer had to stop working on it, so a couple months ago we did some major updates to Reselect. Reselect 4.1.x has huge improvements to its TS types for better inference, and adds a new set of customization options like cache sizes > 1.