const Fragment = ({children}) => children;
// later
return <Fragment><Component1 /><Component2 /></Fragment>;
[0] https://medium.com/@gajus/using-react-v16-to-create-self-des...
We did mention the author of react-aux in the blog post though :-)
>Thanks to Gajus Kuizinas and other contributors who prototyped the Fragment component in open source.
Another thing I'm looking for in React as I get started is better styling support. I'm resourcing to React JSS for that, but I feel it should be part of the language. The web trinity if you may is HTML-CSS-JS and React basically left CSS out half-baked into almost unusable style attributes, so I still have to resource to className and CSS. Or am I just being noob-anal?
It has out of the box support in Atom and scss (like?) syntax.
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.
In: <></>
Out: <React.Fragment></React.Fragment>
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."
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?
But for a newcomer to JSX it looks odd.
I'm probably just missing the reason for the syntax, we're already compiling - why can't fragments be added automatically as required?
1: Like this:
<*> ... </*>Thanks for feedback! I assure there wasn't a lack of thought, in fact we discussed this for several weeks before even beginning to implement this. Your proposal was also considered but it doesn't bring anything over <>, whereas * already has a meaning in JS related to generators. It would be confusing to use it here for a different purpose.
FYI, <> is not original. As mentioned in the post, it has prior art. It already went through standardization once (in E4X). It has also been used for months (maybe over a year) in ReasonML, and its users reported really enjoying this syntax.
You may not like it but it doesn't mean we haven't given this any thought. :-)
I don't necessarily buy the prior art arguments too because E4X was barely used even though it was a standard and is now deprecated, and ReasonML is pretty specialized and much less popular, as well as has a different set of users, than React. If you had told me a product in the same category as React, like Angular, Vue, Ember, Ractive, etc., used that syntax, I would be much more receptive.
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.
Well done react team and contributors.
return <div />
// am I a comment? Or text after div?
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 just gets lost.
>We think async rendering is a big deal, and represents the future of React. To make migration to v16.0 as smooth as possible, we’re not enabling any async features yet, but we’re excited to start rolling them out in the coming months. Stay tuned!
The rewrite was about adding the foundation for making this even possible. But there's still work to do before we can enable async rendering by default.
> 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!
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.
Curious: which one are you referring to?
Kinda weird that it upset you that much.