Live data from Hacker News

React v16.2.0: Improved Support for Fragments

reactjs.org

11–20 of 47 posts

Re: React v16.2.0: Improved Support for Fragments

#11
post #5

This is a bit off topic, but does anyone reading this happen to know the status of async rendering in react? There was chatter about it for version 16, and then nothing really else. I'm curious about what they are testing or at least planning in this area. Unfortunately i've found it really hard to search for anything related to async rendering for react, as there is just so much other crap about react and "async" it…

You can track it here. Still plenty of work to do but we are making progress. https://github.com/facebook/react/issues/8830 https://github.com/facebook/react/issues/11566

Thank you! This is exactly what I was looking for and it seems all search engines have failed me!

Re: React v16.2.0: Improved Support for Fragments

#12
post #3

Several people had already noted [0] that you could implement equivalent behavior by using a component that simply returns its own children: const Fragment = ({children}) => children; // later return ; Nice to see this added as both a built-in component type and a useful syntax extension. (Now if they'd just modify JSX syntax so that we can pass props by matching local variable names similar to how ES6 object literal…

That works in ReasonML :)

Re: React v16.2.0: Improved Support for Fragments

#13
I love to see these small improvements added to React.

Everything is not perfect though, some issues have been here for a looong time. At the moment, my biggest problem is the non-support of passive events [0]. And today, some browsers are starting to make some events passive by default (`touchmove` on Chrome for example), it is quietly starting to become a serious problem for developers to get things working fine cross-browser without anti-patterns.

[0] https://github.com/facebook/react/issues/6436

Re: React v16.2.0: Improved Support for Fragments

#14
I appreciate the addition of Fragments, but I'm not sure if the addition to the JSX syntax was really a good decision.

While it initially took some time to wrap my head around JSX (especially with a lot of JS mixed into it), after that I really started to enjoy JSX for its simplicity. The Fragment syntax adds some additional magic to JSX (which is rarely a good thing), and will also very likely break all the syntax highlighting out there again when used.

Re: React v16.2.0: Improved Support for Fragments

#16
I just can't help but sneer. Opinionated document.write() using "jsx".

Working with react has been the worst experience of my life. I had to call a meeting and laid in down in October. If 2018 is React, I am leaving on Dec 31.

So soon I am going swiftly back into the arms of Angular and I can't wait. Honestly, my eyes are blurring as I type this with pure happiness.

Enjoy the fragments guys, it will be good practice for picking up what little is left of your happiness and transferable skill set in years to come.

Re: React v16.2.0: Improved Support for Fragments

#18
post #14

I appreciate the addition of Fragments, but I'm not sure if the addition to the JSX syntax was really a good decision. While it initially took some time to wrap my head around JSX (especially with a lot of JS mixed into it), after that I really started to enjoy JSX for its simplicity. The Fragment syntax adds some additional magic to JSX (which is rarely a good thing), and will also very likely break all the syntax h…

> The Fragment syntax adds some additional magic to JSX (which is rarely a good thing)

In:

Out:

WITCHCRAFT!! SORCERY!!

Teasing aside, I don't get what's magical about this. It's a straightforward transform. You can call that "magic," I'll call it "syntax."

Re: React v16.2.0: Improved Support for Fragments

#19
post #15

No mention of prior work? This is part of web platform since forever. See document.createDocumentFragment().

We did mention some prior art in the section discussing the new syntax:

> Fragment syntax in JSX was inspired by prior art such as the XMLList() constructor in E4X. Using a pair of empty tags is meant to represent the idea it won’t add an actual element to the DOM.

You're right that we could have referenced document.createDocumentFragment(), too. Perhaps we'll add that to the documentation. Thanks for the suggestion!

Re: React v16.2.0: Improved Support for Fragments

#20
post #18
post #14

I appreciate the addition of Fragments, but I'm not sure if the addition to the JSX syntax was really a good decision. While it initially took some time to wrap my head around JSX (especially with a lot of JS mixed into it), after that I really started to enjoy JSX for its simplicity. The Fragment syntax adds some additional magic to JSX (which is rarely a good thing), and will also very likely break all the syntax h…

> The Fragment syntax adds some additional magic to JSX (which is rarely a good thing) In: Out: WITCHCRAFT!! SORCERY!! Teasing aside, I don't get what's magical about this. It's a straightforward transform. You can call that "magic," I'll call it "syntax."

Sure, we can call it syntax. Of course, for anyone who already knows what it does, it's just a transform, but the problem with extra syntax is that it makes it harder for newcomers to pick it up.

Taking your example when putting it in front of someone seeing it for the first time:

In:

Out (Newcomer): WTF does that mean? Did someone forget to put something in those tags?

Post reply on HN