Rebuttal to the points raised in this article (please see details below ) ?

[sktguha]

What is the solution to the two problems mentioned in this article ? ( don't agree too much with the rest of the article though) ,

1. https://codeburst.io/the-ugly-side-of-redux-6591fde68200#fa23:~:text=The%20store%E2%80%99s%20life%20cycle%20is%20different%20from%20the%20components%E2%80%99%20life%20cycle

2. https://codeburst.io/the-ugly-side-of-redux-6591fde68200#a6cf:~:text=The%20global%20store%20is%20a%20singleton%2C%20but%20a%20component%20may%20have%20many%20instances

I have myself run into both problems personally.

[msutkowski]

Hi @sktguha!

IMO, these aren't problems, but just poor design decisions. The example of multiple shopping carts is interesting, but the concept of adding booleans to track separate carts shows a lack of understanding of best practices. I would guess that if the author revisited this subject, they'd most likely want to rewrite the majority of this. What this article doesn't address with its local state approach in the e-commerce scenario is something as simple as showing a cart total + quantity in a navbar. As soon as you do that, you're going to introduce a different state solution, so basically, every point raised here is irrelevant.

In terms of modern react-redux, you could very easily implement this exact scenario with hooks and just giving each cart a temporary id and having a slice structure like { cart: { cart_key_1: { ... attributes } } }. When the component is mounted, initialize a new a cart with the temporary key, and when it's gone, remove the cart from the store if that behavior is desired. This would solve the issues that are raised, but is still a non-realistic implementation and I wouldn't recommend doing that in most scenarios.

At the end of the day, I'm pretty sure this article is just complaining about redux boilerplate, which is mostly solved by Redux Toolkit. Judging by the last update that is quoted below, I'd just disregard this whole thing.

Update (11/09/2020): This post is pretty old now, and many things has changed since I wrote it. Today, Dan Abramov, the creator of Redux, already admits that Redux was a mistake, and Redux is loosing his popularity. Controllerim is still working and pretty much stable, but I am no longer maintaining it. My efforts are now focusing on suggesting a built-in state management solution for React itself, using Stores, Context, and local state improvements.

If you have specific issues that are relevant to what you're actively working on, I'd bring those up instead of the points in this article, as what is represented there are outdated complaints that were most likely given just to promote the author's own library. If you look at that quote above, they're now basically recommending re-implementing Redux, but most likely in a less performant manner. @markerikson has many articles on the topic of Redux vs Context that have been linked many times - here is a relevant thread from yesterday that include such links.

If you're actively in need of help with Redux best practices and implementation approaches, I'd recommend reading the latest fundamentals guide, then checking out #redux on reactiflux where there are many people that can help you.

[msutkowski]

I'd recommend taking a look at https://rtk-query-docs.netlify.app/ - it bolts right on to your existing redux implementation and has very similar features to react-query.

I can't really give too much input on your solution, but I would advise against going down that path unless you have a really good reason to. There are a lot of redux-based libraries that try to do similar things, but they're all very opinionated in their implementations and usually built for specific purposes.

In my own projects, I've moved entirely away from HOCs and connect usage. I'm biased (a collaborator on the project), but I now use rtk-query for mostly every network request and it covers everything I could possibly want to do while integrating very nicely with my existing redux codebases.

[sktguha]

Hello @msutkowski , Thanks for reply. indeed I did take a look at rtk query.
But some issues with rtk query,

1. Does it handles the clearing cache on unmount automatically (which is one of my primary requirements). I know I can dispatch the clear cache on componentWillUnmount but wanted to automate that.

2. You still have to write your own mapDispatchToProps and mapStateToProps. I believe there is a reducerPath param in the createApi API of rtk query. I want to avoid that. i.e as mentioned, I don't want to bother at all with thinking where I want to put my network request results in the Redux state and read from it (some common state field like state.privateNetworkStates.todoDisplay_some_unique_id_per_instance ), for "simple fetch some data from network and display components and invalidate cache on unmount ( and freshly fetch data when it is opened/initialised again )"

3. Also at the moment I can't use hooks. I know they are recommended by the React team but for now have to stick with class components. Hence the connect and HOC way.

[phryneas]

1. will be done by hooks,
2. in that case your reducerPath would be privateNetworkStates. Also, you don't have to ever use that again as you are provided with selectors by rtk-query
3. if you just aren't allowed to use hooks, you'll probably have to go with a HOC - in the simplest case calling it a one-off where the HOC just calls the hook (if it's technically possible but just a "style guide thing") and passes everything down to child components, in the more complex case recreating the logic of the hooks in a HOC for once.

[sktguha]

will be done by hooks,

Not sure fully, but I still have to call the clearCache method that I would get from the useQuery or something manually in my componentWillUnmount method right ?

in that case your reducerPath would be privateNetworkStates. Also, you don't have to ever use that again as you are provided with selectors by rtk-query

That's really awesome. But I don't need any of the rtk query features actually at the moment like fetching every 5 secs etc. So don't want to add it for nothing, an extra layer of abstraction.

[phryneas]

will be done by hooks,

Not sure fully, but I still have to call the clearCache method that I would get from the useQuery or something manually in my componentWillUnmount method right ?

No, hooks are lifecycle-aware. They can do stuff on mount and they can do stuff on cleanup.

[phryneas]

Adding to all this: if you have state that is created when a component mounts and should be removed when a component unmounts, that is local component state. It belongs into your component.
It was never the goal of redux to manage that data.
See the FAQ on that

[sktguha]

Anyways thanks everyone for their time in discussing this with me 🙂.

[sktguha]

Hello @markerikson , While developing my own library, I had an idea, i.e a proposed simplification of the mapDispatchToProps API,
in React-Redux connect itself.

What if instead of putting dispatch calls, the developer simply returns the action object from their mapDispatchToProps and React-Redux will call dispatch internally , i.e

OLD

import { connect } from 'react-redux';

 connect(null, (dispatch, ownProps)=>({
    fetchTodo : (...args)=>dispatch(myactions.fetchTodo({ ...args, todoId: ownPropsId}))
 }))(TodoDisplay)

NEW SIMPLIFIED

import { connect } from 'react-redux';

 connect(null, (ownProps)=>({
    fetchTodo : (...args)=>myactions.fetchTodo({ ...args, todoId: ownPropsId})
    // no need to call dispatch call from here. it will be called internally by React-Redux
    // React Redux will get the return value of the function(s)  , as fetchTodo here, and pass it on to dispatch internally
 }))(TodoDisplay)

I completely understand that there is an object shorthand form already available. But that expects a plain object and won't handle this case. I can roughly think of some benefits of this, apart from the simplification.
But first of all, what is your initial thoughts on this ?
cc @phryneas @msutkowski

[phryneas]

The connect API is an API that is used by probably by millions of code bases and thousands of tutorials. I don't see any way of introducing any breaking change there that would not be extremely confusing.

Also, we are recommending to use the hooks as the way to use react-redux. While the connect API will no go away, it is very unlikely to see any changes in the future, as it is more of a legacy tool than something we'll actively put time in. We expect class components to go away more and more, and thus this API being used less & less (granted, this can still be used for some edge cases like what you are doing, but for that it already does everything that is needed).
The only updates I see it getting are necessary updates to keep it working with future versions of react.

[sktguha]

Oh all right understood. btw I was not suggesting making any breaking change. But find some way so that it is not breaking.

But ok I get your point.

[sktguha]

Hi @phryneas , this is the example usage of the library that we had discussed earlier here. Calling it simply redux-simplifier now.
will integrate RTK Query in future to it.
https://gist.github.com/sktguha/3bbfdd5b8cbdfc4dfa6dd609060edb4d
I have not covered the middleware or reducer integration here. but those are one time only

I am using it in my project at work and in process of talking to other teams also to integrate it.
Please let me know any comments/feedback/criticism 🙂 and thanks for your time again for the earlier discussions.