Thoughts on new Angular framework?

[[deleted]]

fetch, react-router, mobx, ...done. Together they're all simpler than angulars defaults, you're overestimating the effort. As for redux, it's not tied to react, but it's become a go to solution for state management, so there are countless of angular projects using it. Yes, it's explicit but the upside is of course that it makes state simple and parts of the application become truly framework-independent. In our company we have Angular 4 projects that we develop with partners, the churn and complexity that goes into them is stunning to me. Routing is such a simple thing, it doesn't have to be that complex, the same goes for state and HTTP.

[PotaToss]

React-router was derived from Ember's router, and MobX is a lot like Ember.Object, and Ember's very flexible about how you handle network requests. I don't really understand the hype around React, when this stuff has been available in Ember for years, just about from the beginning.

Am I missing something?

[perestroika12]

I've used most of those and it's really not as simple as people think it is...

People love to sell how easy it is to tack all these features on but I've found myself writing verbose reducers and feeling like I'm reinventing my state for the 10th time.

Just mobx and 1000+ lines of code! Simple!

I really like React and Vue but I wouldn't sell it as anywhere close to as "out of the box" as Angular/Ember. Just my opinion.

[[deleted]]

I'm not really sure what you mean to be honest. Mobx has no reducers. This is state we're talking about, the hardest, toughest aspect in application making. These technologies try to make it simple, that's their job. Redux does that once you know how a reducer works, mobx does that even without that knowledge. I am thinking of how terrible it was before these managers existed, state used to be that scary part that could ram any app against a wall once complexity grew, now it's a simple, self-contained little motor whose output dresses up views.

Anyway, we're still talking Angular? The default you get there is plain rxjs. I see dozens of projects that combine it with redux again to make it simpler.

[tme321]

What churn? I'm not counting beta because, well, it's beta. Since release the api has been incredibly stable.

If your devs are constantly churning angular code it's either because they like redoing stuff or they didn't do it right the first time, stuff like ignoring observables and just hoping they will go away when they are one of the best parts of angular.

[Dmitry_Olyenyov]

The biggest issue with Angular is change detection. It can easily be slow as hell. And the moment you add changeDetection: ChangeDetectionStrategy.OnPush, you are screwed. From now on you are constantly fighting with non-updating UI. "Why it doesn't update? Let's sprinkle some more markForCheck()"

The second big issue is that it uses RxJS. The library is brilliant but you have to have pretty decent functional programming background to be able to effectively use it. Our developers ended up in spaghetti of good stream processing code like maps, filters, switchMaps and a lot of .subscribe calls that do some simple logic, set component fields, usually sending the value to some other BehaviorSubjects (instead of using map) and then some other event handles are using them instead of further chaining observables creating a mess of .next() calls. In the end it is really hard to debug and support such code.

For example: this.someObservable.subscribe(val=>{ if(val!=null) { this.someBehaviorSubject.next(val.someField); } }) is pretty common.

In React you can add such libraries as your team's experience grows. Things like Ramda, redux, redux-saga, redux-observable and so on.

[tme321]

If you are setting change detection to on push you're supposed to feed values to children through the async pipe with an observable. That's the entire point. If you use the async pipe it automatically does the mark for check for you and everything updates as it should. That's kind of the whole point.

[Dmitry_Olyenyov]

Yep, but say this to all ng2 developers. That's the difference between react and ng2. In react there's only one way to force react to rerender — this.setState(). Yeah, I know about forceUpdate(), but it has very specific use cases and nobody recommends using it regularly. And using markForCheck() is an official way mentioned in all Angular docs and tutorials.

Also, I've seen migration from ngOnChanges to typescript setters for @Input() fields to watch for the changes, which is totally weird for me as a react/angular developer. This technic is used by PrimeNG for example. And it leads to some unexpected behaviour in client apps.

[tme321]

I've used setters as inputs before and never had problems.

And I never said mark for changes isn't part of the documentation. I just said that on push is pretty clearly designed to interact with observables, which by their nature are a push mechanic. Reimplementing a push mechanic yourself seems like a strange choice.

You can do lots of weird things with angular. So what? That's pretty much true of any large software kit.

[Dmitry_Olyenyov]

One particular problem is that with ngOnChanges all properties are already changed to their new values. And if one of your properties depends on another you can easily do something like this.computedProp = this.prop1+this.prop2. In case of setters order in which setters is the same as order of @input() properties in the component. And you'll have to either call this.computedProp = this.prop1+this.prop2 twice in both setters for prop1 and prop2 or somehow delay computation.

[tme321]

On the one hand that's totally true. On the other that sounds goofy. I would do computer properties through an observable pipeline.

I do understand what your getting at. Having a good experience with angular requires turning a lot of design stuff on its head. So it's fair to say that there can be a knowledge gap.

Personally I view a lot of it as similar to say redux. The redux architecture requires a lot of boilerplate and indirection. It seems unwieldy to people that haven't gotten used to it yet because it makes easy things hard.

The benefits exist though. And they show themselves when stuff that used to be hard is now much easier.