4 ms·

I don't think I understand your objection. Can't a library trivially convert between the two representations if it wants to in its implementation of _jsx? Havi

I don't think I understand your objection. Can't a library trivially convert between the two representations if it wants to in its implementation of _jsx? Having children as a property of the parent isn't an implementation detail of React -- it's just a mapping onto Javascript, where objects have properties, and there's no independent notion of children. The new transform makes things more like Javascript, which seems like a good thing.

lucideer 6y ago
EDIT: (since you updated your comment, some of my original reply no longer applies) Part of the elegance of JSX is that it maps conceptually to the 3 dimensions of it's intended output structure (usually HTML) rather than being restricted by direct mappings to the 2 dimensions represented in JS objects. --- original below --- Both transforms work "like javascript"; I'm not sure how the new one is any different in that regard. While I do think it's a little nicer to not have to import React, they could've done that without changing the factory signature. Furthermore, I think the value of not needing to import React is slightly overstated. If you're using React & JSX, you'll be importing React in your application at some point regardless (so importing in the JSX component file shouldn't add weight). If you're using JSX without React, you don't currently need to import react anyway (as transpilers provide configuration options for factory methods: e.g. via Babel's react-jsx plugin's `pragma` config key)
- afiori 6y ago
  more than not needing react it looks like the new transformation is react-agnostic, so that all libraries that consume JSX can use the same transformation and put all application specific functionality in the _jsx function
- tln 6y ago
  There is a practical limit on how many arguments can be passed to a spread parameter. I tested at 125k in Chrome just now. That's probably a couple orders magnitude more than a typical web page, let alone one parent node, but maybe that's part of why the change was made?
  - lucideer 6y ago
    If that was the reason behind the change, changing the signature to strictly be `_jsx(name, attrs, children)` would've made more sense. I also didn't see this reasoning stated in the RFC thread.

lucideer 6y ago

EDIT: (since you updated your comment, some of my original reply no longer applies) Part of the elegance of JSX is that it maps conceptually to the 3 dimensions of it's intended output structure (usually HTML) rather than being restricted by direct mappings to the 2 dimensions represented in JS objects. --- original below --- Both transforms work "like javascript"; I'm not sure how the new one is any different in that regard. While I do think it's a little nicer to not have to import React, they could've done that without changing the factory signature. Furthermore, I think the value of not needing to import React is slightly overstated. If you're using React & JSX, you'll be importing React in your application at some point regardless (so importing in the JSX component file shouldn't add weight). If you're using JSX without React, you don't currently need to import react anyway (as transpilers provide configuration options for factory methods: e.g. via Babel's react-jsx plugin's `pragma` config key)

afiori 6y ago
more than not needing react it looks like the new transformation is react-agnostic, so that all libraries that consume JSX can use the same transformation and put all application specific functionality in the _jsx function
tln 6y ago
There is a practical limit on how many arguments can be passed to a spread parameter. I tested at 125k in Chrome just now. That's probably a couple orders magnitude more than a typical web page, let alone one parent node, but maybe that's part of why the change was made?
- lucideer 6y ago
  If that was the reason behind the change, changing the signature to strictly be `_jsx(name, attrs, children)` would've made more sense. I also didn't see this reasoning stated in the RFC thread.