Proposal: Input as Observable

[lacolaco]

Sorry, I'm not good at English.

@Input property values are provided by parent component. The changes come asynchronously.
And if Input property was changed in the child component (it has the property as own property) , its change detector never notice it.

Goal

• Parent's input data and child's input property should be synchronized.
• Developers should understand that input properties are changed asynchronously.

Proposal

@Component({ selector: "child" })
class Child {
  @Input("input") inputValue: Observable<T>;

  ngOnInit() {
    this.inputValue.map((value)=>...);
  }
}

@Component({
  template: `
  <child [input]="valueToChild"></child>
  `
})
class Parent {
  valueToChild: T;
}

Above code does not work. Currently, to receive input as Observable<T>, I must write it like below.

@Component({ selector: "child" })
class Child {
  @Input("input") inputValue: Observable<T>
}

@Component({
  template: `
  <child [input]="valueToChild"></child>
  `
})
class Parent {
  valueToChild: Observable<T> = new Observable<T>((observer)=>{
    ...
    observer.next(val);
  });
}

Example: http://plnkr.co/edit/BWziQygApOezTENdTVp1?p=preview

This works well, but it's not essential. Parent's input data is a simple data originally.

I think this proposal make us happy.

Thanks.

[robwormald]

Hi @laco0416 - your English is fine, don't worry!

I very much like this idea, and it's something we've discussed before. It also matches up nicely with #4062 (Observing view events) and #5467 (Observable child events from parents)

It's important to remember that not everybody will want to use Observables (these people are missing out!), so we must provide options for both use cases, and so it's unlikely we'll make @Input() directly into an Observable. I do think that having something like @ObserveInput() might work, and we'll have a discussion after we ship beta about some of these more interesting features I think.

In the meantime, here's a basic (and very experimental!!! do NOT do this for real) implementation of this idea. Is this conceptually what you were thinking? http://plnkr.co/edit/Nvyd9IPBZp9OE2widOcW?p=preview

[alexpods]

I think it's a very bad idea to change input properties in a child component. Input properties should be "read-only". Your data should always flow from parent to child (and never in the reverse direction).

[robwormald]

@alexpods i believe the idea here is exactly that - its listening to the change in input properties as an Observable, not emitting values upstream, which is absolutely fine as far as I'm concerned.

[lacolaco]

@robwormald

your English is fine, don't worry!

Thank you! I'm so relieved.

Your @ObserveInput is what just I want!
Also, @Input has no breaking changes. I think it is a very good solution.

[lacolaco]

@alexpods Me too at all.

its listening to the change in input properties as an Observable, not emitting values upstream, which is absolutely fine as far as I'm concerned.

I think in the same way as Rob.

[alexpods]

@laco0416 Ooh, sorry for misunderstanding. The phrase "if Input property was changed in the child component" confused me.

[wmaurer]

I don't know if I should comment here or if I should open a new issue. Please let me know if I'm adding a request to the wrong place.

I've been trying (but, until now, failing) to write a such a decorator, and then I stumbled upon @robwormald's plunkr, which works almost perfectly (but not quite).

What got me excited by this approach was the fact that it is leveraging into the ngOnChanges lifecycle hook.
What I would like to see is some way for all lifecycle hooks to be exposed as Observables, i.e. as onChanges$: Observable<{[key: string]: SimpleChange}>, onInit$: Observable<{}>, etc.

Having all lifecycle hooks available as Observables will help me Rx all the things ;-)

[fxck]

Any updates on this?

[lacolaco]

AFAIK, No.
@robwormald do you have any news?

[Guardiannw]

I know this is old, but this would be great! @robwormald Any word on this?

[lephyrus]

I'd love to provide changing @Input property values as an Observable, just like @robwormald's @ObserveInput decorator does. It's not always feasible to have parent components pass Observables, especially when you're migrating an existing (Angular 1) application. Not being able to "contain" Observables within a single component makes leveraging the power and elegance of RxJS much harder, though.

Unfortunately, Rob wasn't kidding when he said not to use this version of @ObserveInput. The problem I'm running into is that the Observables are created on a "class-level" (if that terminology makes sense) and are hence shared across all instances of the component. This is no good, obviously. Creating the Observables at instantiation time did not work for me, either. It seems Angular doesn't correctly wire up change detection it that case.

Has anyone managed a better implementation of @ObserveInput or is there any news on official support?

[wmaurer]

@lephyrus While an official @ObserveInput decorator would be a very nice, it's not strictly necessary in order to get an Observable of changing @Input property values. The decorator would simply be very elegant "sugar".

There is already a lifecycle event ngOnChanges. Inside ngOnChanges we can use an rxjs Subject, to create an observable of changes, i.e.:

@Input inputString: string;
private Subject<string> inputString$ = new Subject<string>;

ngOnChanges(changes: { [key: string]: SimpleChange }) {
    if (changes.hasOwnProperty('inputString')) {
        this.inputString$.next(changes['inputString'].currentValue);
    }
}

constructor() {
    inputString$.subscribe(x => {
        console.log('inputString is now', x);
    });
}

Or, if you want something more reusable, you could create a base class that your componentextends:

import { SimpleChange } from '@angular/core';
import { Observable, ConnectableObservable, Observer } from 'rxjs';

export interface TypedSimpleChange<T> {
    previousValue: T;
    currentValue: T;
}

export class ReactiveComponent {
    private changesObserver: Observer<{ [key: string]: SimpleChange }>;
    private changes$: ConnectableObservable<{ [key: string]: SimpleChange }>;

    constructor() {
        this.changes$ = Observable.create((observer: Observer<{ [key: string]: SimpleChange }>) => this.changesObserver = observer).publishReplay(1);
        this.changes$.connect();
    }

    public observeProperty<T>(propertyName: string): Observable<TypedSimpleChange<T>> {
        return this.changes$
            .filter(changes => changes.hasOwnProperty(propertyName))
            .map(changes => changes[propertyName]);
    }

    public observePropertyCurrentValue<T>(propertyName: string): Observable<T> {
        return this.observeProperty<T>(propertyName)
            .map(change => change.currentValue);
    }

    ngOnChanges(changes: { [key: string]: SimpleChange }) {
        this.changesObserver.next(changes);
    }
}

... which could be used as follows:

@Component({
    ...
})
export class YourComponent extends ReactiveComponent {
    @Input() inputString: string;

    constructor() {
        super();
        this.observePropertyCurrentValue<string>('inputString')
            .subscribe(x => console.log('inputString is now', x));
    }
}

I am using this approach until an official @ObserveInput decorator is available.

[lephyrus]

Thank you, @wmaurer. Your ReactiveComponent is very welcome, and using impeccable code and safe typing to boot - really nice! Importantly, it also behaves well under test and still allows using the OnPush change detection strategy. I'm now happy to wait for the "official sugar". (Also I'm sure I'll learn something when I figure out why you had to use the Observable.create() logic - I haven't found time to look into it yet.) Again: merci gäll! 😉

[wmaurer]

@lephyrus you're welcome, gärn gescheh ;-)

I used Observable.create() to get hold of an Observer in order to be able to do a next(). I could have used a Subject which is both an Observable and an Observer, but I believe it's generally bad practice to 'expose' a Subject (Observer).

[DzmitryShylovich]

@laco0416 close in favor of #13248 ?

[lacolaco]

@DzmitryShylovich No. The feature proposed in this issue is read-only and event-driven data passing.

[huan]

@ObserveInput will be super cool! 👍

[ChrisWorks]

Thank you @wmaurer for a good example. I have one question though. I would like to be able to use an object instead of a string as the observable.

E.g.

@Input() chartConfig: ChartConfig;

constructor(private _reportService: ReportService) {
		super();
             this.observePropertyCurrentValue<string>('chartConfig')
            .subscribe(changedConfig => this.updateChart(changedConfig));
 }

export class ChartConfig {
	public id: string;
	public type: any;
	public data: any;
	public labels: any;
}

However the this.updateChart and the ngOnChanges is not called. How can expand your sample from a simple string to observe an object instead?

[wmaurer]

@ChrisWorks it should also work with objects:

this.observePropertyCurrentValue<ChartConfig>('chartConfig')
            .subscribe(changedConfig => console.log(changedConfig));

I do this very often, so if this doesn't work, I'd guess there's a problem with the input to your component somewhere.

[ChrisWorks]

Hi @wmaurer, thanks for the reply. Would you be able to expand your sample with a working version where you use a "config" object? I simply cant get mine to work. A sample Git repo? :)

[wmaurer]

@ChrisWorks it really should just work the way it is. observePropertyCurrentValue doesn't differentiate between a string input and an object.
Here's a really old ng2 beta 0 project I made where inputs are of all different types, not just strings:
https://github.com/wmaurer/todomvc-ng2-reactive
e.g. https://github.com/wmaurer/todomvc-ng2-reactive/blob/master/src/app/todo-item/todo-item.component.ts

[Dashue]

+1 Such a fundamental use-case, can't believe it hasn't been sorted yet!

[insidewhy]

what's needed is some variation of a BehaviorSubject

ReplaySubject(1)

[aavelyn]

Is there any news on this? I think this is highly relevant for component-based architecture with inputs which can arrive and change at any time. In my case it's almost always to trigger some api call once all input values are present and then whenever either one changes.

My solution is to use two or more local BehaviorSubjects and a combineLatest to accomplish this behavior.
BehaviorSubject for use cases where I need to access its current value synchronously, otherwise a ReplaySubject(1) is also fine.

<some-cmp [itemid]="activeItemId$ | async" [userId]="activeUserId$ | async"></some-cmp>

@Input() set itemId (id){this.itemId$.next(id)};
@Input() set userId (id){this.userId$.next(id)};

itemId$ = new BehaviourSubject$(null);
userId$ = new BehaviourSubbject$(null);

ngOnInt(){
    combineLatest([
        this.itemId$.pipe(filter(item=>!!item)),
        this.userId$.pipe(filter(item=>!!item))
    ]).pipe(
        debounceTime(10),
        switchMap(...)
    ).subscribe(...)
}

[simeyla]

I'm assuming part of the delay getting this feature is related to change detection and ensuring everything works as efficiently as possible within change detection cycles. But clearly those nuances are the whole reason why we need framework support for something like this in the first place.

I'd even be fine with observable lifecycle hooks to solve this right now. Just tell me 'reactively' when OnChanges is called!

constructor(private lifecycle: LifecycleHooks)     // this doesn't exist
{

}

// Normal input property, no change needed to infrastructure
@Input('date')
date: Date;

model = {
    nextWeek$: this.lifeCycle.onChanges.pipe(map(inputs => {

         // notice that I just access 'this.date' here and it's a normal input
         return new Date(this.date.getTime() + 7 * 24 * 60 * 60 * 1000).toString();
    }))
}

Then in the template:

Next week is {{ model.nextWeek$ | async }}

In fact if injected services were notified with a hook for ngOnChanges (in addition to the ngOnInit and ngOnDestroy hooks we already have today) I could make this class myself!

A big advantage of this method is you won't run through your 'observable chain' until all the inputs are initially set and/or changed later. Let's say your component has three @input() property values that you've shoehorned into BehaviorSubject instances. You also have an injected service providing some other value. If you combine everything using combineLatest it's quite possible your logic will be run four times as each of those inputs gets set! Yes it's probably easy to avoid this if you realize it's happening, but it's easy to overlook. Hooking into ngOnChanges like this would guarantee to just give you one 'trigger' for all three of the inputs.

One of the best parts of 'early angular' was they just went for it and made mistakes and told us 'sorry we changed the way this works'. I'm sure I'm not the only person that just wants some way to do it - even if it changes later.

PS. Excuse my lack of imagination right now coming up with a smarter example that combined multiple observables.

[jessicajaniuk]

Thank you for submitting this feature request. The team has reviewed the feature request and has decided not to move forward with it. Turning inputs into Observables would more tightly couple Angular with RxJS, and we don't want to further couple with RxJS until we can discuss more broadly how we can utilize streamable / subscribeable APIs in a library agnostic way. You can see the related issue list for more information.

[DmitryEfimenko]

well, that's very disappointing

[satanTime]

You broke my heart

[simeyla]

So back to reinventing the wheel every time I need to do this - in a slightly different way each time :-(

[Lonli-Lokli]

At least it's fair, even too late.
More frustrating is the root of this decision - Angular team want to move away from Rxjs. As for me it's the first sign to move away from Angular.

[Jopie64]

I feel that this decision is wrong in many ways.

• Angular and RxJS go hand in hand from the beginning. In fact I came to know RxJS thanks to Angular. I don't think this was a bad decision. It was a nice standard way for Angular to be reactive. For me the places where it was not used, like @Input or lifecycle hooks, feel out of tone from the rest of Angular.
• How do you plan to remove or replace Angular's dependency on RxJS without introducing a massive backward incompatibility breakup like in the AngularJS -> Angular 2+ era? Don't repeat history but learn from it!
• If you manage to not create backward incompatibility issues, then why do you think that introducing input as observable will?
• It already is possible to merely see the usage of observable/observer as a Subscribable pattern. RxJS was meant to be functionality around this pattern. But because Observable was not an ECMA standard like Promise, Observable was included in RxJS. If I remember correctly, Ben Lesh regrets his decision not to make Observable a separate lib apart from RxJS, because now the two are seen as one while in fact they are not.

I hope this decision is reverted soon and Angular will return to it's declarative reactive path instead of holding on to partly forcing users to use error prone imperative reactiveness.

[fxck]

Well, that's a disappointing decision. I don't at all agree with the reasoning, you already coupled Angular with rxjs years ago and kinda left those actually utilizing it in the middle of the road, refusing to address the pain points for years until finally giving up altogether.

I'm not moving away from Angular, I'm way too deep in, but man, it's sad to see what has become of this framework (and I've been here since the early alphas!), the excitement is all but gone. I can't remember the last release that actually improved developer quality of life. I really hope that at some point Angular will at least provide enough extension points to properly integrate features such as this one without having to resolve to hackarounds.

[lazarljubenovic]

Over 99% of messages here have never been responded to by a team member. In fact, there are only five (5) replies by team members, the first one being 5 years after opening the issue: 2020-04-27, by mgechev; 2020-04-28, by mgechev; 2020-05-18, by mgechev; 2021-01-07, by mhevery; 2021-05-27, by JoostK, off-topic.

After over 6 years, 250 upvotes and 300 comments, the issue gets closed with a generic comment of three and a half lines in size, by a person who has never before participated in the discussion.

we pledge to respect everyone who contributes

Apparently, respect doesn't include responding to the most popular issue with hundreds of ideas?

We promise to extend courtesy and respect to everyone involved in this project

Extend the courtesy and respect to everyone? Nah. Just close it with a stock reply after six years.

If you are subject to or witness unacceptable behavior, or have any other concerns, please email us at conduct@angular.io.

But at least there's a way to combat disrespect. Thank you, Angular!

[mlc-mlapis]

Probably everyone is anxiously awaiting what will follow as the next step. Currently, ~ 3/4 has been done, and ~ 1/4 is missing. Is it possible to think realistically about some magic idea that will connect the current state with some new all-embracing solution without massive breaking changes? After all, everything speaks in favor of the idea of finishing the remaining ~ 1/4 (like observable inputs, observable lifecycle hook streams, cold event template streams, ...), especially when many things it is not possible to move forward only by community efforts because changes are required at the internal level (compiler, ...). The current position of the Angular team does not make sense for this topic.

[insidewhy]

Turning inputs into Observables would more tightly couple Angular with RxJS, and we don't want to further couple with RxJS until we can discuss more broadly how we can utilize streamable / subscribeable APIs in a library agnostic way

This request wasn't about turning inputs into Observables, so it would not have increased coupling between Angular and rxjs. All we were asking for was an option, one that would have reduced lots of boilerplate in our code and made us happier to use Angular. Given that the compiler only includes code one is actually using in the final build, it wouldn't have even had any effect on those who didn't want to use it.

It would have been nice if at least we could write libraries to provide this feature. Yet all the libraries in this thread either have problems with boilerplate, subscription leaks, or stopped working due to Angular updates.

[zamzowd]

until we can discuss more broadly how we can utilize streamable / subscribeable APIs in a library agnostic way.

Why is this discussion necessary? Why can't Angular just continue to use streamable / subscribable implementation of RxJS?

If we do need this discussion, then can we get on that? This is just kicking the can down the road, not actually addressing the request raised in this issue.

[bryanrideshark]

You don't have to tightly couple it to rxjs to deliver this feature. You could make the construction of the Observables an injectable part of the framework, "ObservableFactory", just like how HttpClient is an injectable part of the framework. Folks could provide their own ObservableFactory, then they get to use core-js or whatever they want, and it would be over and done with.

Also, if you're wanting to move away from a tight coupling on rxjs (which I don't get the motivation behind at all), you're going to need to implement some sort of "ObservableFactory" anyway.

Please reconsider. If you don't, at least give us more rationale. There are so many ways to solve the reason you gave for closing it.

[pauldraper]

would more tightly couple Angular with RxJS

@angular/common @angular/elements @angular/forms @angular/router: "Am I a joke to you?"

[jessicajaniuk]

Thanks for all the discussion here. We just want to be clear that though we closed this issue, we are aware that it's a highly wanted feature. We aren't just ignoring it and do plan to address the feature need. We looked at this issue as a team and during our discussion, we decided that just implementing Observable for Inputs does have some drawbacks that we need to consider. We have no plans to divest in RxJS. We just were uncertain that in this case Observable was the best choice for streamable implementation as it has a lack of await support. Based on this feature request, we want to look at subscribable / "stream" based APIs in Angular holistically rather than just at this one issue in isolation, which is why the list of cross cutting issues related to this was posted. There will be a future feature proposal for streamables and component interaction that looks at this need as a whole. We will post a link to that feature request / issue on this thread once it's created.

[Airblader]

@jessicajaniuk And do you have a (rough) timeline for that proposal?

This is understandably frustrating for every user, because the crack in the door is kept open for a magical candy future where it will be addressed. That time hasn't come in the past six years(!), and without any meaningful statement, I doubt people will believe it'll happen in the next ten years either (I certainly don't).

I also don't understand why the team chooses to do all of these things (assuming that they are in fact being done) behind Google curtains rather than transparently out in the open. If the team truly is discussing these plans behind the scenes, there are so many ways to do so while keeping the community informed (even if you keep us read-only).

[mlc-mlapis]

There will be a future feature proposal for streamables and component interaction that looks at this need as a whole. We will post a link to that feature request / issue on this thread once it's created.

@jessicajaniuk This sounds promising, and at the same time, it seems that the Angular team already has the basis of the proposed concept. If this is true, then the entire Angular community would very much welcome the publication of at least the basic building blocks of this concept and principled logic in the relatively foreseeable future. Is it possible to consider, say, about 4 - 6 weeks?

[abdulkareemnalband]

Angular Component already has dependency on rxjs because of @Output and EventEmitter

I propose following solution without any breaking changes

Input as observable could exposed as same as current @Output implementation

The API could like

@ObservableInput() name = something_which_returns_an_observer();

And it could be used in template as any other input,

<prefix-component [name]="value"></>

Component Consumer does not need to worry about, whether component's input is defined using @ObservableInput() or @Input() , that is just internal implantation detail for said component

[abdulkareemnalband]

something_which_returns_an_observer could be Subject , ReplaySubject or BehaviorSubject

If component author wants values as they arrive he can use

@ObservableInput() name = new Subject();

If component author wants values only when they are provided by template

@ObservableInput() name = new ReplaySubject(1);

If component author wants have a default value also then he can use

@ObservableInput() name = new BehaviorSubject(default_value);

[pauldraper]

In the thread's spirit of half-assed third-party solutions to this common problem, I present my 30 line implementation: neo-observable-input.

AFAIK unlike all other solutions proposed, this isn't a hack and it works with input typechecking in templates.

Usage:

import { Component, OnChanges } from "@angular/core";
import { ObservableInputs } from "neo-observable-input";

@Component({ template: "" })
export class ExampleComponent implements OnChanges {
  private readonly inputs = new ObservableInputs();

  @Input()
  color: string;
  color$ = this.inputs.observe(() => this.color);

  @Input()
  count: number;
  count$ = this.inputs.observe(() => this.count);

  ngOnChanges() {
    this.inputs.onChanges();
  }
}

[mgechev]

Let me quickly follow up here as well. As we've discussed in the past, the community is very split when it comes to using less or more RxJS with Angular. The majority of folks on GitHub are advanced developers who feel comfortable with RxJS, which makes the feedback we get here a bit more skewed towards more RxJS. Additionally, we're mindful of the JavaScript we ship as part of the critical loading path of an application. Having RxJS as a hard dependency automatically adds extra KBs.

That's why we want to explore the alternative of making RxJS optional for @angular/core in the future. There would be ways to achieve this with minimal breaking changes that we can automatically migrate because the framework's (@angular/core) runtime has a very lightweight dependency on RxJS.

It's also essential for us to provide an ergonomic solution for people who want to embrace a more declarative and expressive development style with RxJS. We can do this without introducing additional coupling with RxJS. For example, we could look into the shape of the input and treat it differently if it is observable-like. This way, we can avoid a hard dependency on RxJS, and we'd also support more advanced use cases.

That said, we have many solutions in mind, and this thread offers tens of other exciting options to explore. We closed the issue because of two main reasons:

1. We want to ensure the API we implement is coherent with other parts of the framework. We don't want a one-off API, which works with observables and looks entirely out of place. Even though 30 line implementations could satisfy the basic requirements, we want to guarantee consistency with the rest of Angular, which will require planning, investigation, and more time.
2. We want to be honest with what we can achieve in a specific timeframe and communicate that well with the community. It was not ideal in the first place that we kept the issue open for six years, posting sporadic comments. We unintentionally sent mixed messages and set unrealistic expectations with that communication pattern even though we were not close to implementing the feature.

Since we want to set more realistic expectations in the future, we will share our plans for more ergonomic RxJS APIs when we prioritize that project. We'll make sure to follow up with an RFC and other resources that capture prior work and suggestions from the community to ensure we cover all the requirements of folks.

Until we get there, I'd recommend using the community solutions that already exist and follow the roadmap for updates.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}