Add Fragment as a named export to React

[clemmy]

This PR is a part of the bigger change to introduce <></> fragment syntax to JSX. With this named export, we'll be able to de-sugar <></> into React.createElement(React.Fragment) calls.

UPDATE:

Summary of discussions in PR:

We want to align fragment with array behavior.

• top level keyed React.Fragment => create fragment fiber
• top level un-keyed React.Fragment => no fragment fiber created
• nested fragments => fragment fiber created
• React.Children will treat fragments as a terminal element
• In this gist (https://gist.github.com/clemmy/b3ef00f9507909429d8aa0d3ee4f986b), switching between arrays and un-keyed fragments will preserve state (e.g. Child will be preserved when rendering <>[]</> and then <><></></>)

You can think of it as the quantum theory of fragments. It has both array-like and element-like properties. 😆

[acdlite]

Looks good... except you wrote too many tests. How dare you!

[acdlite]

Just the noop renderer is fine :D This doesn't touch any renderer-specific code.

[clemmy]

Should have said so sooner! :'(

[acdlite]

I’m sorry :( Didn’t know you were struggling with this. If something’s not renderer specific, we usually just test with the noop renderer. Except for older tests, which use React DOM.

[clemmy]

Gotcha, good to know! :)

[acdlite]

Is there documentation somewhere that I should update for this PR?

Let's hold off on documentation until we're ready to release it. Also shouldn't merge this until after 16.

[gaearon]

With this named export, we'll be able to de-sugar <></> into React.createElement(React.Fragment)

Doesn’t it mean we’ll create two fibers for every fragment? One for the wrapper and one for the fragment itself. Seems unfortunate.

[acdlite]

@gaearon Yes, but I think this is fine for demo purposes and experimenting at FB. We can optimize it later.

[acdlite]

Although @clemmy if you want to do it the "right" way and avoid the extra fiber, I'm happy to merge that, too :D

[NE-SmallTown]

Relevant quip: https://fburl.com/j3hcevus

The link 404 😲

And IIRC, "<></> fragment syntax to JSX" is still under discussion, or you mean it will be accepted to JSX2.0?

[acdlite]

Doesn’t it mean we’ll create two fibers for every fragment

Thought this was the case but then I remembered we don’t create an extra Fragment fiber for an array returned from render. For the same reason we don’t create an extra Fragment fiber for the children of a host component. It just becomes that fiber’s child set. So, we could turn React.Fragment into a Fragment fiber instead of a FunctionalComponent fiber, but it would still just be one fiber.

[acdlite]

Could still be worthwhile for other reasons though

[gaearon]

So, we could turn React.Fragment into a Fragment fiber instead of a FunctionalComponent fiber, but it would still just be one fiber.

This is what I meant. But I agree it doesn't block this PR.

[clemmy]

@NE-SmallTown Oops! The link I posted basically just mentions some quirks regarding the <></> syntax such as not allowing attributes. Currently, we're experimenting with the syntax support for fragments, but not the rest of the proposals in the JSX 2.0 issue.

[trueadm]

I though ReactFragment would export a string of # instead of a functional component?

[sophiebits]

Or '#fragment'? Then to special case it we don't need to somehow detect if it's the same function, which seems treacherous.

[clemmy]

@trueadm I believe that's more of an implementation detail? The reason I'm pushing for this named export to be merged in ASAP is to save a bit of headache when rolling out fragment syntax changes. I'd be happy to change it to '#fragment' after.

[gaearon]

Would it be hard to implement '#fragment' in the scope of this PR? I'd rather not expose it as a function at all since then changing its type is technically a breaking change.

[gaearon]

The branching on string type happens here. We could check for '#fragment' there and create a Fiber with a private Fragment type instead that would be implemented as a function.

[trueadm]

@clemmy It is an implementation detail, but an important one in my opinion. Babel could instead compile to React.createElement('#fragment', ...) instead. There are a bunch of reasons for this:

• We're not changing the type at later stage from function to string. Which is a breaking change.
• Far easier to determine this a fragment rather than a functional component.
• It's very common for React codebases to set the Babel JSX pragma to createElement and rather than import React in their module, they do import {createElement, Component} from 'React'. This would force them to go back and add Fragment.
• It means the JSX has a fixed coupling with React or another pragma needs to be added to avoid this coupling.
• Inferno, Preact and Vue all support JSX – using #fragment would enable those libraries to adopt fragments in the future too.

[gaearon]

The reason I'm pushing for this named export to be merged in ASAP is to save a bit of headache when rolling out fragment syntax changes.

Could you elaborate on this? How would the export help for the syntax? My understanding is that desugaring JSX to React.Fragment is inherently problematic because it requires a second pragma:

<>hi</>
// How do we know it's React.Fragment and not something else?
React.createElement(React.Fragment, null, 'hi')

Whereas if we use a string, we don’t have this problem.

<>hi</>
// Works with any pragma.
React.createElement('#fragment', null, 'hi')

Why is merging the export helpful in this case? I thought that, if we went with the '#fragment' proposal, we’d only need React.Fragment as a fallback for people who can’t use the syntax yet (e.g. due to waiting for tools). I don’t see why the export would be useful for the syntax itself.

[aweary]

cc @developit, since JSX fragments are important for other libraries that utilize JSX like Preact

[acdlite]

I say we merge this as-is and decide on the implementation details later. We want to start trying out the fragment syntax at Facebook ASAP.

[acdlite]

I like the #fragment idea but I'd also want to hear from other libraries before committing to it. So let's just go with the simplest thing for now. We can put it behind a feature flag maybe if we need to hide it from the public.

[gaearon]

If we only need to add it to try it at FB, we could hack it into the internal React-fb.js entry point instead. Just like we did with createClass during migration.

[gaearon]

But yes, either that, or let’s put it behind a feature flag. I don’t want this to become a public API before we’re truly committed to it.

[acdlite]

I'm fine with hacking it onto the export, too. I didn't realize we were still debating whether to export React.Fragment, only the underlying implementation.

[gaearon]

We shouldn't have used this. It introduces reliance on Symbol which we don't currently require.

I think we should add a lint against for ... of as it's easy to use accidentally and it's not obvious what it compiles down to.

[xyzdata]

good to go!

[xyzdata]

I have some questions, anybody can explain it more in detail?

https://reactjs.org/docs/react-component.html#fragments

1. ...fragments, which don’t require keys for static items:

is that mean we should use a unique key for each dynamic items?

2. just like the below codes shows, li no needs a unique key.

render() {
  return (
    <React.Fragment>
      <li>First item</li>
      <li>Second item</li>
      <li>Third item</li>
    </React.Fragment>
  );
}

is that mean React.Fragment will automatically add a unique key for each li item?

    <React.Fragment>
      <li key="A">First item</li>
      <li key="B">Second item</li>
      <li key="C">Third item</li>
    </React.Fragment>

[clemmy]

@xgqfrms-gildata No keys are required in React.Fragments because they are static in nature. However, keys are required when using the array syntax.

The wording in the documentation is a bit convoluted since the array syntax used to be called fragments. To make it clearer:

Instead of

Don't forget to add keys to elements in a fragment to avoid the key warning

It should be

Don't forget to add keys to elements in an array to avoid the key warning

[xyzdata]

@clemmy Thanks for your time.

good explanation.