This article would be fantastic.... if it had released 2 years ago before Redux Toolkit came out, which sorted out the boilerplate issue for the most part.
I'd hesitate to call this a more scalable solution than something like Recoil or Redux Toolkit since you still need to have a deep understanding of how context affects rendering and performance. And it's why context will always be better suited for sharing primarily static data that won't change, as opposed to a state management tool. Not to mention that it doesn't account for any of the more advanced state management features like middleware and async operations.
This seems great for prototyping small to medium size projects, but not much else. Still, it's definitely neat and worthwhile mentioning. Too many people feel like they need to use a massive state management library like Recoil or Redux for their hobby project when something leaner could be enough.
I wouldn't say that REDUX scales perfectly with big projects. Having one huge state is not always ideal, especially in cases when you have multi page app, then you have parts of your state, which are completely useless for some pages, but they can still ask data from there, because the state is global. I feel, that having limited context provided only to e.g. one page, scales much better as other pages can't access it even if they want to.
Having one huge state is not always ideal, especially in cases when you have multi page app, then you have parts of your state, which are completely useless for some pages, but they can still ask data from there, because the state is global.
Why would state "ask for data" if the pages are not being used? This sounds less like a Redux problem, and more like an architectural problem caused by bad developer planning. Redux state not-in-use doesn't affect memory or performance in any measurable way. And if it does, it's because you probably are doing some kind needless logic somewhere which could also be caused using the limited context pattern.
I feel, that having limited context provided only to e.g. one page, scales much better as other pages can't access it even if they want to.
This isn't a benefit exclusive to limited context. You can achieve the same results by having individual reducers for each page and not subscribing to global changes from other pages. If you want to have state that can't be accessed by other pages... maybe just don't access it from other pages? You make it sound like because it's global, you are forced to use it everywhere and that's just not true.
What confuses me the most, is your article basically ends with you building a lighter, but more limited version of Redux by combining Context + useReducer + use-context-selector. You basically re-invented the modern wheel, except it's lighter, but harder to repair and can only drive on certain roads (and not very fast). Which is great and impressive as a learning exercise, don't get me wrong. But it's missing important key functionality from global state management systems such as middleware, async operation handling, among other things. And calling it a "redux replacement" is a bit of an overstatement.
Other than that, it's a good first article on Dev.to, congrats!
Sure, it really depends on the project though. I understand that in long lasting projects it is really important to have some strong foundation, where REDUX can give you that, it's a tested approach and you know that it won't kick you.
In our case we wanted to be efficient and reduce unnecessary boilerplate, while keeping the performance and the fact that you can build it yourself pretty easily was quite amazing for me :)
That's fair! I agree that Tolgee seems like a rather simple app where perhaps Redux would have been overkill. Kudos to you for taking the initiative and building your own state management solution, I agree it was probably a fun learning experience.
My feedback was merely directed at that this wasn't a viable solution for Redux for anything larger than small projects 😅 Thanks for understanding. Have a good day!
I don't know what is the size apps you usually build, but I wouldn't say that Tolgee is simple app. Actually we decided to stop using Redux, because it grew too much. ⚰️
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.
This article would be fantastic.... if it had released 2 years ago before Redux Toolkit came out, which sorted out the boilerplate issue for the most part.
I'd hesitate to call this a more scalable solution than something like Recoil or Redux Toolkit since you still need to have a deep understanding of how context affects rendering and performance. And it's why context will always be better suited for sharing primarily static data that won't change, as opposed to a state management tool. Not to mention that it doesn't account for any of the more advanced state management features like middleware and async operations.
This seems great for prototyping small to medium size projects, but not much else. Still, it's definitely neat and worthwhile mentioning. Too many people feel like they need to use a massive state management library like Recoil or Redux for their hobby project when something leaner could be enough.
redux toolkit is not clean or can claim it uses less boilerplate than, recoil, valtio or similar state managers.
I wouldn't say that REDUX scales perfectly with big projects. Having one huge state is not always ideal, especially in cases when you have multi page app, then you have parts of your state, which are completely useless for some pages, but they can still ask data from there, because the state is global. I feel, that having limited context provided only to e.g. one page, scales much better as other pages can't access it even if they want to.
Why would state "ask for data" if the pages are not being used? This sounds less like a Redux problem, and more like an architectural problem caused by bad developer planning. Redux state not-in-use doesn't affect memory or performance in any measurable way. And if it does, it's because you probably are doing some kind needless logic somewhere which could also be caused using the limited context pattern.
This isn't a benefit exclusive to limited context. You can achieve the same results by having individual reducers for each page and not subscribing to global changes from other pages. If you want to have state that can't be accessed by other pages... maybe just don't access it from other pages? You make it sound like because it's global, you are forced to use it everywhere and that's just not true.
What confuses me the most, is your article basically ends with you building a lighter, but more limited version of Redux by combining Context + useReducer + use-context-selector. You basically re-invented the modern wheel, except it's lighter, but harder to repair and can only drive on certain roads (and not very fast). Which is great and impressive as a learning exercise, don't get me wrong. But it's missing important key functionality from global state management systems such as middleware, async operation handling, among other things. And calling it a "redux replacement" is a bit of an overstatement.
Other than that, it's a good first article on Dev.to, congrats!
Sure, it really depends on the project though. I understand that in long lasting projects it is really important to have some strong foundation, where REDUX can give you that, it's a tested approach and you know that it won't kick you.
In our case we wanted to be efficient and reduce unnecessary boilerplate, while keeping the performance and the fact that you can build it yourself pretty easily was quite amazing for me :)
That's fair! I agree that Tolgee seems like a rather simple app where perhaps Redux would have been overkill. Kudos to you for taking the initiative and building your own state management solution, I agree it was probably a fun learning experience.
My feedback was merely directed at that this wasn't a viable solution for Redux for anything larger than small projects 😅 Thanks for understanding. Have a good day!
I don't know what is the size apps you usually build, but I wouldn't say that Tolgee is simple app. Actually we decided to stop using Redux, because it grew too much. ⚰️