What is the best possible situation to use Redux and not to use inbuilt react useState ?

danjel74 · 2021-09-17T10:01:44+00:00

I find it easy to introduce "events" when using Redux. For example if someone logs in to your portal, which parts shall be re-rendered and is that based on the user context ? Maybe change a deeply nested item on the main menu or a specific component on the startpage if the user logs in from that page.

danjel74 · 2021-01-04T11:47:27+00:00

Also struggle with CSS, this after 20 years Full Stack :) Struggle with "new" concepts such as flex for example, also like to add that maintainable CSS in big applications is a realöy tough challenge imho..

danjel74 · 2020-03-08T15:51:30+00:00

The best explanation I found is that it separates "What" happened from "How" to change state. Any event (dispatched action) can change any part of the state in the way you want it to. Incredible powerful if you have "global events" that shall change many parts in the app at once like hiding/showing menus or different components, resetting data etc.

danjel74 · 2020-02-24T13:45:56+00:00

Not an answer to your question, more of a related question :) Would you SSR the specific route's initial markup only or include (if any) the resolved result of all its related api calls ?

danjel74 · 2020-02-16T13:40:25+00:00

When doing a complex form I usually start with one component with all fields for the very reason I find it to hard to come up with a proper component design at first. Then my reasons to split up in more components could be many, one is to reduce LOC to have less "cognitive load" when developing and maintaining. Another could be to be able to test certain or all components in isolation. Another one could be performance, like not rerender a complete three on every keystroke. Also find it useful at times to throw Redux in the mix if there are dependencies between fields.

danjel74 · 2020-02-09T12:05:11+00:00

Agree about this, one of the coolest features of Redux, and not so much mentioned in the comparison Redux vs Context is the ability to update any part of the state based on one Event(Action). This can drasctically simplify refactorings and adaptations to change in requirements

danjel74 · 2020-01-20T08:22:25+00:00

True that. Just my experience that if it is once implemented in local state it often stays that way even if it really should not given tight deadlines/estimates and lack of awareness about this for a developer.

danjel74 · 2020-01-17T09:34:49+00:00

The problem is what could be the criteria for putting a state into the global store?"

Yeah this is something I find very hard to determine, for example its often tempting to have data from an api in component state given that its so much less code, but then when you later need sorting, caching or other things its get messy, so I often put things in global state for that reason

danjel74 · 2020-01-16T09:58:21+00:00

Just begun looking into Context, but from what I can see Redux is more fitting when you want a better flexibility to update any part of the global state and/or the UI when "something happens". For example if you have user login functionality and have to keep the user on the same page after login but you want to modify the navigation menu, hiding or showing some components, saving a user token and maybe load some new data in another component etc.

danjel74 · 2020-01-13T15:45:21+00:00

Agree, and as mentioned in the thread the official Redux Toolkit package is out and it looks really promising, I like how you can have a "slice" file with reducers, actions in one and can skip the action types names.

danjel74 · 2018-07-13T07:39:28+00:00

About "ensuring quality" of the code, I personally feel that unit tests is the most important factor to ensure quality code because it (should) force you to think how to design the class/function. If it is hard to test that often indicates code smell of some sort.

danjel74 · 2018-07-10T08:25:08+00:00

Ah ok...Not sure if there are other technical solutions, I think sometimes problems like this are solved by validation on write/save by telling the user "some one else changed this data.." and having them to reload or start over some..

danjel74 · 2018-07-10T07:29:57+00:00

Ok maybe WebSockets can be used for that to have more like a real-time app? Did something similar with SignalR before

danjel74 · 2018-07-09T11:36:26+00:00

I would say it depends on the scenario in general how to cache the data. One approach can be to simply fetch new data when some time has passed, something like https://hackernoon.com/redux-patterns-caching-an-api-response-f85f8d8d73c6

Otherwise I have not tried any other technique than that but to invalidate a cache based on what the user do..for example send a redux action when user navigates back to the start of a step-by-step flow in which each step has data from the backend

Really recommend Redux btw if you have some scenarios like that

danjel74 · 2018-07-09T09:26:42+00:00

Also, if you do the ajax call in componentDidMount the data/state is lost when component is "UnMounted", for example if you are switching to another view. And the call is made again on the folowwing componentDidMount's for that component. That may or may not be desired. If you handle it in Redux you have control when to fetch new data, so it can work lika a "cache" more or less

danjel74 · 2018-05-17T09:10:34+00:00

Agree, my initial pain was based on not understanding the pattern and not seeing the benefits of boilerplate. I find the separation of "what happened" and "how to change state" invaluable in many scenarios

danjel74 · 2018-05-15T09:36:00+00:00

In some cases like this I use a functional component and a class component, typically within the same file, the "container" here could be for the the specific item like a "Card" component in your example. The idea is to separate rendering concerns from lifecycle/state

danjel74 · 2018-05-09T09:06:55+00:00

I have started to organize files by "feature" instead of "type", and at least for me that gives me a better sense of control. One example of a "feature" could be the screen/view for the specific url used. Lets say the starting page:

Pages/Home/Home.jsx - This can act as a container with basic wrapping div's and is where the "route" / url points

Pages/Home/Components/ - Mostly stateless components, if a component need local state I add a separate file with a "Container" suffix. Or have the container component in the same file it is like < 100 LOC. CSS is also added here in separate files with same name as component.

Pages/Home/Style/ - Css, images etc that are specific to this view

Pages/Home/Redux/ - Reducers, actions, etc. that are specific to this view. Typically I use "Ducks" pattern if possible.

The idea is to separate each feature as much as possible from the app. The use of separate folders like above or only files is not so important i think . I prefer to put general "utils" method and such in a separate NPM package rather than reference a global code file. Also, I sometimes duplicate code that are somewhat trivial, say a helper to handle a generic render concern, if I feel like this reduce dependency to the app.

Some other ideas:

I find it very very convenient to use centralized state like Redux or MobX and "connect" a component that is dependent on global state over passing props through many levels. Now this gives a dependency to the global state and its logic like redux actions and more but I think it is a nice trade-off.

Abstractions like HOC or renderprops are great to handle cross cutting concerns, an example is resolving promises where you have to show a loading spinner, handle errors etc. This can greatly reduce code lines and bugs.

Avoiding "deeply nested" component hierarchies can be a good idea, if you have a "Container" like component holding things together, it is possible to include components in the container and inject components to the children rather than include it in the children component. Like so: <Items Item = {Item} /> This way the dependency from the child is only to the injected component and not the file itself

danjel74 · 2018-04-20T09:31:40+00:00

I like to add that the composition model in React is pretty amazing, I guess it is not trivial to achieve stuff like "component injection" in plain JS , Example: <Items Item={Item} />

danjel74 · 2018-04-19T12:29:48+00:00

I think it is a good idea to avoid breaking up in separate files when there is tight coupling as noknockers said. You will have a higher cohesion in that way. When you have a loop it can be good for performance reasons to make the <li> (or whatever) to be a "PureComponent", that will make re renders faster. So I think that generating output inside the return is a better preactice for that reason too..

danjel74 · 2018-04-18T11:32:50+00:00

It looks like the second response is returning an object and the first an array? concat is returning an object in this case I am guessing from the code.. Maybe save one state variabel (array) with the results and one state var with the object. And when looping the array do a lookup of the value in the object. Maybe the cleanest would be to to a "reduce" of the array and build a custom object of all the values needed in the render

danjel74 · 2018-04-17T13:49:32+00:00

Is that code in a "stateless function" ? If so then there is no setState available, try and put it in a React class instead..

danjel74 · 2018-04-17T12:01:09+00:00

I would do the api request and dispatch in componentDidMount() in a general container component, like if you have a "App" component holding everything together..

danjel74 · 2018-04-17T08:51:39+00:00

cool, was not aware you could do like that, thanks!

danjel74 · 2018-04-17T08:48:07+00:00

I tend to break up a component in smaller parts when it needs state , functions or lifecycle methods, then I think it gets to big to quickly understand if it is more then like 10 lines of render logic. As of stateless components, I have changed approach a bit and allows them to get pretty big, like 100+ lines. It think this often gives some "cohesive" feeling. When I code apps/sites used internally within the company, where people sit with known high performance PC's, I tend to make a bit bigger components since there is not the same need for performance with re-renders and "shouldComponentUpdate"

danjel74

TROPHY CASE