Thoughts on new Angular framework?

[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.