Closed quassnoi closed 4 years ago
I would say that spreading is not what you want, you want the same behavior as you would get with arrays (if you ignore the key warning) with it being its own hierarchy and implicit indices computed accordingly. A previously discussed syntax is <>
, which is also consistent with E4X IIRC (for whatever it's worth).
Also, I imagine if we want to support spreading there's already a solution that wouldn't necessarily introduce new syntax <Parent>{...foobar}</Parent>
. Again, not sure why you would want it though as opposed to just fragments.
Don't I have to key the fragments?
Actually come to think of it, <Parent>{...foobar}</Parent>
would be nice too. That's what I was naively trying to do in the first place, only to stumble upon an error saying JSXSpreadAttribute
being not in the right place. I just failed to find any proposals about this syntax or <>
.
Is there any conceptual difference in React between
createElement(tag, styles, a, b, c, d)
createElement(tag, styles, a, [b, c], d)
createElement(tag, styles, a, createFragment({b, c}), d)
?
Don't I have to key the fragments?
@quassnoi Using React.createFragment
naively requires it yes, it's essentially an associative list (i.e. Map
), so everything has to be keyed by necessity. But you could easily feed an array to React.createFragment
(use index as key) or have JSX pre-compute the indices and assign keys accordingly.
I just failed to find any proposals about this syntax or <>.
Yeah, I'm not 100% sure TBH. It may just have been "informal/internal" discussions in other places.
Is there any conceptual difference in React between createElement(tag, styles, a, b, c, d) and createElement(tag, styles, a, [b, c], d)?
Yes, a very important one. Removing c
in the non-array case would cause React to destroy the instance for d
and try to reuse the instance for c
but now with the props from d
. In the second everything would happen just as you would normally expect.
Are you saying I can just pass an array to createFragment
and it will accept it, keying by the index, with no extra effort from the developer's side?
@quassnoi Honestly not sure, but you could easily have a wrapper that does it, it's trivial logic.
This is a feature request.
It is a common request from developers to allow returning multiple elements from inline expressions in JSX.
http://stackoverflow.com/questions/23840997/how-to-return-multiple-lines-jsx-in-another-return-statement-in-react
A use case for this would be this pseudocode:
which would have React generate either
<Parent><Child/></Parent>
or<Parent><Sibling1/><Sibling2/><Sibling3/></Parent>
, depending on the value of the flag.As it stands now, this would not work, as two or more consecutive tags would not transpile to a single expression.
There are several approaches to that problem:
Wrap the elements into some kind of a parent tag:
This is not always acceptable.
Use arrays:
This would make React complain on the elements in the second array having no unique
key
property, and adding that property would take some extra effort.Use keyed fragments (https://github.com/facebook/react/issues/2127)
This requires assigning arbitrary keys to the fragments, the syntax is quite cumbersome and it's not JSX.
Use
createElement
directly, making benefit of ES6 spread syntax:This is the most straightforward way, as it would be equivalent to either
React.createElement('parent', {}, <Child/>)
orReact.createElement('parent', {}, <Sibling1/>, <Sibling2/>, <Sibling3/>)
, but it's not JSX either.My proposal is to make use of the latter solution in JSX, extending JSX with a Spread tag:
<...>
This tag could only be used as a non-top element in a JSX tree and could only contain a single JS expression in curly braces, which must evaluate to an array.
This Spread tag
<...>{ expression }</...>
would transpile to ES6 array spread syntax:...(expression)
, so that<Parent><a/><...>{ expression }</...><b/></Parent>
becomesReact.createElement('parent', {}, React.createElement('a', {}), ...(expression), React.createElement('b', '{}'))
This way, the original problem could be solved by writing:
which would transpile as follows:
This is almost as simple as the naive solution at the very top, and it produces the exact effect most developers are after: variable number of arguments to
createElement
with no need to create keys or wrap elements into dummy tags.Also, it's a pure JSX feature which does not introduce any new React code.