Here's the scenario when I realized that I needed to study and apply redux.
I was working on a react project - it was actually my first - and at some point in an absolute maze of components, I realized there was a need to throw a certain stateful value from a component to another component, which was 5 components up the tree and 4 down.
Eventually I ended up throwing the value up the project tree until I did exactly that.
Now if I knew how to use redux, it would have been almost as easy as declaring a global variable(in some sense)
Of course using redux in all these cases is not an optimal design pattern and taking into account of these cases before you begin a project is a better approach.
But that was when the need occurred for me in my case.
The usual use case would be (in my experience) keeping user tokens/credentials, pretty much any dynamic value that needs to be accessed in most parts of the project.
And I don't mean to refute your statement that context provider will do the trick - it's true.
I believe the true value of redux is shown in terms of DX(Developer eXperience). The debugging tools are far superior to any other state management tools I've heard of. Which is probably why it is so widely used.
Hi 👋
I'm Jesco, software consultant, digital nomad and currently trying to build my own learning platform.
If you have any feedback please tweet at me @jescowuester
Interesting. I get the use case that you described above but I think in most cases that can be solved by structuring your components in a somewhat nicer way :D.
In my personal opinion, pure context has better dx than redux. I usually declare a provider like userProvider and a hook like useUser and then its pretty easy to consume the context.
I did use redux for nearly a year and in most cases it was just a burden, it came in handy once when I made a online photo editor but I figured that that's hardly a common use case :D
When I was refering to DX, I believe I might not have been specific enough. Yes I agree setting up redux is a pain and definitely has a steeper learning curve. And in that sense the DX is worse. The DX that I was referencing to was debugging code when projects get larger.
It can get increasingly difficult to do so as projects begin to get too large to even trace what's going on in where - especially when multiple developers are working on a single project.
In this scenario, redux is a god-send and I believe it has saved me countless hours of debugging because of redux's robust features when it comes to logging and debugging.
In small projects, I couldn't agree more that redux can feel a bit bloaty :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Here's the scenario when I realized that I needed to study and apply redux.
I was working on a react project - it was actually my first - and at some point in an absolute maze of components, I realized there was a need to throw a certain stateful value from a component to another component, which was 5 components up the tree and 4 down.
Eventually I ended up throwing the value up the project tree until I did exactly that.
Now if I knew how to use redux, it would have been almost as easy as declaring a global variable(in some sense)
Of course using redux in all these cases is not an optimal design pattern and taking into account of these cases before you begin a project is a better approach.
But that was when the need occurred for me in my case.
The usual use case would be (in my experience) keeping user tokens/credentials, pretty much any dynamic value that needs to be accessed in most parts of the project.
And I don't mean to refute your statement that context provider will do the trick - it's true.
I believe the true value of redux is shown in terms of DX(Developer eXperience). The debugging tools are far superior to any other state management tools I've heard of. Which is probably why it is so widely used.
Trust me, reduxing pays off Jesco :)
Interesting. I get the use case that you described above but I think in most cases that can be solved by structuring your components in a somewhat nicer way :D.
In my personal opinion, pure context has better dx than redux. I usually declare a provider like
userProviderand a hook likeuseUserand then its pretty easy to consume the context.I did use redux for nearly a year and in most cases it was just a burden, it came in handy once when I made a online photo editor but I figured that that's hardly a common use case :D
When I was refering to DX, I believe I might not have been specific enough. Yes I agree setting up redux is a pain and definitely has a steeper learning curve. And in that sense the DX is worse. The DX that I was referencing to was debugging code when projects get larger.
It can get increasingly difficult to do so as projects begin to get too large to even trace what's going on in where - especially when multiple developers are working on a single project.
In this scenario, redux is a god-send and I believe it has saved me countless hours of debugging because of redux's robust features when it comes to logging and debugging.
In small projects, I couldn't agree more that redux can feel a bit bloaty :)