2 ms·

Yes, you can use the same convention in React (or rather use React with the same convention), this is mentioned in the description actually. As far as "prop dr

Yes, you can use the same convention in React (or rather use React with the same convention), this is mentioned in the description actually. As far as "prop drilling" goes, I never understood what is the problem that some people have with it. If you just put your state in one object its just one more param that you have to pass to components. Do we really need a big-ass framework just because of one extra param. Also, by passing state explicitly, you get a clear visibility over which component needs what. And it also allows you to restrict which component uses which parts of the state.

iakov 3y ago
If this convention can be used in React, what is the "no-framework framework"? What's the point? React is not "just one extra param". One thing it does and your "no-framework framework" does not is figuring out what needs to be updated when the state changes. Add some console.log statements to your components and you'll see that clicking on any button on the demo page results in all components being updated, causing update of DOM nodes. How can this possible work in a complex web page? I click on the "Close Modal" button, and every single DOM node on the page gets updated, from the menu bar down to each and every button? That's the very basic thing that React does. I am not talking about anything else, like component lifecycle or hooks. This not-framework doesn't even begin to approach what React does. If you don't want the "big-ass framework" for whatever reason, there are Inferno and Preact already. Both are great projects and have all the things a developer expects from React replacement.
- naasking 3y ago
  > If this convention can be used in React, what is the "no-framework framework"? What's the point? I think the point is a "no-state handling framework". It seems like you can combine this with something like morphdom to get React-like merging for pure DOM updates, and the state-handling is via this hierarchical approach. Or your DOM construction can be via a vDOM library which then handles the merges for you.

iakov 3y ago

If this convention can be used in React, what is the "no-framework framework"? What's the point? React is not "just one extra param". One thing it does and your "no-framework framework" does not is figuring out what needs to be updated when the state changes. Add some console.log statements to your components and you'll see that clicking on any button on the demo page results in all components being updated, causing update of DOM nodes. How can this possible work in a complex web page? I click on the "Close Modal" button, and every single DOM node on the page gets updated, from the menu bar down to each and every button? That's the very basic thing that React does. I am not talking about anything else, like component lifecycle or hooks. This not-framework doesn't even begin to approach what React does. If you don't want the "big-ass framework" for whatever reason, there are Inferno and Preact already. Both are great projects and have all the things a developer expects from React replacement.

naasking 3y ago
> If this convention can be used in React, what is the "no-framework framework"? What's the point? I think the point is a "no-state handling framework". It seems like you can combine this with something like morphdom to get React-like merging for pure DOM updates, and the state-handling is via this hierarchical approach. Or your DOM construction can be via a vDOM library which then handles the merges for you.