8 ms·
Hi, I wrote this blog post. We were trying to keep our API surface area small with one way to load data into components, but you're right -- we should probably
by avital 11y ago
Hi, I wrote this blog post.
We were trying to keep our API surface area small with one way to load data into components, but you're right -- we should probably /also/ add a ES6 base class as a second option, and let the people choose which they prefer.
A lot of React developers still prefer mixins -- react-router recently switched from mixins to ES6 classes and then changed their mind "until ES6 classes have better answers to replace what mixins do (like decorators).": https://github.com/rackt/react-router/blob/master/UPGRADE_GUIDE.md#0132---0133 https://github.com/rackt/react-router/blob/master/UPGRADE_GU...
- clessg 11y ago> we should probably /also/ add a ES6 base class as a second option, and let the people choose which they prefer. Please provide a higher-order component or ES7 decorator (assuming ES7 will be supported?), would rather not use inheritance.
- jxm262 11y ago^ this. Id much rather use a decorator with ES7 then extending out classes. Although, i thought i heard that react is working on making some better alternative to mixins
- anarchy8 11y agoThat is very disappointing. Decorators already exist in Babel and they work perfectly. I don't know what they're waiting for
- pspeter3 11y agoI suspect they're waiting for the proposal to be more stable for the official integration. This seems like a great opportunity for the community to write a decorator and let a convention form before it gets merged into the core framework
- deleted 11y ago[deleted]
- djmashko2 11y agoThere's a more detailed discussion about mixins vs. other data loading methods on this GitHub issue: https://github.com/meteor/react-packages/issues/25#issuecomment-116236904 https://github.com/meteor/react-packages/issues/25#issuecomm...