First off, I just want to say thanks for the article! I don't agree with your proposal, but it was a really interesting thought experiment to Rey to figure out why not. Redux can definitely feel like a lot of overhead, and pursuing alternatives to is awesome.
Second, if you're up for it, I'd love to hear your thoughts on my points below.
Okay, so that said, I can offer at least 3 concrete reasons why I don't believe this proposal is not scalable, mostly related to maintainability. These are my own thoughts, mostly gathered from experience.
1) You've created an implicit dependency on your application hierarchy being instantiated in a specific order. While this works great for small projects where you are the only dev, it tanks the maintainability because it requires anyone who works on it to have knowledge of that implicit dependency. This increases onboarding time, makes it harder to debug, and makes your application more brittle with regards to change.
2) The singleton component cache will exist before, and outlive, all of your components. This means that, when reasoning about your component, you now have to consider not only what the state of that cache is now, but also what it was like in the past. Again, probably fine for a small application, but this can quickly lead to very hard-to-trace bugs in a large application. This also results in components that are way harder to test, because you now have to manually tear down and set up the component cache before every test.
3) The singleton only holds a few components right now, but when you have even half a dozen devs working on a mid-sized application, the potential for naming collisions starts to increase pretty drastically. Now you have state that out lives your components and is directly changed by components from totally different contexts.
Some additional, more fluffy points:
You've created dependencies both up and down the hierarchy. This means that, if you want to change something, you now need to tear out twice the dependencies.
Using a solution that only works for singletons means that you need a second solution for everything else. Now, whenever a new dev opens a component, they first need to figure out which of the two state management systems it uses.
I would at least suggest that, rather than importing a singleton component cache, you pass your cache to child objects. It's just one argument instead of multiple. This allows you to separate contexts, makes testing easier, and at least hints to other devs that there's something extra they need to provide (though I would wager that just using React's context API is probably the best choice).
Thanks for the article! Even if I don't agree with your proposal, it's always cool to try to understand why. As said, I'd love to hear your thoughts.
I'm gonna circle back to this in a bit (hopefully, later today when I have some more time). But I wanted to drop a quick reply here to say thank you for these thoughts. It's already given me some ideas to chew on. And I've never been bothered by the fundamental idea that my technique might not be "best practice". I've been bothered by the fact that those who dismiss it have only bothered to reply with dogma and with vague notions of "industry standards" - without being able to actually say why something is-or-is-not an "industry standard".
Thanks for letting me know - I always worry when posting these kind of responses that they're not going to land right.
Also, I totally agree with your stance on dogma - if you're using something simply because it's really popular, without understanding the pros and cons, you might as well be blindly copying code from Stack Overflow (actually, I think that might be the less harmful of the two).
OK, now that I've had some time to work through some coding samples and figure some things out, I finally have time to put a "proper" reply on your well-considered points. And... I'm not going to.
Because the stuff I've figured out over the last 24 hours (with the awesome feedback of you and others on this post) really shouldn't be encapsulated in a single comment/reply. I'm gonna put this into a new blog posting.
But if you're curious about the Cliff's Notes version of what I've come up with:
My previous approach may not have been outright wrong, but I definitely understand a lot of your points, and it makes the optimal use-case for my approach extremely narrow.
This led me to reassess other approaches - including having another look at the Context API (which is what Redux uses under the covers).
I'm now convinced, with the "new"/finalized Context API, that this will definitely be my go-to state-sharing/prop-passing tool of the future.
Wow, thanks! I'm stoked you found my ramblings useful!
Your article was really thought-provoking. Also, respect for posting things you know people disagree with - that stuff terrifies me. Have fun with the Context API! I'm looking forward to your next post!
Hey Adam,
First off, I just want to say thanks for the article! I don't agree with your proposal, but it was a really interesting thought experiment to Rey to figure out why not. Redux can definitely feel like a lot of overhead, and pursuing alternatives to is awesome.
Second, if you're up for it, I'd love to hear your thoughts on my points below.
Okay, so that said, I can offer at least 3 concrete reasons why I don't believe this proposal is not scalable, mostly related to maintainability. These are my own thoughts, mostly gathered from experience.
1) You've created an implicit dependency on your application hierarchy being instantiated in a specific order. While this works great for small projects where you are the only dev, it tanks the maintainability because it requires anyone who works on it to have knowledge of that implicit dependency. This increases onboarding time, makes it harder to debug, and makes your application more brittle with regards to change.
2) The singleton component cache will exist before, and outlive, all of your components. This means that, when reasoning about your component, you now have to consider not only what the state of that cache is now, but also what it was like in the past. Again, probably fine for a small application, but this can quickly lead to very hard-to-trace bugs in a large application. This also results in components that are way harder to test, because you now have to manually tear down and set up the component cache before every test.
3) The singleton only holds a few components right now, but when you have even half a dozen devs working on a mid-sized application, the potential for naming collisions starts to increase pretty drastically. Now you have state that out lives your components and is directly changed by components from totally different contexts.
Some additional, more fluffy points:
You've created dependencies both up and down the hierarchy. This means that, if you want to change something, you now need to tear out twice the dependencies.
Using a solution that only works for singletons means that you need a second solution for everything else. Now, whenever a new dev opens a component, they first need to figure out which of the two state management systems it uses.
I would at least suggest that, rather than importing a singleton component cache, you pass your cache to child objects. It's just one argument instead of multiple. This allows you to separate contexts, makes testing easier, and at least hints to other devs that there's something extra they need to provide (though I would wager that just using React's context API is probably the best choice).
Thanks for the article! Even if I don't agree with your proposal, it's always cool to try to understand why. As said, I'd love to hear your thoughts.
Regards,
Patrick
I'm gonna circle back to this in a bit (hopefully, later today when I have some more time). But I wanted to drop a quick reply here to say thank you for these thoughts. It's already given me some ideas to chew on. And I've never been bothered by the fundamental idea that my technique might not be "best practice". I've been bothered by the fact that those who dismiss it have only bothered to reply with dogma and with vague notions of "industry standards" - without being able to actually say why something is-or-is-not an "industry standard".
No worries!
Thanks for letting me know - I always worry when posting these kind of responses that they're not going to land right.
Also, I totally agree with your stance on dogma - if you're using something simply because it's really popular, without understanding the pros and cons, you might as well be blindly copying code from Stack Overflow (actually, I think that might be the less harmful of the two).
OK, now that I've had some time to work through some coding samples and figure some things out, I finally have time to put a "proper" reply on your well-considered points. And... I'm not going to.
Because the stuff I've figured out over the last 24 hours (with the awesome feedback of you and others on this post) really shouldn't be encapsulated in a single comment/reply. I'm gonna put this into a new blog posting.
But if you're curious about the Cliff's Notes version of what I've come up with:
That's what I'm gonna explain in my next post...
Wow, thanks! I'm stoked you found my ramblings useful!
Your article was really thought-provoking. Also, respect for posting things you know people disagree with - that stuff terrifies me. Have fun with the Context API! I'm looking forward to your next post!
The follow-up...
dev.to/bytebodger/throw-out-your-r...