Live data from Hacker News

React v16.2.0: Improved Support for Fragments

reactjs.org

41–47 of 47 posts

Re: React v16.2.0: Improved Support for Fragments

#41
post #40

Why can't they automatically wrap every bit of JSX with a 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.

Because you don't know where JSX ends and code begins. Don't forget that fragments can include text nodes too.

return

// am I a comment? Or text after div?

Re: React v16.2.0: Improved Support for Fragments

#42
post #37

Man, 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 accom…

>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. :-)

Re: React v16.2.0: Improved Support for Fragments

#43
post #28

Earlier quoted context omitted.

Sure 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?

I'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.

Because it is ambiguous. :-)

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.

Re: React v16.2.0: Improved Support for Fragments

#44
post #40

Why can't they automatically wrap every bit of JSX with a 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.

Because you don't know where JSX ends and code begins. Don't forget that fragments can include text nodes too. return // am I a comment? Or text after div?

Ah, hmm... good catch.

Re: React v16.2.0: Improved Support for Fragments

#45
post #37

Man, 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 accom…

>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…

Yes, 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.

Re: React v16.2.0: Improved Support for Fragments

#46
post #45

Earlier quoted context omitted.

>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…

Yes, 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 with…

>I doubt it since JSX tags don't support generators as an attribute or name

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.

Re: React v16.2.0: Improved Support for Fragments

#47

Earlier quoted context omitted.

I'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.

Because it is ambiguous. :-) 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.

It would be, wouldn't it. Silly I didn't realize that right off the bat.

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.

Post reply on HN