I mean direct render method components... you don't have to inherit from Component or use the legacy method at all if you don't want to.
export default MyComponent(props, context) {
return <div>Hello {props.name}!</div>
}
I happen to like React because it's functional representation all the way down, and I tend to like JSX in my JS vs. weird DSL in templating system in my HTML referenced with JS. But that's just me.
I can see the appeal of Vue.. and frankly, can see the appeal of Polymer as well. However, I find React feels better when I've used it.
The one point that rings true to me is "Focusing on poor metrics such as “issues closed” or “commits per day”"...
I was on the verge of being fired (I moved on to another position before that happened), because my issues list didn't have as many closed items as other developers.
Despite the fact that I'd literally removed over 20kb of code from the project (the prior month) with mild refactoring, using better techniques and all the code I did refactor/add was 100% tested. I also helped a lot of the other developers in the group, and had to participate in the meetings for two teams. But no, the issues closed ruled the roost so to speak.
Mistake towards the top, in the second code segment...
someModule(param, (result, error) => {
should be
someModule(param, (error, result) => {
Node-style CJS async methods should *always* have error first in the response... those few API interfaces that don't cause issues with other libraries.
I'll often use both, but not in the same places... async functions when called return a promise... you can await anything that returns a promise.
I'll often refactor some pieces that make sense as functions that return a straight promise (especially if using callback code.
const foo = () => new Promise((res,rej) => {
someCbFunction((err, result) => err ? rej(err) : res(result);
});
There are times it's just easier to think imperatively... A great example is a promise that will retry N times on rejection before raising the rejection... try this with promises alone and you'll drive yourself bonkers.
I mean direct render method components... you don't have to inherit from Component or use the legacy method at all if you don't want to. export default MyComponent(props, context) { return <div>Hello {props.name}!</div> }Mistake towards the top, in the second code segment... someModule(param, (result, error) => { should be someModule(param, (error, result) => { Node-style CJS async methods should *always* have error first in the response... those few API interfaces that don't cause issues with other libraries.I'll often use both, but not in the same places... async functions when called return a promise... you can await anything that returns a promise. I'll often refactor some pieces that make sense as functions that return a straight promise (especially if using callback code. const foo = () => new Promise((res,rej) => { someCbFunction((err, result) => err ? rej(err) : res(result); }); There are times it's just easier to think imperatively... A great example is a promise that will retry N times on rejection before raising the rejection... try this with promises alone and you'll drive yourself bonkers.