6 ms·
React v16.2.0: Improved Support for Fragments
- slaymaker1907 9y agoThese will be quite nice when wrapping things like css grid components which must be on the same DOM level.
- acemarke 9y agoSeveral 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 <Fragment><Component1 /><Component2 /></Fragment>; 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 literals work, like `<SomeComponent a b c />`, rather than having that become a defaulted-true boolean, I'd be happy :) ) [0] https://medium.com/@gajus/using-react-v16-to-create-self-destructing-components-de8e4eb61d0f https://medium.com/@gajus/using-react-v16-to-create-self-des...
- danabramov 9y agoTo be pedantic, it's not 100% equivalent. You can find the nitty-gritty details about the (intentional) differences here: https://github.com/facebook/react/pull/10783 https://github.com/facebook/react/pull/10783. 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.
- girvo 9y agoThat works in ReasonML :)
- borplk 9y agoI was already thinking "but what about Typescript..." then saw it already supports it :) Well done react team and contributors.
- Klathmon 9y agoThis 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 just gets lost.
- nimos 9y agoFibers? I thought they were implemented and that was what React 16 was all about.
- danabramov 9y agoFrom React 16 blog post (https://reactjs.org/blog/2017/09/26/react-v16.0.html https://reactjs.org/blog/2017/09/26/react-v16.0.html): >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.
- nimos 9y agoAh ok thanks, not super familiar with react. Had seen a video about fibers/async and saw something about 16 implementing them. Put 2 and 2 together and got 5.
- danabramov 9y agoYou 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/8830 https://github.com/facebook/react/issues/11566 https://github.com/facebook/react/issues/11566
- 9y ago
- KeitIG 9y agoI 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 https://github.com/facebook/react/issues/6436
- hobofan 9y agoI 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.
- acdlite 9y ago> The Fragment syntax adds some additional magic to JSX (which is rarely a good thing) 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."
- hazza1 9y agoSure it's straightforward enough and much better than what we had before. 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?
- electric_sheep 9y agoI'm guessing it's because JSX is XML-like and so parsers may require a single root element for each JSX "document". It's a good question though, hopefully someone from the React team might be able to comment.
- danabramov 9y agoBecause it is ambiguous. :-) https://news.ycombinator.com/item?id=15808311 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.
- megous 9y agoNo mention of prior work? This is part of web platform since forever. See document.createDocumentFragment().
- acdlite 9y agoWe 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!
- megous 9y agoThanks, it's a useful part of the DOM, perhaps somewhat overlooked.
- Fifer82 9y agoI 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.
- chrisweekly 9y agoNot to feed a troll but how is doubling down on _Angular_ better for a ”transferable skill set” than React?
- sotojuan 9y agoNext time post this kind of stuff on your blog, not HN comments.
- deleted 9y ago[deleted]
- deleted 9y ago[deleted]
- danabramov 9y ago>back into the arms of Angular Curious: which one are you referring to?
- abritinthebay 9y ago> I had to call a meeting and laid in down in October. If 2018 is React, I am leaving on Dec 31. I'm not sure they'll miss you.
- hoodoof 9y agoEach to his own. Kinda weird that it upset you that much.
- 9y ago
- deleted 9y ago[deleted]
- ojosilva 9y agoIve started with React recently and strangely the lack of fragments were one of the things that caught my attention in the first days. 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?
- spoiler 9y agoI agree with you that CSS support is a bit lacking. I think they did this on purpose though, because many people prefer CSS preprocessors like SCSS/Sass or Less. However, with Create React App, you get nice CSS support via webpack and PostCSS. I recommend you check out styled-components; getting used to the back tick syntax takes some time, but after you do get used to it, working with them is really nice. Also, Babel syntax highlighting (in Atom at least) properly highlights the CSS used in styled-component.
- worldsayshi 9y agoI've found styled components to be a nice attempt at bundling styles with the component. Haven't tried that many options though. It has out of the box support in Atom and scss (like?) syntax. https://github.com/styled-components/styled-components https://github.com/styled-components/styled-components
- aidos 9y agoAnother vote for styled-components. I tried everything I could (model and library wise). That's the one that felt the most natural to me.
- yladiz 9y agoMan, although fragments are a pretty useful concept, the implementation is really terrible. It feels so uninspired and without thought of the design, in my opinion. They could have chosen some character instead of an empty tag and it would have been much better, like an asterisk[1], because it would be clear that the tag serves a defined purpose. I would almost argue that if this weird shorthand is necessary to accomplish this task (something that irked me when creating text heavy pages) then JSX should be redesigned to handle it natively without the weird fragment syntax. 1: Like this: <*> ... </*>
- danabramov 9y ago>feels so uninspired and without thought of the design, in my opinion. 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. :-)
- yladiz 9y agoYes, technically if the empty tags do suffice, then the asterisk brings no additional value, and it would be potentially confusing to use a character that already serves a purpose in Javascript, although I doubt it since JSX tags don't support generators as an attribute or name. You could replace the asterisk with a different character in that case. 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. While I'm sure that there wasn't a lot of discussion within the React team about this, the inclusion of at least a single character, whatever that would be, would make it feel like it was actually designed properly, and I would also argue that adding something to make the tag feel nonempty would actually have a value (to make the tag explicit and not confusing). 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.
- mcphage 9y agoWhy can't they automatically wrap every bit of JSX with a <Fragment> tag? That way users would need to include an empty tag when they're returning multiple elements, and they're not it'll be a fragment tag that just contains a single element.
- danabramov 9y agoBecause you don't know where JSX ends and code begins. Don't forget that fragments can include text nodes too. return <div /> // am I a comment? Or text after div?
- mcphage 9y agoAh, hmm... good catch.