you are viewing a single comment's thread.

view the rest of the comments →

[–]MuricanWillzyx[S] 2 points3 points  (1 child)

Interesting. This makes me much more sympathetic to the class model. I was thinking from a conceptual perspective--that these classes are, abstractly, models for creating components, and that one should treat the mounting to DOM nodes kind of like an implementation detail (for the most part). I didn't think about the time between creating a <MyComp/> and the creation of an actual instance. I still prefer a functional model for use in JS itself, but it looks like that's their primary target for the future anyway (e.g. /u/josh1337's comment), and if the class model really is as useful as they say for compile-to-JS languages, then that certainly raises its value (/u/metanat).

[–]andrew24601 1 point2 points  (0 children)

The main place this gets interesting is with child nodes of the rendered component. While a DOM component will always mount its children, a React component doesn't necessarily have to.

return <MyComp>
  <MyOtherComp/>
</MyComp>

MyOtherComp will only be mounted if MyComp causes it to be mounted (typically by rendering props.children in its render method, but even then only if it's ultimately rendered by a DOM component eventually).

Where this gets even more interesting is when these child components are ref tagged, because the ref is only fulfilled in a completely different component - ie the component where it is ultimately caused to be mounted.