I can improve on angular performance with one line too!
npm install webpack babel babel-preset-react babel-preset-es2015 babel-preset-stage-2 react redux react-redux redux-thunks
;-)
I'm mostly kidding, but honestly, after working daily on ng1/ng2 and having used redux + react on a few side projects now, I feel so much stronger about react+redux than ng* ... I'm biased as all hell, but my bias is backed by much less complexity in the codebase for an application.
Jumpin in late, but having the "recent" article pages have a rel="nofollow" until they've seen 3 upvotes may be worth it too, real spam will likely be reported before sufficient upvotes... maybe requiring a certain karma from posts before being able to upvote articles? Just a few thoughts on this one.
I mostly prefer to do more front end work, but like to control the back end as well. I don't like to be pigeon-holed... People assume that because you're good on the front end that you aren't a good/great developer, or that you're weak on the back end, or even more core understanding.
That kind of mindset always irked me to no end.
I find that the lines may get muddled... Something that should reset if the page is reloaded should not go through redux/flux. This includes modals for a calendar control, search boxes, like in tfa, etc.
However, there are interactions, and states that should be part of the application state. A better example, even though it is per-control, would be form/control validation state... was a control focused, if so, then it should show a validated state, otherwise, it shouldn't until a submit is attempted.
There are other controls that may very well go either way. It really depends on your need. I can see the desire to separate the control state from application state, but really, it should be a matter of the guiding parent's feature that controls this... the containing feature's form/screen should have its' own data state, and that state should guid the lookup through a determined service. Then you can still have structured components, but then separate the logic not to a generic control provider, but the parent becoming responsible.
Interesting take... I spent a good deal of time integrating the redux library into an angular2 application, and it was "interesting" doing so, to say the least. Although I don't like this pattern quite as much, it is a much better fit with Angular2.
I have to admit, I'm really biased in favor of React + Redux, but seeing Angular 2 in this article makes it feel much more tolerable. There are quite a few bits of ng2 that I disagree with, and I just don't care for the template engine. The syntax is leaps and bounds better than ng1, that said, I still prefer React+Redux ... going a step farther, I'm playing with preact+redux currently, and getting a working starter app in under 20K payload (min+gzip) is pretty sweet, compared to over 10x that for ng2.
DMCA takedown in 5... 4... 3...
I jest, but I've seen several Spotify API apps like this get shut down on bogus DMCA claims over the source code... hopefully I can clone this at home while it's still up.
I'm not sure how null == false is a security fail in this case... if false were passed, the same effect would have happened. If false were the default for null, etc. In any case, it could have thrown an error, but this would have broken behavior.
This is an instance where the wrong default were passed, it has nothing to do with truthy/falsy in JS. In enterprise environments where you are mitm'd through your corporate transparent proxy, that's the behavior you want/need much of the time.
One thing that really irked me in ng2 was that an <input> uses [id] for a computed id property... however, a <label> needs [attr.for] for the attribute on the element's for instead of [for]. I don't know why unknown values for generic html elements aren't translated to [attr.*] in rendering. *sigh*
I really just don't care for Angular since I've started using React+Redux more. It just makes less sense. React+Redux+Axios(or fetch) get you pretty much everything angular offers in a much more reasonable interface, even with the setup costs for webpack+babel+*...
Definitely good news... I'm also glad that Array.from is now part of the spec, I've shimmed it similarly for years (Array.fromAny in my case).
Although it may be a while before this actually works well, I still look forward to it.
I can improve on angular performance with one line too! npm install webpack babel babel-preset-react babel-preset-es2015 babel-preset-stage-2 react redux react-redux redux-thunks ;-) I'm mostly kidding, but honestly, after working daily on ng1/ng2 and having used redux + react on a few side projects now, I feel so much stronger about react+redux than ng* ... I'm biased as all hell, but my bias is backed by much less complexity in the codebase for an application.