-
Notifications
You must be signed in to change notification settings - Fork 47k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JSX Spread Syntax requires ES6 Object.assign #2417
Comments
I actually like the idea of using Object.assign, and encouraging the use of the ES6 standard. However, it seems counterproductive/redundant to implement Object.assign for internal use only, and exposing it as React.__spread, especially when Object.assign is so commonly used. Same with a couple other internal APIs, such as listen(), which could be exposed so it doesn't have to be implemented twice. |
I think it's too radical! At least the doc should explain something like "ES6 only , you can use transferPropTo() function for compatibility". Due to this case , I feel React is not credible. There are popular words in Chinese "步子大了容易扯到蛋" that means “ If your step is too big, your ball will break up” |
@dandelany This feature was never announced in 0.11.2 because it wasn't quite done yet. In 0.12, the spread attributes in JSX do not require The original intention was to require an Both our Unfortunately, the wider JS community's polyfilling infrastructure is pretty poor. So we eventually decided against taking on the dependency in React Core for now. @dexbol The main docs was updated with alternative patterns if you don't want to follow along with the progress of standards. http://facebook.github.io/react/docs/transferring-props.html#transferring-with-underscore |
Closing out since this was already addressed in 0.12. |
@sebmarkbage Thanks for the explanation, and apologies for the confusion. I had installed 0.12 but was accidentally still testing this on a project that used 0.11.2. Great presentation, and I definitely agree with you re: reducing the API surface area and bringing abstractions under control. I, too, though, am a bit worried about how polyfilling will work. Seems like you have a few options, none of which are great:
I'm curious what React's planned approach is... definitely not an easy problem to solve. |
I'm still seeing this behavior with 0.12.0 (through react-rails). This should work yeah? render: function() {
return <MyComponent {...this.props} />;
}
// compiles to
render: function() {
return MyComponent(Object.assign({}, this.props));
} |
That seems like react-rails might be still using the old compiler. That's not the 0.12.0 behavior. Perhaps you're using the 0.12.0 runtime with the 0.11 compiler. |
Thanks @sebmarkbage. It was actually an old version of |
The new JSX spread syntax introduced in 11.2 and described here:
https://gist.github.com/sebmarkbage/07bbe37bc42b6d4aef81
is very nice, but when I compile JSX that uses this feature, I see it is implemented with Object.assign. Since this is a proposed ES6 feature that is only supported in Firefox 34, using JSX spread syntax necessitates using a polyfill for Object.assign. It would be great if this were not the case, and seems like it should be possible to implement this behavior without Object.assign.
The text was updated successfully, but these errors were encountered: