-
Notifications
You must be signed in to change notification settings - Fork 47k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify v15.0.0 changelog note about JS component klasses #6496
Conversation
The change is that you can no longer do `class Hello {}` vs `class Hello extends React.Component`; you can still do `function Klass () { return {render} }`.
@jmm How about this as an alternate wording:
My changes bolded for visibility, real copy should retain standard formatting. Adds "ES2015" qualifier to class component, and removes |
@jimfb Thanks for the feedback.
Hmm, sorry about that, I was trying to make it more precise. I have to admit that I find the React vocabulary pretty woolly. Referring to stateless functional components in particular is very awkward. It's also confusing that so many terms are used somewhat interchangeably: I'd appreciate if you could tell me where I went wrong with the React vocabulary. Consider these examples:
To me this language is confusing because:
function SFC (props) { return element; } // <= function
React.createClass(opts) // <= function, class, ReactClass
function () { return {render}; } // <= function, ReactClass
class Child extends React.Component {
} // <= function, class, ReactClass, ES2015 class
What would this mean?:
Is that describing a scenario like this?: var Child = class extends React.createClass({render}) {
/* ... */
} |
They're not entirely interchangeable. It's like the difference between a square and a rectangle. Technically, all squares are rectangles, but not all rectangles are squares. Similarly, a
Part of the problem/ambiguity is inherent in the english language. For instance, you mention that a ES2015 and
Anything still confusing about this draft? |
Yes, that's why it's important to have terminology that clearly communicates what concept it's referring to. For example, this:
A component instance ( I think all of this can be expressed in English, but it's certainly easy to lose clarity when writing about stuff like this, especially without well defined terms. Right now there are too many terms that are too vague, inconsistent use of terms to refer to the same things, and too many things referred to imprecisely by the same terms.
👍 👍
That would be helpful. This illustrates why it's difficult to precisely use React vocabulary. As much as possible I try to use the terminology from React (Virtual) DOM Terminology since it defines specific terms — that aren't easily mistaken for high level concepts or references to the general meaning of a word — for concrete interfaces. That has a definition for
This is an example of what I mean that the current terminology makes these very awkward to refer to. "stateless function" for example doesn't even make sense, but I've been tempted to say it too for lack of a better option.
I think its going to be very confusing to have both
Ok, thanks. I got the impression that #5884 actually removed the ability to create a plain ES5 JS component "class" and it seemed like that's what the changelog was describing by referencing both of those.
Short of having a better vocabulary to describe this stuff I think just omitting some of the vaguer usage of
It's up to you though. When I read the changelog and created the PR it seemed to me like a straightforward issue: that behavior changes from #5884 were logged and then undone in #6008 without being reflected in the log, but maybe I misunderstood or it's more complicated. |
This sentence structure still feels awkward to me. How about:
So the paragraph becomes:
|
@@ -15,7 +15,7 @@ | |||
- **`data-reactid` is no longer on every node.** As a result of using `document.createElement`, we can prime the node cache as we create DOM nodes, allowing us to skip a potential lookup (which used the `data-reactid` attribute). Root nodes will have a `data-reactroot` attribute and server generated markup will still contain `data-reactid`. ([@spicyj](https://github.com/spicyj) in [#5205](https://github.com/facebook/react/pull/5205)) | |||
- **No more extra `<span>`s.** ReactDOM will now render plain text nodes interspersed with comment nodes that are used for demarcation. This gives us the same ability to update individual pieces of text, without creating extra nested nodes. If you were targeting these `<span>`s in your CSS, you will need to adjust accordingly. You can always render them explicitly in your components. ([@mwiencek](https://github.com/mwiencek) in [#5753](https://github.com/facebook/react/pull/5753)) | |||
- **Rendering `null` now uses comment nodes.** Previously `null` would render to `<noscript>` elements. We now use comment nodes. This may cause issues if making use of `:nth-child` CSS selectors. While we consider this rendering behavior an implementation detail of React, it's worth noting the potential problem. ([@spicyj](https://github.com/spicyj) in [#5451](https://github.com/facebook/react/pull/5451)) | |||
- **Functional components can now return `null`.** We added support for [defining stateless components as functions](/react/blog/2015/09/10/react-v0.14-rc1.html#stateless-function-components) in React 0.14. However, React 0.14 still allowed you to define a class component without extending `React.Component` or using `React.createClass()`, so [we couldn’t reliably tell if your component is a function or a class](https://github.com/facebook/react/issues/5355), and did not allow returning `null` from it. This issue is solved in React 15, and you can now return `null` from any component, whether it is a class or a function. ([@jimfb](https://github.com/jimfb) in [#5884](https://github.com/facebook/react/pull/5884)) | |||
- **Functional components can now return `null`.** We added support for [defining stateless components as functions](/react/blog/2015/09/10/react-v0.14-rc1.html#stateless-function-components) in React 0.14. However, React 0.14 still allowed you to define a component `class` without extending `React.Component` (e.g. `class Hello {}`), so [we couldn’t reliably differentiate between a stateless functional component and a `ReactClass`](https://github.com/facebook/react/issues/5355) and did not allow returning `null` from a stateless functional component. This issue is solved in React 15, and you can now return `null` when rendering any component, whether it is a `ReactClass` or stateless functional. ([@jimfb](https://github.com/jimfb) in [#5884](https://github.com/facebook/react/pull/5884)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about flipping this to be using pure functions as "stateless" components
? I think it gets the idea across a little more clearly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume you're referring to changing "defining stateless components as functions".
I have no objections. To be clear, class components can also be "stateless" and therefore technically match the term "stateless components", but I don't think that makes your version incorrect.
So the paragraph becomes:
|
@jimfb The change you suggested to sentence structure seems fine to me. I'm kind of on the fence about whether In any case, while I hope it's clear that the React terminology would benefit from an overhaul, I don't think introducing new terminology for these in the changelog is going to help clear things up. |
I’m going to close this—to be honest I don’t think it helps a lot (e.g. |
There's an item in the v15.0.0 release notes (changelog and blog post) that's super confusing, because I think it's a mistake.
This part...
...implies that you can no longer do this:
And apparently that was the case mistakenly and temporarily from #5884 but fixed in #6008 without being reflected in the changelog.
My understanding is that the actual change is that you can no longer do
class Hello {}
vsclass Hello extends React.Component {}
(because it wouldn't haveHello.prototype.isReactComponent
). (Aside: I don't actually fully understand why it works like that, since it seems like you could duck type onHello.prototype.render
to differentiate from stateless functional, but I haven't looked at all of it and there must be a reason.)I've attempted to clarify that in the changelog. (If this is correct it'd also be good to update the blog post if the content is going to be duplicated there.)