React v16.2.0: Improved Support for Fragments(reactjs.org) |
React v16.2.0: Improved Support for Fragments(reactjs.org) |
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.
Not currently, but we do have some plans regarding do-expressions, generators, and JSX. So * might get a meaning, even though not in attributes but children.
>My main point is that the empty tag feels, well, empty and made without a real purpose, in part because it's just so foreign compared to HTML (which is what JSX is based on?) as this kind of thing is never found in HTML.
I think most React users in practice don't touch HTML that often. JSX has quite a few differences with HTML, and we don't really plan to bring it closer to HTML in the future. It is more important to us to make JSX pleasant and convenient to everyday React users than it is to have 1:1 mapping to every HTML concept.
>ReasonML is pretty specialized and much less popular, as well as has a different set of users, than React.
I would argue that people using ReasonML today are the same kind of early adopters (and often even the same people) that started using React four years ago when the ecosystem didn't exist (and shaped that ecosystem). I trust their judgment.
>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
By that logic, we could dismiss React when it came out, because it was not like anything else :-) Give this syntax some time. It felt odd to me at first, after living with it for a few months it feels very natural. I'm sure you'll get to like it eventually too. At that point it might feel odd that other libraries don't provide this syntax.
I understand your point, but in practice people love tiny affordances like this, especially when they are needed as often as fragments are.
This is a balance, but it's important to consider the needs of power users too. Beginners don't stay beginners forever. We've thought about this for a few months, and decided that adding syntax would be better. I understand some people will always disagree though, and that's fine :-)
https://news.ycombinator.com/item?id=15808311
If you have a specific proposal for how it should work, I'm happy to look at it and try to poke holes in it.
Can't imagine putting forward a proposal that wouldn't in essence be what you're doing, i.e. wrapping in JSX delimiters. Because attempting anything fancier than that would probably have edge cases for days, plenty of material for you to poke holes in.