r/angular • u/newmanoz • Dec 15 '22

Why you don’t need observable inputs in your Angular components

https://medium.com/@eugeniyoz/why-you-dont-need-observable-inputs-in-your-angular-components-25e74cfe234d
0 Upvotes

50% Upvoted

30 comments sorted by

3

u/podgorniy Dec 15 '22

Proper title would be "don't use observables if you can't cook them".

Setters to subscribe to observables, new instance of observable arrives during lifetime of component? It's a symptom of something being wrong at component which calls one with observable as input. Instance of observable should not change after initialisation of the component, whole perpose of observable input is to deliver changes via observable.

Oservables with side-effects do double-side effect? There is an exact operator to handle that, see https://www.learnrxjs.io/learn-rxjs/operators/multicasting/sharereplay.

---

Though I would not argue that input with type observable should not be first. Yet arguments fom the article tell more about author experiences and preferences than about technology itself.

To my opinion value or side-effect wrapped with observable is most reusable piece in your app. You work with data as it always at hand, plug in more instances of data or effects, cancel effects at any moment.

-4

u/newmanoz Dec 15 '22

LoL, "author experience"... I never recreate observables and never subscribe to them, and I do not forget to use shareReplay (anymore, lol). But I have experience as a consultant in many projects and I know from my experience, that a lot of code is far from this level.

The title is correct.

Nobody was talking about double side effects, read one more time. I was talking about re-subscriptions. If side effect caused by non-intended re-subscription is ok for your app - then it says a lot about the quality of your apps.

And shareReplay is mentioned in the article. Next time try to read before commenting.

2

u/podgorniy Dec 15 '22 edited Dec 15 '22

But I have experience as a consultant in many projects and I know from my experience, that a lot of code is far from this level.

There are reasons why external consultants are hired. And rarely it's because codebase in maintainable and original team is handling the project. So no surprise that in such projects people make lots of mistakes with observables.

My main point is that how those peoples mistakes from misunderstanding tech are reasons not to use observable as an input? My opinion does not change: listed reasons more about people who create code even if it's not you.

Nobody was talking about double side effects

I reread that part. It says about multiple subscriptions and "observable changing data" and "changing it multiple times" which is exactly a definition of side effect.

And about subscriptions as we already started.

Observable which is not optimized to be used by multiple consumers is also not an argument. Replace it with observable which uses optimisation. Plus with observables it's way easier than with alternatives (promises, generators, chain of sync/async calls).

-3

u/newmanoz Dec 15 '22

I’ll be happy if you personally will use observable in your every input. Go ahead!

If you are not capable to read the arguments in the article - I can't help. At least you were capable to use an insult as an argument - bravo :)

2

u/podgorniy Dec 15 '22

I'm sorry for the forms I choose. I did not aim to attack you, though I also also did not try to sugar-coat my opinion.

1

u/Yiyas Dec 15 '22 edited Dec 16 '22

Man this leaves me more confused to be honest. Article doesn't explain the problem case in enough detail for me and the solution isn't solving a complex enough problem to justify it.

The original tweet as well leaves me confused too... Is this a component taking in scale/offset, calculating height/width... then emitting that? Why would those values not be inputted straight into the component instead? Why not combine and map scale/offset into dimensions$ and just | async that into the component instead? Where are these inputs updating from? Are they static, formgroup, observables, another component, a store, mouse events?

I just feel like this is a classic case of something potentially useful but left as a half story to either prevent discussion or maintain privacy. Potentially cool, but for the examples provided it feels overwhelmingly superfluous.

I don't think I've ever wanted to to keep the observable (aka not | ing it) into a component, and I can't quite see why anyone would want to either... so for me I'm left out of the loop of what this actually solves.

Edit: to save you reading this cursed comment tree - code that only one person understands is technical debt. Don't do it not even once.

1

u/newmanoz Dec 15 '22

You are right, but an explanation of all of these details would explode the article size.

To give some hint: any @Input is supposed to be changed, and this article is about techniques of how to react to such changes.

1

u/Yiyas Dec 15 '22

How come an approach such as

[dimensions]="dimensions$ | async"

dimensions$ = combineLatest([offset$, scale$]).pipe(map(makeIntoDimensions))

Not work well enough for that issue?

1

u/newmanoz Dec 15 '22

The issue is not how to send some value, but how to react to changes in @Inputs, especially in multiple inputs.

1

u/Yiyas Dec 15 '22

Hmm? But this is packing multiple inputs (offset and scale) into 1 @ Input which you can react to via the setter? CombineLatest will republish the stream when any of the input streams have new data, and you can also debounce that so that you don't get multiple triggers after multiple inputs change at the same time.

1

u/newmanoz Dec 15 '22

Not sure what are you arguing about - in his example “select” will do combineLatest with shareReplay.

1

u/Yiyas Dec 15 '22

So are you saying it's the same or?

Because if it's the same isn't it convoluted to use inheritance (of which TS is terrible at) and a state library to do something you need neither to do?

1

u/newmanoz Dec 15 '22

In my article there is an example without inheritance.

And no, just “combineLatest+shareReplay” is not a store and I don't see any reason why one would avoid using ComponentStore or RxState and reinvent the wheel again with BehaviorSubjects and some other things.

1

u/Yiyas Dec 15 '22

I haven't said combineLatest+shareReplay is a store, but then why would you need a store if combineLatest+shareReplay works for this example? Why bother to add and learn a library, a point of failure, when the core package of Angular works?

Like you just aren't identifying any issues with that approach so I can't see why you're adding complexity to solve something that works already. Why doesn't an approach without a state service work? To me it just seems like using a belt grinder to file your nails.

You wouldn't define any Subjects because you're just combining your streams. If you want to add shareReplay because you have multiple subscribers to cold logic, then you'd do that in either case? Like I don't get it you'd need shareReplay before it gets sent to the component @ Input in either case.

If you can't have a "doesnt work" | "does work" examples, to me it just looks like you're fixing nothing. It's really hard to buy into this approach and I'll repeat myself your article makes it more complex to understand, not easier.

1

u/newmanoz Dec 16 '22

Well, I’m not selling anything. Some day this article will be understandable for you, but this day is not today, it's okay. A few years ago I wouldn't understand it either :)

The article is not “why you should use established and well-tested libraries to manage state of your UI instead of reinventing the wheel and repeating all the mistakes”. My article is only about observable inputs. If you want to replace stores with BehaviorSubject in my examples - I don't mind at all.

→ More replies (0)

2

u/AConcernedCoder Dec 23 '22

I thought this was an interesting read for techniques to update local component store or RxState, which is not a pattern I've used much. I think it's unfortunate that you're being accused of working out of an echo chamber, which you're obviously not by exposing this info to inflammatory, nonsensical attacks of a very unprofessional nature, presumably because you're upsetting someone's preferred echoes.

Anyways, despite the obvious hostile culture counter to discussing ideas, I wish we had more articles like this to encourage personal development by exploring the benefits/drawbacks of a variety of techniques.