Pretty wild... and I'm entirely amused that people complain about the churn and boilerplate for React. I'm glad they worked out whatever issues were preventing the mangle option for uglifyjs to work, as that's a pretty significant difference.
Still not a fan of DI in JS, especially with it's easy module system... it's easy enough to export a single instance in a module, and if you only need one instance, then you can create a wrapper that everything else imports that give you the instantiated instance explicitly.
DI systems make it hard to track down where something came from, makes for disconnected code that's often harder to debug and test against, and in general is usually a complexity that is best avoided.
DI makes far more sense in a statically typed environment that requires certain types of inheritance for testing. Although it *may* provide value if you're writing your tests in TypeScript, I would emphatically *not* use this for JS.
Grommet definitely had some nice features... I haven't seen that library before...
One good thing about react is if given component libraries are well isolated, you can usually bring in `lib/component/foo` as a single component without bringing in the whole library. It would allow you to use, for example, the stats from rebass and the form fields from material-ui. Some libraries do use heavy/separate css, and would keep an eye out for that... if it isn't easy enough to only bring in what you need (via source import), then I would probably avoid such libraries.
It's probably best to create a common lib/components that brings in those components in your application individually, but only those you use... this way you can reuse by importing {Foo} from 'components' or SomeIcon from 'components/foo' aliasing components to your lib/components directory.
I think one should also point out react-icons, which collects the most popular icon libraries as svg icons, so you only bring in what is needed as react components... they seem to be normalizzed, so combining fontawesome icons with google's material icons works out okay (trying to use the font versions together has tended to be problematic).
wrt #10, I prefer feature oriented structure, not just UI oriented.. this can be components and/or higher order services and utils.
#11, not all frontend devs know redux, but it is very popular in React circles and can work well with ng2... I had some issues with synchronizing the ng2 router (before the recent change, not sure about current version) with redux, and the redux-angular2 injection is improved, but not my preference.
I think this would be really useful with the composition operators (<< and >>). Would be nice to see this added as a proposal for EcmaScript stage 0, and a babel implementation.
While interesting, the form example looks alien, to say the least...
<form ref="login" className="login">
<input name="email" type="email" />
...
</form>
Would be more idiomatic... Though at 2kb, it's hardly worth complaining about... Preact isn't much larger, but has more idiomatic support for react-style JSX, which I've used a couple times now.
Yeah, though npm is really an ecosystem built around cjs modules (though some moving towards ES6), and a lot of code now being written in ES6. In some cases, it's hard to decide to leave the ./src directory or not, in addition to ./dist for the potential of tree shaking etc.
I'd much rather use es2015 syntax for rest/spread with fat-arrow syntax... somethingAsync() .then( (...args) => doSomething('prefix', ...args) );Grommet definitely had some nice features... I haven't seen that library before... One good thing about react is if given component libraries are well isolated, you can usually bring in `lib/component/foo` as a single component without bringing in the whole library. It would allow you to use, for example, the stats from rebass and the form fields from material-ui. Some libraries do use heavy/separate css, and would keep an eye out for that... if it isn't easy enough to only bring in what you need (via source import), then I would probably avoid such libraries. It's probably best to create a common lib/components that brings in those components in your application individually, but only those you use... this way you can reuse by importing {Foo} from 'components' or SomeIcon from 'components/foo' aliasing components to your lib/components directory. I think one should also point out react-icons, which collects the most popular icon libraries as svg icons, so you only bring in what is needed as react components... they seem to be normalizzed, so combining fontawesome icons with google's material icons works out okay (trying to use the font versions together has tended to be problematic).While interesting, the form example looks alien, to say the least... <form ref="login" className="login"> <input name="email" type="email" /> ... </form> Would be more idiomatic... Though at 2kb, it's hardly worth complaining about... Preact isn't much larger, but has more idiomatic support for react-style JSX, which I've used a couple times now.