I think the alternative to prop drilling is to have the presentational components largely for styling and layout while filling them with children and other components by props from a more central location higher up the tree like the page level. (So these components are “open”, like you use the browser provided html5 elements; few attributes, lots of children)
You have the state largely centralized per page and removed most prop drilling from the equation.
State locality becomes clear, low amount of indirection, and there’s a clear approach where state is managed and attached (even with redux I personally don’t like the idea that deeply nested components get “connected”)
You can then instead use context for more shared or global-esque state and reusable behaviors, and avoid the indirection and complexity of state containers.
I find what you are saying interesting. I'm just wishing I could see some significant code to represent it. Did you produce a little project anything recently that you'd be able to share that represents current thoughts? Most examples are very terse and I wish that sometimes people happened to have a recent project that someone could review to learn from rather than a few lines of code. Please and thank you
That would be awesome! Thank you. Can I request that the code to review is more than just 4 or 5 lines completely out of context. Would be awesome if there were samples in a post and then a link to a GitHub that relayed a larger more inclusive context to review. That's so so rare and that would be awesome to see especially in the subject we are discussing
Alright, that's a bit of a tall order for a first time blogger and a larger topic ;-)
However I started a post series, the first one just landed: dev.to/patroza/component-vs-prop-d...
I will try to expand on it in the next one, i'm considering to use your "hypothetical" application as a basis.
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.
I think the alternative to prop drilling is to have the presentational components largely for styling and layout while filling them with children and other components by props from a more central location higher up the tree like the page level. (So these components are “open”, like you use the browser provided html5 elements; few attributes, lots of children)
You have the state largely centralized per page and removed most prop drilling from the equation.
State locality becomes clear, low amount of indirection, and there’s a clear approach where state is managed and attached (even with redux I personally don’t like the idea that deeply nested components get “connected”)
You can then instead use context for more shared or global-esque state and reusable behaviors, and avoid the indirection and complexity of state containers.
I find what you are saying interesting. I'm just wishing I could see some significant code to represent it. Did you produce a little project anything recently that you'd be able to share that represents current thoughts? Most examples are very terse and I wish that sometimes people happened to have a recent project that someone could review to learn from rather than a few lines of code. Please and thank you
I'm preparing a post. Hopefully ready within a week.
That would be awesome! Thank you. Can I request that the code to review is more than just 4 or 5 lines completely out of context. Would be awesome if there were samples in a post and then a link to a GitHub that relayed a larger more inclusive context to review. That's so so rare and that would be awesome to see especially in the subject we are discussing
Alright, that's a bit of a tall order for a first time blogger and a larger topic ;-)
However I started a post series, the first one just landed: dev.to/patroza/component-vs-prop-d...
I will try to expand on it in the next one, i'm considering to use your "hypothetical" application as a basis.