안녕하세요 @laco0416 - 당신의 영어는 괜찮습니다, 걱정하지 마세요!

저는 이 아이디어가 매우 마음에 듭니다. 이전에 논의한 바 있습니다. 또한 https://github.com/angular/angular/issues/4062 (보기 이벤트 관찰) 및 https://github.com/angular/angular/issues/5467 (부모로부터 관찰 가능한 자식 이벤트)과도 잘 맞습니다.

모든 사람이 Observable을 사용하고 싶어하는 것은 아니므로(이 사람들은 놓치고 있습니다!) 두 사용 사례에 대한 옵션을 제공해야 하므로 @Input() 를 Observable로 직접 만들 가능성은 거의 없습니다. @ObserveInput() 같은 것이 있으면 효과가 있을 거라고 생각합니다. 우리는 _이후_ 베타를 출시하여 제 생각에 더 흥미로운 기능 중 일부에 대해 논의할 것입니다.

그 동안에는 이 아이디어의 기본(그리고 _매우_ 실험적!!! 실제로 하지 마세요) 구현이 있습니다. 이것이 당신이 생각하고 있던 개념적입니까? http://plnkr.co/edit/Nvyd9IPBZp9OE2widOcW?p=preview

자식 구성 요소에서 입력 속성을 변경하는 것은 매우 나쁜 생각이라고 생각합니다. 입력 속성은 "읽기 전용"이어야 합니다. 데이터는 항상 상위에서 하위로 이동해야 하며 반대 방향으로는 절대 흐르지 않아야 합니다.

@alexpods 저는 여기에 있는 아이디어가 정확히 - 입력 속성의 변경을 _듣는__ 관찰 가능하고, 값을 업스트림으로 내보내지 않고, 내가 우려하는 한 절대적으로 괜찮은 것이라고 믿습니다.

@robwormald

당신의 영어는 괜찮습니다, 걱정 마세요!

감사합니다! 정말 안심이 됩니다.

당신의 @ObserveInput 는 내가 원하는 것입니다!
또한 @Input 에는 주요 변경 사항이 없습니다. 아주 좋은 해결책이라고 생각합니다.

@alexpods 저도 그렇습니다.

입력 속성의 변경 사항을 Observable로 수신 대기하고 값을 업스트림으로 내보내지 않습니다.

나는 Rob과 같은 방식으로 생각합니다.

@laco0416 앗 , 오해해서 죄송합니다. "자식 구성 요소에서 입력 속성이 변경된 경우"라는 문구가 나를 혼란스럽게 했습니다.

여기에 댓글을 달아야 하는지 아니면 새 문제를 열어야 하는지 모르겠습니다. 잘못된 위치에 요청을 추가하는 경우 알려주십시오.

나는 그런 데코레이터를 작성하려고 시도했지만(지금까지는 실패했지만) @robwormald 의 plunkr 을 우연히 발견했는데 _거의_ 완벽하게(그러나 완전히는 아님) 작동합니다.

이 접근 방식이 저를 흥분시킨 것은 ngOnChanges 수명 주기 후크에 활용하고 있다는 사실이었습니다.
내가 보고 싶은 것은 onChanges$: Observable<{[key: string]: SimpleChange}> , onInit$: Observable<{}> 등과 같이 _all_ 수명 주기 후크가 Observable로 노출되는 방법입니다.

모든 수명 주기 후크를 Observable로 사용할 수 있게 하면 모든 것을 Rx하는 데 도움이 됩니다 ;-)

이에 대한 업데이트가 있습니까?

AFAIK, 아니.
@robwormald 소식이 있나요?

나는 이것이 오래되었다는 것을 알고 있지만 이것은 좋을 것입니다! @robwormald 이것에 대해

@robwormald 의 @ObserveInput 데코레이터가 하는 것처럼 @Input 속성 값을 Observable로 변경하는 것을 제공하고 싶습니다. 특히 기존(Angular 1) 응용 프로그램을 마이그레이션할 때 부모 구성 요소가 Observable을 전달하도록 하는 것이 항상 가능한 것은 아닙니다. 그러나 단일 구성 요소 내에 Observable을 "포함"할 수 없다는 것은 RxJS의 강력함과 우아함을 활용하는 것을 훨씬 어렵게 만듭니다.

불행히도 Rob은 이 버전의 @ObserveInput 를 사용하지 말라고 말한 것은 농담이 아닙니다. 내가 겪고 있는 문제는 Observable이 "클래스 수준"(해당 용어가 의미가 있는 경우)에서 생성되어 구성 요소의 모든 인스턴스에서 공유된다는 것입니다. 이것은 분명히 좋지 않습니다. 인스턴스화 시간에 Observable을 생성하는 것도 저에게 효과가 없었습니다. Angular가 이 경우 변경 감지를 올바르게 연결하지 않는 것 같습니다.

@ObserveInput 의 더 나은 구현을 관리한 사람이 있습니까? 아니면 공식 지원에 대한 소식이 있습니까?

@lephyrus 공식 @ObserveInput 데코레이터는 매우 훌륭하지만 @Input 속성 값을 변경하는 Observable을 얻기 위해 꼭 필요한 것은 아닙니다. 데코레이터는 단순히 매우 우아한 "설탕"입니다.

이미 수명 주기 이벤트 ngOnChanges 있습니다. ngOnChanges 내부에서 rxjs Subject 를 사용하여 변경 사항을 관찰할 수 있습니다. 예:

<strong i="13">@Input</strong> 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);
    });
}

또는 더 재사용 가능한 것을 원하면 구성 요소 extends 기본 클래스를 만들 수 있습니다.

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);
    }
}

... 다음과 같이 사용할 수 있습니다.

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

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

공식 @ObserveInput 데코레이터를 사용할 수 있을 때까지 이 접근 방식을 사용하고 있습니다.

@wmaurer님, 감사합니다. 귀하의 ReactiveComponent 는 매우 환영합니다. 흠잡을 데 없는 코드와 안전한 타이핑을 사용하여 부팅할 수 있습니다. 정말 좋습니다! 중요한 것은 테스트에서도 잘 작동하며 OnPush 변경 감지 전략을 계속 사용할 수 있다는 것입니다. 이제 "공식 설탕"을 기다리게 되어 기쁩니다. (또한 Observable.create() 논리를 사용해야 하는 이유를 알게 되면 뭔가를 배우게 될 것이라고 확신합니다. 아직 살펴볼 시간이 없습니다.) 다시: merci gäll! :눈짓:

@lephyrus 천만 에요, gärn gescheh ;-)

내가 사용 Observable.create() 잡아 얻을 Observer 할 수 있도록하기 위해 next() . 내가 사용했을 수있는 Subject 인을 둘 모두 Observable 와 Observer , 그러나 나는 그것이 '노출'에 일반적으로 나쁜 관행 믿습니다 Subject ( Observer ).

@laco0416 은 https://github.com/angular/angular/issues/13248 에 찬성하여 마감합니까?

@DzmitryShylovich 아니요.

@ObserveInput 정말 멋질 것입니다! :+1:

좋은 예를 보여주신 @wmaurer님 감사합니다. 하지만 한 가지 질문이 있습니다. 관찰 가능 개체로 문자열 대신 객체를 사용할 수 있기를 원합니다.

예

@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;
}

그러나 this.updateChart 및 ngOnChanges는 호출되지 않습니다. 대신에 개체를 관찰하기 위해 간단한 문자열에서 샘플을 확장하는 방법은 무엇입니까?

@ChrisWorks 객체에서도 작동해야 합니다.

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

나는 이것을 매우 자주 수행하므로 이것이 작동하지 않으면 어딘가에 구성 요소에 대한 입력에 문제가 있다고 생각합니다.

안녕하세요 @wmaurer님 , 답변 감사합니다. "config" 개체를 사용하는 작업 버전으로 샘플을 확장할 수 있습니까? 나는 단순히 내 일을 할 수 없습니다. 샘플 Git 리포지토리? :)

@ChrisWorks 정말 있는 그대로 작동해야 합니다. observePropertyCurrentValue 는 문자열 입력과 개체를 구분하지 않습니다.
다음은 입력이 문자열뿐만 아니라 모든 다른 유형인 곳에서 만든 정말 오래된 ng2 베타 0 프로젝트입니다.
https://github.com/wmaurer/todomvc-ng2-reactive
예: https://github.com/wmaurer/todomvc-ng2-reactive/blob/master/src/app/todo-item/todo-item.component.ts

+1 이러한 기본적인 사용 사례는 아직 정렬되지 않았다는 것이 믿기지 않습니다!

마침내 최고의 솔루션을 얻었고 AOT 컴파일과 함께 반복 없이 작동합니다. 비밀은 @Input() 를 두 번째 데코레이터와 결합하는 것입니다.

데코레이터:

import { ReplaySubject } from 'rxjs/ReplaySubject'                                                                                                 

const subjects = new WeakMap()                                                                                                                     

export function ObservableInput() {                                                                                                
  return (target, propertyKey) => {                                                                                                                
    delete target[propertyKey]                                                                                                                     

    Object.defineProperty(target, propertyKey, {                                                                                                   
      set(value) {                                                                                                                                 
        this[propertyKey].next(value)                                                                                                              
      },                                                                                                                                                                                                                            
      get() {                                                                                                                                      
        let subject = subjects.get(this)                                                                                                           
        if (! subject)  {                                                                                                                          
          subject = new ReplaySubject<any>(1)                                                                                                      
          subjects.set(this, subject)                                                                                                              
        }                                                                                                                                          
        return subject                                                                                                                             
      },                                                                                                                                           
    })                                                                                                                                             
  }                                                                                                                                                
}                                                                                                                                                  

용법:

class SomeComponent {
  @Input() @ObservableInput()                                                                                                                    
  public index: Observable<number>
}                                                                                                               

편집: 이제 이것을 라이브러리로 만들었습니다. 개선할 아이디어를 받게 되어 기쁩니다. 기존 @Input 를 Observable 보완하는 새로운 방법을 다음에 추가합니다. https://github.com/ohjames/observable-input 참조

그런 일을 해야 한다면 차라리 ngOnChanges: Subject<SimpleChanges> 에 대한 단일 주제 아날로그를 사용하겠습니다.
원하는 경우 여전히 하나의 특정 입력에만 필터링 및 매핑할 수 있습니다.

1 입력당 주제는 getter 및 setter를 생성하기 위해 클래스 소품을 삭제하고 입력 유형이 잘못되었으며 input = value 하면 실제로 관찰 가능한 값을 내보내는 것에 대해 이야기하지 않고 많이 보입니다. 당신의 주제를 완료합니다.

여기 에서 내 아이디어의 구현 예를 찾을 수 있습니다. 데코레이터 접근 방식은 실험적 이지만 상속 접근 방식을 사용하는 것이 매우 안전해야 한다고 생각합니다(여기에 표시하기 위해 지금 수행했으며 사용되지 않음).

@ghetolay 주제가 완료되었는지 여부는 중요하지 않습니다. 보기가 닫히면 스트림에 대한 구독이 더 이상 없고 GC에서

changes$ 는 구성 요소에 대한 BehaviorSubject 인터페이스를 누출합니다. 이상적으로는 Observable<...> 로 입력해야 합니다.

많은 주제의 문제에 관해서는... n 주제를 사용하든 1 를 사용하든 여전히 n 구독이 있습니다. 1개의 주제가 있는 경우 각 구독에 하나의 맵 연산자와 하나의 필터 연산자를 추가하게 되면, 이것의 성능 오버헤드는 n 주제를 사용하는 것보다 훨씬 작지 않을 것이며 더 나쁠 수 있습니다.

입력 매개변수 자체의 타이핑을 무시하는 데코레이터 기반 버전은 any 기반의 SimpleChange 유형보다 옵저버블 소비자에게 더 유형이 안전한 API를 제공합니다.

@ohjames

보기가 닫히면 스트림에 대한 구독이 더 이상 없고 GC에서 삭제할 수 있습니다.

모든 구독이 보기에 연결되고 보기와 동일한 수명 주기를 갖게 된다고 가정합니다. Observable이 어떻게 소비되는지에 대해 어떤 가정도 하지 않습니다.

옵저버블에서 값을 내보내는 것이 기본적으로 이것의 요점입니다. Angular 컴파일러는 현재 입력 속성 유형을 확인하지 않습니다. 더 공식적인 작업을 수행할 때쯤이면 사용할 수 있을 것입니다. ;)

나는 사용자를 위해 사용자가 여전히 속성에 액세스하고 설정할 수 있음을 의미했습니다. 따라서 Observable로 입력된 것을 제외하고는 속성을 숫자인 것처럼 설정하고 속성을 설정하지 않고 방출하게 만듭니다. 이것은 나에게 매우 혼란 스럽습니다.

많은 주제의 문제에 관해서는... n개의 주제를 사용하든 1개의 주제를 사용하든 여전히 n개의 구독이 있습니다. 하나의 주제가 있는 경우 각 구독에 하나의 맵 연산자와 하나의 필터 연산자를 추가하게 되며, 이것의 성능 오버헤드는 n개의 주제를 사용하는 것보다 훨씬 작지 않으며 더 나쁠 수 있습니다.

우리는 곧 주요 목적에 대한 초점을 잃을 것이기 때문에 여기서 이런 종류의 토론에 들어가지 않을 것입니다.

Subject 노출하지 않도록 업데이트했고 변경 사항에 타이핑을 추가하기 위해 무언가를 만들었습니다.
나는 BehaviorSubject 아니라 평범한 Subject 왜냐하면 Observable을 가치 보유자로 보지 않고 시간이 지남에 따라 변화하기 때문입니다.
방금 결함을 찾았습니다. 비동기 파이프를 사용할 때 비동기 파이프가 첫 번째 방출 후에 구독하기 때문에 첫 번째 값이 방출되지 않습니다. 이 경우를 적절하게 처리하기 위해 나중에 코드를 업데이트하겠습니다.

여기 다시 링크가 있습니다: https://stackblitz.com/edit/angular-observableinput?file=observablechanges%2Fimpl.ts

모든 구독이 보기에 연결되고 보기와 동일한 수명 주기를 갖게 된다고 가정합니다. Observable이 어떻게 소비되는지에 대해 어떤 가정도 하지 않습니다.

네 요점을 알겠습니다. Observable을 완료하면 모든 구독이 강제 종료되지만 실제로 걱정할 정도는 아닙니다. 우리 앱에서 구독의 99%는 비동기 파이프를 통해 발생하며, 종종 CombineLatest/switchMap을 통해 Redux/etc에서 제공되는 외부 관찰 가능 항목을 소스로 사용하기 때문에 어쨌든 수동으로 닫을 필요가 없는 소수의 구독입니다.

우리는 곧 주요 목적에 대한 초점을 잃을 것이기 때문에 여기서 이런 종류의 토론에 들어가지 않을 것입니다.

글쎄요 당신은 잘못된 비판을 제기했으므로 그것에 대응할 필요가 있었습니다.

~또한 상속을 통해 클래스를 사용하면 작동하지 않습니다. AOT 컴파일러에 의해 생성된 코드는 상위 클래스에서 수명 주기 메서드를 호출하지 않습니다. https://github.com/angular/angular/issues/12756#issuecomment -260804139를 참조 ngOnDestroy() { super.ngOnDestroy() } 및 ngOnChanges 에 대한 또 하나를 추가해야 합니다. ~ <-- Angular 4.4에서 특정 제한 사항으로 수정된 것 같습니다.

비동기 파이프 사용에 대한 우려 사항을 검토했으며 여전히 입력에 액세스할 수 있으므로 사용법이 의미가 없다고 생각합니다. 템플릿의 입력 값을 바인딩하려는 경우 여기에서 관찰 가능 및 비동기를 사용할 필요 없이 입력에 직접 바인딩할 수 있습니다. 새로운 옵저버블을 구성하려면 원하는 것을 쉽게 얻을 수 있어야 합니다(어딘가에서 startWith ).

그래서 내 이전 진술이 괜찮다고 생각합니다.

Observable을 가치 보유자로 보지 않고 시간이 지남에 따라 변경하기 때문에 BehaviorSubject를 사용하지 않고 일반 Subject를 사용하고 있습니다. 입력 값에 액세스해야 하는 경우 속성이 여전히 존재하며 동기적으로 참조할 수 있습니다.

이 코드는 고도로 실험적이며 일종의 poc일 뿐이며 해당 stackblitz에서만 사용했습니다.
그래서 나는 그것이 꽤 안전 하다고 말하지 말았어야 했고 죄송합니다. 그리고 말씀 하신 대로 AOT에서 작동하지 않을 수도 있습니다.
방금 시도했고 두 가지 접근 방식 모두 현재 AOT(각도 v4.3.6, cli v1.4.1)에서 작동합니다.

여기서 내 요점은 모든 입력 변경 사항을 포함하는 changes 관찰 가능에서 이동하면 연산자를 사용하여 필요한 모든 작업을 수행할 수 있다는 것입니다. 변경, 특정 값에서 다른 값 등으로 변경되었을 때...
원하는 Observable을 구성할 수 있습니다.

또한 구현을 위해 관리할 주제는 1개이고 사용자를 위해 사용할 속성은 입력당 1개뿐입니다.

내가 변경할 수 있는 것은 사용자가 pair 및 map 를 사용하여 SimpleChange 와 같은 종류의 구조를 얻을 수 있으므로 SimpleChanges 개체가 아닌 새 값을 내보내는 것입니다. SimpleChange . 그러나 현재 우리가 얻은 것은 SimpleChanges 이므로 나중에 비슷한 것을 재구성하기 위해 분해하는 것은 어리석은 일입니다.

추신:

글쎄요 당신은 잘못된 비판을 제기했으므로 그것에 대응할 필요가 있었습니다.

당신에게 유효하지 않습니다 .

성능을 언급할 때 개인적인 관점이 아니라 객관적으로 측정할 수 있는 사실입니다. 3명의 주제가 6명의 추가 연산자보다 더 많은 오버헤드와 같다고 느끼며, 아마도 당신이 옳을 수도 있지만 일부 측정을 할 때까지 그것을 믿을 합리적인 근거가 없습니다.

많은 입력에 반응하는 경우... switchMap 또는 CombineLatest 또는 여러 관찰 가능 항목과 함께 작동하도록 설계된 다른 연산자를 사용할 수 있습니다. 당신은 이것에 대해 매우 대담하고 포괄적인 발언을 하고 있습니다. 정말로 이 대화를 계속하고 싶다면 이 이슈 트래커에서 삭제하겠습니다.

다음은 다양한 단점과 장점이 있지만 기본 클래스가 필요한 버전입니다.

import { OnChanges, OnDestroy, SimpleChanges } from '@angular/core'
import { BehaviorSubject } from 'rxjs/BehaviorSubject'
import { Observable } from 'rxjs/Observable'
import 'rxjs/add/operator/map'
import 'rxjs/add/operator/distinctUntilChanged'

export class ChangeObserver implements OnChanges, OnDestroy {
  protected ngChanges = new BehaviorSubject<object>({})

  ngOnChanges(changes: SimpleChanges) {
    const props = { ...this.ngChanges.value }
    for (const propName in changes) {
      props[propName] = changes[propName].currentValue
    }
    this.ngChanges.next(props)
  }

  ngOnDestroy() {
    this.ngChanges.complete()
  }

  changes<K extends keyof this>(key: K): Observable<this[K]>
  changes<V>(key: string): Observable<V>
  changes(key: string) {
    return this.ngChanges.map(props => this.ngChanges.value[key]).distinctUntilChanged()
  }
}

사용하려면:

class MyComponent extends ChangeObserver {
  @Input() public field: string
  // typescript knows this is Observable<string>
  field$ = this.changes('field')

  @Input() private privField: number
  // typescript can't access private stuff from outside the class so we need to help it out
  privField$ = this.changes<number>('privField')
}

내가 문제를 잘못 이해했는지 확실하지 않지만 비동기 파이프가 이 문제를 해결하지 않습니까?
[inputVar]="observableValue | async" ..

@najibla 당신이 잘못 이해했습니다. 입력은 관찰 가능하지 않으므로 비동기 파이프가 도움이되지 않습니다.

@ohjames 제 경우에는 관찰 가능 항목에 대해 비동기 파이프를 사용하여 작동했습니다. 그리고 부모로부터 관찰 가능한 값을 업데이트하면 값이 자식 구성 요소에 반영됩니다.

@najibla 이 github 문제는 @Input 속성을 관찰 가능 항목으로 바꾸는 것입니다. 이것은 설명하는 경우와 거의 관련이 없습니다.

즉, 구성 요소가 관찰 가능 항목을 사용하여 변경되는 입력 속성에 응답하는지 여부는 구성 요소 자체에서 격리되어야 하므로 입력 속성을 보기에서 관찰 가능 항목으로 변환할 필요가 없습니다. 그렇지 않으면 Angular의 일반적인 "관찰 가능한 우선" 접근 방식과 상반되는 속성을 관찰 가능한 것으로 사용하기로 결정한 경우 구성 요소의 인터페이스를 변경해야 합니다.

@icepeng 실제로 당신은 그것을 제대로 이해하지 못했습니다. 이것은 표준 입력을 관찰 가능한 것으로 바꾸는 것에 관한 것입니다. 따라서 새 패턴은 실제로 다음과 같습니다.

<app-child [prop]="prop$ | async"></app-child>

... 그런 다음 prop 내부의 AppChildComponent 에 Observable이 아니더라도 Observable로 액세스할 수 있는 방법을 제공합니다. ). 이제 물론 예에서와 같이 처음에 prop$ 가 있었다면 합리적이지 않은 것처럼 보일 수 있습니다(지금 입력으로 관찰 가능 항목을 이미 전달할 수 있음). 전달 된 입력이 이미 관찰 아닌 경우에는 그 값을 많이 제공한다 (예 index 에서 ngFor ).

옵저버블을 입력으로 전달하는 문제(지금은 완전히 가능함)는 OnPush 제대로 작동하지 않는다는 것입니다.

것을 잘 @fxck 당신 맞아요 ngOnChanges 호출되지 않습니다 때 관찰 방출한다 (입력이 동일하게 유지하기 때문에), 그러나만큼 당신이 비동기 파이프를 사용으로 통과 관측에 가입 @Input 다음 OnPush 는 비동기 파이프가 자식 구성 요소의 변경 감지기를 수동으로 트리거하므로 제대로 작동합니다.

예, @icepeng으로 향했습니다.

@ohjames @fxck 옵저버 블을 전달하는 것이 지금 가능한지 몰랐습니다. 잘못된 정보를 죄송합니다.

Observable을 직접 전달하는 것이 가능하기 때문에 @ObserveInput 가 유용할지 잘 모르겠습니다.
변경할 수 있는 값이 Observable이 아니면 이미 문제라고 생각합니다.
개인적인 의견일 뿐입니다.

@icepeng 이것을 고려하십시오:

<ng-container *ngFor="value in (values$ | async); let i = index">
  <child-component [value]="value" [index]="i"></child-component>
</ng-container>

index 를 후프를 건너 뛰지 않고 여기에서 관찰 가능하게 만드는 방법은 무엇입니까?

또는 타사 라이브러리를 작성 중이고 라이브러리 소비자가 구성 요소에 관찰 가능 항목을 전달하도록 강제하고 싶지 않다고 생각해 보십시오(많은 사용자가 스트림에 익숙하지 않고 rxjs를 사용하지 않음).

이것이 유용한 다른 많은 경우가 있습니다.

@ohjames index 는 child-component 각

BehaviorSubject 접근 방식이 더 나은 것 같습니다. Angular 코어가 이와 같은 @NgChanges() 데코레이터를 제공하면 좋을 것입니다.

{
  @NgChanges() ngChanges$: BehaviorSubject<{ prop: string }>
  @Input() prop: string;

  ngOnInit() {
    this.ngChanges$.subscribe(changes => console.log(changes.prop));
  }
}

이것이 구현 가능한가요?

버퍼 길이가 1인 ReplayObservable이 선호되며 속성에 액세스할 수 있는 경우 BehaviourSubject의 값 의미 체계가 필요하지 않습니다.

구현이 가능한지 여부는 다양한 구현 및 옵션에 대한 문제 내역을 확인하세요. 어느 것도 훌륭하지 않고 일부는 완전히 망가졌습니다. 제대로 하려면 연결된 PR 또는 이와 유사한 것이 필요합니다.

내 2 센트: object.observe가 프록시를 선호하여 평가절하되었기 때문에 내 솔루션은 프록시를 확장한 다음(예, 알 수 없습니다. 생성자에서 반환한 이유) 여기에 속한 키를 수신하는 것입니다. $get(keyName) 메서드를 통해 개체를 Observable로 사용합니다. Angular 클래스 1뿐만 아니라 모든 객체와 함께 사용할 수 있습니다.

import { Observable } from 'rxjs/Observable';
import { Subject } from 'rxjs/Subject';

/**
 * Extends this class to be able to observe any key affectation
 */
class ObservableProxy {
    private changes: Subject<[PropertyKey, any]> = new Subject<[PropertyKey, any]>();

    constructor() {
        return new Proxy(this, {
            set: (object, key, value) => {
                this.changes.next([key, value]);
                object[key] = value;
                return true;
            }
        });
    }

    public $get<K extends keyof this>(key: K): Observable<this[K]> {
        const value: this[K] = this[key];

        const startWith: Observable<this[K]> = Observable.of(value)
            .filter((initialValue) => // remove this filter if you dont mind receiving an undefined value on subscription
                initialValue !== undefined;
            );

        return this.changes
            .filter(([changedKey]) => {
                return changedKey === key;
            })
            .map(([changedKey, nextValue]) => nextValue)
            .merge(startWith);
    }
}

예시:

class User extends ObservableProxy {
public name: string;
}

const user: User = new User();
user.$get("name").subscribe((value)=> {
console.log(value);
})

user.name = "toto"; // prints console.log("toto")

@robwormald , 이 문제에 대한 관심이 있습니까? 확실히 사용하기 쉽게 만드는 데 큰 도움이 될 것입니다.

@bryanrideshark 이것이 지원될 가장 좋은 기회는 https://github.com/angular/angular/issues/10185를 통하는 것입니다. 제 생각에는 PR이 이 문제와 연결되지 않은 것에 놀랐습니다.

이것은 우리가 Ivy를 배송할 때까지 일어나지 않을 것입니다
2018년 2월 21일 수요일 오전 7시 56분에 James Pike [email protected]에서 다음과 같이 썼습니다.

@bryanrideshark https://github.com/bryanrideshark 최고의 기회
이것은 #10185를 통해 지원됩니다.
https://github.com/angular/angular/issues/10185 제 생각에는 놀랐습니다.
PR은 이 문제와 관련이 없습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/angular/angular/issues/5689#issuecomment-367372931 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAgpkvtGA4w8uHgiz0QsdYwBgqgM2EpAks5tXDyWgaJpZM4Gwr8f
.

당신의 영어는 훌륭하고 당신의 각도는 더 큽니다.

@pldin601 귀하의 방법은 AOT 컴파일된 코드를 지원하지 않으므로 대부분의 사람들의 프로덕션 코드에 대해 막대한 메모리 누수가 발생합니다. 대신 AOT와 잘 작동하는 observable-input 패키지를 확인하십시오.

@pldin601 코드의 문제는 ngOnDestroy 수명 주기 메서드를 동적으로 추가한다는 것입니다. AOT 컴파일된 코드는 컴파일러가 그 존재를 정적으로 추론할 수 있는 경우에만 ngOnDestroy 호출합니다. 따라서 데코레이터를 사용하는 모든 구성 요소가 ngOnDestory 도 정의하는 경우에만 메서드가 작동합니다(필요하지 않은 경우 비어 있을 수 있음). 다른 모든 경우에는 구독이 누출되어 구성 요소가 가비지 수집되는 것을 방지합니다.

섹션 3.2가 완료된 후에 일어날 것 같습니까(이 필요성이 고려되기를 바랍니다)?
https://is-angular-ivy-ready.firebaseapp.com/#/status

Ivy가 7.0.0에 포함될 예정입니까?

속성을 관찰 가능한 동반자 속성에 바인딩할 수 있는 데코레이터를 구현했습니다. 각도 입력 속성뿐만 아니라 다른 속성에도 사용할 수 있습니다. @ohjames 의 @ObservableInput() 데코레이터에서 영감을 얻었지만 Observable을 제공하기 위해 다른 속성을 사용하여 속성 getter와 setter 간의 유형 불일치로 인해 발생할 수 있는 문제를 방지합니다.

https://github.com/PSanetra/bind-observable

예시:

class MyClass {

  @BindObservable()
  public myProp: string = 'initialValue';
  public myProp$!: Observable<string>;

}

const myInstance = new MyClass();

myInstance.myProp$.subscribe(console.log);

myInstance.myProp = 'newValue'

이 코드는 'initialValue' 및 'newValue' 을 콘솔에 인쇄합니다.

observable-input 패키지가 지금까지 출시될 시기에 대한 업데이트는 아무 것도 깨지 않고 하위 분류 없이 가장 우아한 것처럼 보입니다. @ohjames 이 시점에서 얼마나 안정적이고 잘 테스트되었습니까?

공식 지원이 더 성숙해지고 버전 전반에 걸쳐 지속적인 지원이 보장되고 더 부드러운 개발 경험이 보장될 것이라고 생각합니다./개발자가 전체 rxjs*로 전환하고 푸시 변경 감지로 최적화하도록 장려할 것입니다(내 생각에 핵심적인 획기적인 기능이어야 함)

* 관찰할 수 없는 입력과의 호환성을 손상시키지 않거나 하이브리드 입력을 위한 추가 상용구가 필요하지 않음

aot가 있거나 없는 각도 4, 5 및 7에서 관찰 가능한 입력을 사용했습니다. 잘 작동하는 것 같습니다. 나는 그것을 썼을 때 내가 무엇을 하고 있었는지 막연하게 알고 있었다고 확신한다.

프레임워크에 추가하고 사용을 권장하기를 바랍니다. 2주간 다운로드 npm은 추가하면 xD가 제공하는 이점에 비해 충분하지 않습니다. 사람들이 그 접근 방식을 따르는 것이 간단하다는 것을 알게 될 것입니다.

사용자 정의 observer 비동기 입력에 대해 다음 API를 제안합니다.

decalre function AsyncInput(bindName?:string) : <T extends Observer>(target: Object, propertyKey: string, descriptor: TypedPropertyDescriptor<T>) => any

사용자는 그대로 사용할 수 있습니다.

@AsyncInput()
asynchronusProperty1 = new Subject();

@AsyncInput()
asynchronusProperty2 = new ReplySubject(1);

@AsyncInput()
asynchronusProperty3 = new UserObserver(); // where UserObserver implement `Observer` interface

Angular 내부는 값이 변경될 때마다 observer.next(newValue) 호출할 수 있습니다.

@HostBinding 지원도 잊지 마세요!

이것은 생성자 @Input 주입과 결합하여 훨씬 더 멋지게 만들어야 합니다. 이렇게 하면 매우 우아한 방식으로 "strictPropertyInitialization"을 수정할 수 있습니다.

class MyComponent {
  inputData$: Observable<Data>;
  constant: string;

  constructor(
    @Input() inputData$: Observable<Data>,
    @Input() constantString: string
  ) {
    this.inputData$ = inputData$;
    this.constant = constantString;
  }

}

@benneq 는 다음과 같이 작을 수 있다는 점에 주목할 가치가 있습니다.

class MyComponent {
  constructor(
    @Input() private inputData$: Observable<Data>,
    @Input() private constantString: string,
  ) {}
}

@maxime1992 네, 관찰 가능 항목이 한 구성 요소에서 다른 구성 요소로 전달되는 경우를 구분하려면 입력 항목에 대해 별도의 데코레이터가 필요합니다.

@benneq @maxime1992 매개변수 이름은 데코레이터 메타데이터의 일부가 아닙니다. 어떻게 매핑하나요?

@trotyl 그러면 @Input('paramName') private myParam: Observable<Data> 를 사용할 수 있을 것 같습니다.

@trotyl @benneq 네, 제 잘못입니다. 신경쓰지 마세요 :zipper_mouth_face:

누군가 이미 이 솔루션을 게시했는지는 모르겠지만 이것은 상당히 좋은 해결 방법입니다.

@ElianCordoba 이것은 HTML <input> 에 관한 것이 아닙니다. 각 @Input()

그것은 다르지만 비슷하게 고통스러운 문제 @ElianCordoba입니다. https://github.com/angular/angular/issues/13248

나는 이것이 의사 요구 사항이라고 생각합니다. 첫째, 입력 데코레이터는 Observable 유형 값을 받아들일 수 있습니다. 둘째, 구성 요소가 입력으로 관찰 가능을 요구하는 경우 관찰 가능하지 않은 값을 수신할 때 조용히 Observable 유형 값으로 변환하는 대신 명시적으로 오류를 발생시켜야 합니다.

자바스크립트의 암시적 유형 변환과 매우 유사하여 버그를 유발하고 찾기 어려울 수도 있습니다.

잘못된 입력을 침묵시키는 것이 아닙니다. 컴포넌트 간에 공통 인터페이스를 노출하는 것입니다(관찰할 수 없는 입력임). 이를 통해 외부 세계에서 인터페이스를 손상시키지 않고 rx 기능을 자유롭게 도입할 수 있습니다. 또 다른 이점은 주로 변경 가능성과 내부 상태를 들어 올리는 것입니다. 모든 것이 입력의 변환이므로 해당 지점에서 푸시 변경 감지를 더 이상 생각할 필요가 없습니다.

반대로 옵저버블을 요구하는 인터페이스를 노출하는 것은 투박하게 들릴 뿐 아니라 구성 요소가 그렇게 이상하게 들린다는 이유만으로 사람들이 of(value)를 제공하도록 강요합니다.

또한 자동 변환이 아니라 rxjs를 통해 변경 사항을 구독하는 API입니다. angular.http와 라우터가 옵저버블을 제공하는 경우 입력 변경 처리가 제공하지 않는 것이 매우 어색합니다. 콜백 및 RxJ의 세계를 통합하려면 너무 많은 보일러 플레이트가 필요합니다.

위의 영리한 솔루션 중 일부가 마음에 들지 않는다는 것은 아니지만 때로는 '표준' 방식을 약간만 재구성하면 명확성/서투른 부족이라는 실제 문제를 해결하기에 충분합니다. 게다가 나는 여전히 언젠가 이것을 할 아이비 이후의 '공식적인' 방법을 기대하고 있습니다.

@Input('isOuterPanel')
set isOuterPanel(value: CheckoutPanelHeaderSettings)
{
    this.inputs.outerPanel$.next(value);
}

@Input('config')
set config(value: CheckoutPanelHeaderSettings)
{
    this.inputs.config$.next(value);
}

// observables for <strong i="6">@Inputs</strong>
inputs = {
    config$: new BehaviorSubject<CheckoutPanelHeaderSettings>(1),
    outerPanel$: new BehaviorSubject<CheckoutPanelHeaderSettings>(1)
};

그런 다음 combineLatest(this.service.magicInput$, this.inputs, config$)...... 와 같은 것을 입력하여 RxJS와 입력을 결합할 수 있습니다.

BehaviorSubject 또는 ReplaySubject 작동합니다. BehaviorSubject는 일반적으로 더 안전하고 예측 가능합니다.

• BehaviorSubject - 기본값이 있는 경우 사용
• ReplaySubject - 입력 값 설정을 잊어버린 경우 관찰 가능 항목이 방출되지 않습니다.

이것은 코드를 명확하게 하는 데 도움이 될 뿐만 아니라 모든 입력을 함께 그룹화하기 때문에 this.inputs. 하고 자동 완성을 가져옴으로써 '순수한' 관찰 가능한 입력이 무엇인지 쉽게 확인할 수 있습니다.

이것으로 유형 안전성을 더 높일 수 있습니다(대부분 이것은 단지 재미를 위한 것입니다).

// define this globally to 'unwrap' a property 'inputs' with an object of ReplaySubject / BehaviorSubject
export type InputTypes<T extends { inputs: { [key: string]: ReplaySubject<any> | BehaviorSubject<any> } }> = {
    [P in keyof T['inputs']]: T['inputs'][P] extends Observable<infer X> ? X : unknown;
}

// define a local 'InputType' helper above each component
type InputType = InputTypes<CheckoutSmartHeaderComponent>;

그러면 @Input 속성의 유형을 명시적으로 지정할 필요가 없습니다.

@Input('config')
set config(value: InputType['config$'])
{
    this.inputs.config$.next(value);
}

구성 요소가 inputs 를 적용하도록 ObservableInputs 인터페이스를 만들 수도 있었지만, 이것을 망쳐놓으면 어쨌든 컴파일되지 않을 것이기 때문에 그렇게 하지 않기로 결정했습니다.

@simeyla 너무 많은 상용구.

나는 내 자신의 데코레이터를 거기에 두기로 결정했습니다. 내 첫 번째 npm 패키지이므로 누락된 것이 있다고 확신하지만 여기에 있습니다. https://www.npmjs.com/package/@ng-reactive/async -input

설치

npm install @ng-reactive/async-input --save

용법

import { Component, Input } from '@angular/core';
import { AsyncInput } from '@ng-reactive/async-input';
import { BehaviorSubject } from 'rxjs';

@Component({
  selector: 'app-hello',
  templateUrl: './hello.component.html',
  styleUrls: ['./hello.component.css']
})
export class HelloComponent {
  @Input() name: string;
  @AsyncInput() name$ = new BehaviorSubject('Default Name');

  constructor() {
    this.name$.subscribe(name => console.log('from async input', name));
  }
}

@ mfp22 정말 좋습니다. 이런 것이 내장되어서는 안되는 이유가 없습니다. 참고로, 패키지에 대한 npm의 github 링크가 오래되었습니다. 여기로 이동합니다.

https://github.com/mfp22/async-input/tree/master/projects/async-input

나는 이것이 꽤 오래된 문제라는 것을 알지만 그 기능은 꽤 놀랍고 Angular에서 그것을 보게 되어 정말 기쁩니다.

더 멋진 것은 관찰 가능한 입력을 사용하면 OnChanges 후크가 필요하지 않다는 것입니다. pairwise rxjs 연산자를 사용하여 관찰 가능한 입력의 이전 및 현재 값을 얻을 수 있습니다.

@Component({...})
class MyReactiveComponent {
  @ObservableInput() prop: Observable<string>; // Whatever syntax may be...

  // emits [prevValue, currValue] and no OnChanges hook yay!!
  propChanges$ = this.prop.pipe(pairwise());
}

https://github.com/rx-ts/ngrx/blob/master/src/utils/decorators.ts#L56 -L124

제 개인적인 구현으로 완벽하고 아주 훌륭하게 작동합니다. 내장할 수 있다면 정말 멋진 일입니다.

내 프로젝트에서 개인적으로 사용한 솔루션을 npm 패키지로 게시했습니다.

https://github.com/futhark/ngx-observable-input

설치

npm install ngx-observable-input

용법

...
<image-item [url]="currentImageUrl"></image-item>

import { Component, Input } from "@angular/core";
import { ObservableInput } from "ngx-observable-input";
import { Observable } from "rxjs";

@Component({
    selector: "image-item",
    template: `<img [src]="url$ | async" />`
})
export class GalleryComponent {
    @ObservableInput() @Input("url") public url$: Observable<string>;

    ...
}

나는 이것이 꽤 오래된 문제라는 것을 알지만 그 기능은 꽤 놀랍고 Angular에서 그것을 보게 되어 정말 기쁩니다.

더 멋진 것은 관찰 가능한 입력을 사용하면 OnChanges 후크가 필요하지 않다는 것입니다. pairwise rxjs 연산자를 사용하여 관찰 가능한 입력의 이전 및 현재 값을 얻을 수 있습니다.

@Component({...})
class MyReactiveComponent {
  @ObservableInput() prop: Observable<string>; // Whatever syntax may be...

  // emits [prevValue, currValue] and no OnChanges hook yay!!
  propChanges$ = this.prop.pipe(pairwise());
}

이것은 또한 잠시 동안 나를 괴롭히는 문제이므로 조금 조사했고 여기에서 언급한 것과 동일한 솔루션을 생각해 냈습니다(@gund).

내부적으로 @Input 데코레이터를 확장하고 이러한 종류의 구성을 허용하는 작은 데코레이터 도우미( @ObservableInput )를 구현했습니다. 여기에서 확인할 수 있습니다( npm 패키지로도 사용 ). 간단한 예제로 테스트해 보았지만 확장 프로젝트에 사용할 시간이 없었습니다. 어떤 피드백이든 환영합니다 :)

사용 예는 다음과 같습니다.

@Component({
  selector: 'app-test',
  template: `<span>{{ message$ | async }}</span>`
})
class TestComponent {
  @ObservableInput<number>('price') price$: Observable<number>;
  @ObservableInput<string>('name') name$: Observable<string>;

  message$ = combineLatest(this.price$, this.name$).pipe(
    map(([price, name]) => `${name} costs {price}`)
  );
}

그리고 이 구성 요소는 다음과 같이 사용할 수 있습니다.

<app-test [price]="price"
          [name]="name">
</app-test>

@aleics 이것이 AOT 컴파일러와 함께 작동할 것이라고 확신합니까?

@aleics 이것이 AOT 컴파일러와 함께 작동할 것이라고 확신합니까?

아니요, 물론 @Input 속성이 명시적으로 정의되지 않았기 때문에 기본적으로 사용할 수 없습니다. 그러나 웹 구성 요소를 사용할 때와 같이 CUSTOM_ELEMENTS_SCHEMA 사용하여 모듈을 정의한 다음 컴파일해야 합니다.

🤦‍♂ 공개된지 5년이 된 이번 호입니다. 반응형 프로그래밍 접근 방식을 용이하게 하기 위해 이것이 필요하다고 생각합니다.

Ivy가 드디어 나왔네요. 누군가 이 작업을 할 시간이 있을 것 같은데요? 제발 제발 제발!

Omg 나는 이것이 매우 필요하다고 구독합니다. 입력 데이터는 반응 소스로 내보내야 하며 ngOnChanges에서 작동하도록 하려면 해결 방법을 사용해야 합니다.

이거 진짜 기대된다

Angular가 오픈 소스라는 것을 알고 있지만 Google에서 실행하는 프로젝트가 5년 이내에 많은 별표 및 요청된 문제를 해결할 수 있어야 한다고 생각하는 것이 잘못되었거나 순진한 것입니까? Google이 Angular에서 작업할 더 많은 개발자를 고용하지 못하도록 방해하는 일부 재정적 문제가 있습니까?

@etay2000 잘 모르겠습니다. rxjs를 사용하여 Angular에서 작업의 75%를 수행한 다음 기본적이고 일반적으로 구성 요소 입력으로 사용되는 것에 대해 갑자기 절차를 수행해야 하는 방법이 좀 웃깁니다. 세계. 관찰 가능 항목의 세계와 작동할 수 없는 이 중요한 프로젝트 부분이 항상 있으므로 항상 상용구를 사용하여 다시 결합해야 합니다. 프로젝트에 대한 완전한 기능적 접근 방식을 절대 달성할 수 없습니다. 4년 동안 공개된 이 문제는 저를 Angular에서 다른 프레임워크로 몰아넣은 실용주의의 부족을 상기시켜줍니다. 왜냐하면 꽤 유용하기 때문입니다. 모든 것에 rxjs를 사용하고 싶다면 cycle.js가 더 나은 솔루션일 수 있고, rxjs를 전혀 사용하지 않으려면 Vue가 될 수 있습니다. Observable을 절반의 시간 동안 사용하고 나머지 절반은 사용할 수 없다는 것은 의미가 없습니다. 매우 강력한 추상화를 높은 학습 곡선과 통합한 다음 완전히 통합하지 못하는 것은 당혹스러울 뿐입니다.

우선순위의 사슬이 이런 식으로 가는 것 같아

내부 Google 사용자의 요구 사항 -> 더 빠른 컴파일러와 관련된 모든 것 -> 더 작은 앱 크기와 관련된 모든 것 -> 신규 사용자를 화나게 하지 않는 모든 것 -> 개발자가 실제로 원하는 것

기술 리더는 이것이 중요하다는 데 동의하지만 사실 Igor와 Misko는 템플릿 컴파일, 뷰 바인딩 및 렌더링 측면에서 대부분의 문제에 대해 생각하는 경향이 있습니다. Angular의 소비자가 중요하다고 말하는 것과 상관없이 솔루션은 항상 템플릿 시스템을 변경하거나 새 렌더러를 작성하거나 컴파일러를 더 좋게 만드는 것입니다.

출처: https://medium.com/@jeffbcross/jeffs-letter-to-the-angular-team-and-community-5367934a16c9)

가장 많이 투표된 문제를 살펴보십시오.

제안: Observable로 입력 #5689

5년 전 작성, 관련 팀원의 마지막 회신 - 5년 전, 현재 상태 불명.

템플릿에서 콜드 이벤트 스트림 지원 #13248

4년 전에 생성된 관련 팀원의 마지막 회신 - 1년 전, 현재 상태 - Ivy가 상륙하기를 기다리고 있습니다.

제안: 구성 요소 수명 주기 후크를 Observable로 제공 #10185

4년 전 작성, 관련 팀원의 마지막 회신 - 3년 전, 현재 상태 불명.

제안: 구성 요소 선언에서 호스트 요소에 지시문을 추가하는 기능이 필요합니다. #8785

4년 전 작성, 관련 팀원의 마지막 회신 - 2년 전, 현재 상태 불명.

as local-val 없이 *ngIf #15280

4년 전 작성, 관련 팀원의 마지막 회신 - 2년 전, 현재 상태 불명.

동적 콘텐츠 프로젝션 지원 #8563

4년 전 작성, 관련 팀원의 마지막 회신 - 3년 전, 현재 상태 불명.

ng-content 기본 콘텐츠 #12530

4년 전에 작성되었으며 관련 팀원의 마지막 회신 - 한 번도, 현재 상태를 알 수 없음.

그런 다음 더 높은 차수의 구성 요소를 허용하는 구성 요소 기능과 같은 것들이 있으며, 물론 더 많은 찬성 투표 문제가 있지만 이러한 문제가 해결되기를 바랐습니다(즉, Ivy 이후 즉시 구현될 것으로 기대하지 않아도 됩니다. ), 프레임워크 및 반응성의 일상적인 사용과 관련이 있기 때문에 아무도 논쟁하지 않을 것이라고 생각합니다. 이것은 대부분의 사람들이 사용하는 것입니다(ngrx가 가장 인기 있는 상태 관리 라이브러리인 경우).

내 앱은 반쯤 구운(단순히 기술적인 제한으로 인해 일부는 코어에서만 제대로 수행할 수 있음) "폴리필"로 가득 차 있고 이러한 문제의 대부분을 해킹하여 언젠가는 앵귤러 네이티브에 빠질 수 있기를 바랍니다. 바꿔 놓음. 하지만 왠지 오지 않을 것 같다.

예, 가장 큰 반응성/개발자 경험 관련 문제의 상태를 다루는 블로그 게시물이 정말 감사할 것이라고 가정해 보겠습니다.

이 기능의 첫 번째 버전을 직접 코딩해 보는 것은 어떻습니까? 저는
covid 때 지루해 죽어, 누가 나와 함께하고 싶어?

예를 들어 여러 사람이 이미 했습니다. https://github.com/insidewhy/observable-input

이들 대부분의 문제는 효율적으로 수행하려면 컴파일러나 angular의 다른 내부 부분을 수정해야 한다는 것입니다.

그건 중요하지 않습니다. 내 말은 각도에 적절한 기여를 하자
핵심. 결국, 우리는 소스 코드를 사용할 수 있습니다. 사실 이 경우에는 컴파일러를 만질 필요조차 없다고 생각합니다.

@ganqqwerty 해당 라이브러리를 작성하기 전에 Angular 내부에서 구현하려고 했습니다. Angular는 매우 복잡합니다. 공정하게 말하자면, 코드는 React와 500줄짜리 미친 기능보다 훨씬 더 읽기 쉽고 이해하기 쉽지만 "정교"합니다. 그리고 그것이 가치가 있다고 생각한다면 나는 여전히 그 구현을 위해 노력을 기울였을 것입니다. 그러나 위에서 @fxck가 반복된 정확한 이유 때문에 가치가 있다고 보지 않습니다. Angular 팀은 커뮤니티의 말을 듣지 않고 일반적으로 Angular의 유용성에 대해 신경 쓰지 않고 최적화와 성능에 지속적으로 집착합니다. 나는 5년 전에 시연된 간단한 문제에 대해 상용구를 구현하도록 강요할 때 잘 수행되는 프레임워크에 대해서는 신경 쓰지 않습니다. 그래서 나는 Angular에 대한 관심을 멈추고, 내가 이미 작업하고 있는 프로젝트를 지원하는 데 필요한 최소한의 노력을 구현하고, 미래의 모든 프로젝트에서 가능하면 언제 어디서나 이를 피하기로 결정했습니다.

이것은 Angular만의 문제가 아니라 Google의 많은 제품에서 발생하는 문제입니다. 이 문제와 @fxck가 위에 나열된 다른 문제는 Google의 고유한 문제에 대한 더 많은 예입니다. Dart 또는 GoLang을 보면 개발자가 일반적으로 직면하는 매우 잘 알려진 문제를 제기하고 문제가 5년 이상 지속되는 것을 볼 수 있습니다.

나는 이것이 추가되어야 한다는 데 동의하지만, 와우, 이 스레드에 대한 증오가 조금 많습니다. 제 말은 우리가 몇 줄의 코드를 절약할 수 있는 무언가를 추가하는 것에 대해 이야기하고 있다는 것입니다. 이제 @Input으로 장식된 setter와 값을 푸시하는 자신의 주제로 관찰 가능한 입력을 가질 수 있습니다.

https://github.com/angular/angular/issues/5689#issuecomment -507001686

너무 많은 상용구라면 이미 간단한 타사 옵션이 있습니다.

https://github.com/Futhark/ngx-observable-input

저는 Angular의 개발에 만족하며 이러한 사소한(바람직한) 기능 때문에 놀랍도록 완전한 기능과 안정적인 프레임워크를 포기하지 않을 것입니다.

일반적인 문제는 주로 사람들이 그것을 보는 관점에서입니다. 누군가에게는 몇 줄의 코드로 무엇이든 변경/추가하는 것이 매우 간단해 보이지만 실제로는 더 큰 범위와 많은 부작용이 있습니다. 그들 모두는 고려되어야 하고 항상 그렇듯이 주제의 라인은 길고 모든 것은 약간의 비용, 부가가치 및 우선 순위가 있습니다.

개인적으로 이러한 모든 문제가 즉시 해결될 것으로 기대하지는 않는다는 점을 지적하고 싶습니다.

그러나 이제 Ivy가 방해가 되지 않고 잠시 동안 야외 활동을 하지 않았기를 바랍니다. 예를 들어 상위 25개 찬성 문제에 대한 일종의 공식 업데이트가 게시되기를 바랍니다.

내 말은, 이 규모의 프로젝트가 프로젝트 관리에서 최우선 순위와 상위 25개(또는 무엇이든) 투표된 모든 문제에 대한 일종의 계획을 고려하지 않을 수 있다는 것을 찾지 못했습니다. 이들 중 대부분에는 effort 태그도 있습니다. 블로그 게시물을 작성하고 커뮤니티에 귀하가 이에 대해 알고 있으며 이에 대한 일종의 계획이 있음을 알리십시오.

나는 확실히 Angular를 포기하지 않을 것입니다. 모든 단점 때문에 여전히 다른 모든 대안보다 훨씬 더 좋아합니다. 그러나 "커뮤니티 관계 관리"(특히 github에서)가 부족하다고 말하는 것이 타당하다고 생각합니다.

// 편집하다

좋은 사람들이 이 설문조사를 작성해 주시겠습니까? 현재 상황과 고려한 모든 사항을 고려할 때 이러한 문제 중 가장 큰 영향을 미치는 것은 / 개발자 경험을 가장 향상시킬 것입니다 https://forms.gle/cprhx239kuqwWd5M8

@fxck 작성

나는 확실히 Angular를 포기하지 않을 것입니다. 모든 단점 때문에 여전히 다른 모든 대안보다 훨씬 더 좋아합니다. 그러나 "커뮤니티 관계 관리"(특히 github에서)가 부족하다고 말하는 것이 타당하다고 생각합니다.

나는 그 문장이 내 생각을 완벽하게 요약한다고 생각합니다.

@chriszrc 저는 이 스레드의 어떤 것도 '증오'로 해석하지 않았습니다. 사람들이 마침내 한 번에 몇 년 동안 문제를 정기적으로 무시하는 Angular로 좌절감을 표출하는 것과 같습니다. 특히 이 문제에 관한 것이 아니라 어떤 형태의 커뮤니티 상호 작용을 유지하는 원칙에 관한 것입니다. Angular 팀이 모든 사람에게 가장 좋은 것이 무엇인지 알고 있기 때문에 개발자 요청을 무시할 수 있다고 생각할 정도로 다른 누구보다 훨씬 뛰어난 것으로 간주됩니까?

@chriszrc 이 스레드에는 증오가 전혀 없고 이해할 수 있는 좌절만 @fxck 가 위에서 제기한 대중적인 문제의 중요한 모음이 무시되었습니다.

안녕하세요 여러분, 이 스레드의 침묵에 대해 실례합니다. 한동안 우리가 받아온 두 가지 직교 요청이 있습니다.

1. 프레임워크에서 더 나은 일급 RxJS 지원
2. Angular의 RxJS가 적어 잠재적으로 선택 사항이 됩니다.

두 요청 모두 우리의 레이더에 있으며 둘 다 장단점이 있습니다. 예를 들어 첫 번째 방향으로 가면 표현력이 풍부하고 의미가 풍부한 RxJS API를 처음 접하는 엔지니어가 프레임워크에 접근하기 어렵게 만들 것입니다. 많은 사람들이 Angular 앱의 모든 곳에서 RxJS를 사용하는 것에 대해 우려하고 있어 경험 수준이 다른 팀원들이 소스 코드를 읽기 어렵게 만듭니다.

동시에 우리는 이미 많은 반응형 API를 가지고 있지만 Angular에서 제공하는 일부 기본 요소는 완전히 필수적이며 모든 것이 잘 연결되지 않습니다. 즉, 반응성 지원을 개선하는 것이 이치에 맞지만 이것이 Angular 핵심의 일부이거나 우리가 긴밀하게 협력하는 커뮤니티 프로젝트(예: ngrx - Angular의 반응 확장)에 위임되어야 합니까?

이 문제를 해결할 수 있는 방법은 여러 가지가 있지만 다음을 고려해야 합니다.

• 이전 버전과의 호환성 - 소스 코드뿐만 아니라 교육 리소스
• 학습 곡선
• 현재 API와의 일관성
• 프로젝트 간 일관성
• 성능 - 런타임 및 초기 로드 시간 모두

우리는 가장 많이 요청되고 우리가 해결할 수 있는 영향력 있는 개선 사항을 살펴보고 몇 가지 주요 GitHub 문제의 우선 순위를 지정하는 과정에 있습니다. 나는 이것이 더 도전적인 것 중 하나라고 말하고 싶습니다. 그래서 날짜를 약속하기가 어렵습니다.

@mgechev 응답

rxjs와 반응형 API가 다른 확장 프로그램으로 분할되는 경우(내 개인 투표가 아님)

나는 그것이 일어날 것이라고 말하는 것이 아닙니다. 내 의견에서 나는 프로젝트의 범위와 우리가 가진 다양한 고려 사항을 보여줄 수 있도록 불완전한 대안 목록을 공유하고 있습니다.

@mgechev 정말 답변 감사합니다.

그러나 Angular의 리액티브 부분이 커뮤니티 프로젝트로 어떻게든 "강등"된다면 리액티브가 Angular의 2급 시민이 된다는 뜻이 아닐까요?

@mgechev 당신의 고통이 한 번에 두 방향으로 찢어지는 것을 느낍니다. 우리 팀은 실제로 명령형/반응형 조각을 나누는 것에 반대하지 않습니다.

이러한 분할에 대한 요구 사항은 다음과 같습니다.

• 명령적 요구와 반응적 요구를 모두 사용하여 고유한 느낌을 주고 어느 쪽도 고정된 느낌을 주어서는 안 됩니다.
• 반응을 가능하게 하는 특정 상태 관리 솔루션과 연결되지 않음(현재 akita를 사용하도록 50개 이상의 프로젝트를 모두 마이그레이션했습니다
• 두 옵션을 동시에 단일 버전으로 출시해야 합니다(지연/지연 없음).
• "즐겨찾기"란 있을 수 없습니다. Angular가 수행하는 모든 작업은 기본적으로 느끼면서 양쪽 세계에서 모두 작동해야 합니다.
• Angular 팀이 뒷받침하는 두 가지 접근 방식 모두에 대한 완전한 공식 지원(우리의 경험에 따르면 이것은 고객의 하드 스톱 고객 요구 사항임)

위의 내용을 기반으로:

• 2가지 주요 옵션이 있습니다.
  
  
  
  • 핵심 명령형 + 애드온 반응형
  
  
  • 핵심 반응 + 애드온 명령
  
  
• 필수처럼 보이도록 리액티브를 래핑하는 것은 매우 간단합니다. 반대의 경우는 그렇지 않습니다.
• 따라서 우리는 핵심에서 반응형을 사용하고 애드온에 명령형 API를 포함하도록 투표할 것입니다.
• 지연이 없고 즐겨찾기 요구 사항이 없고 공식 지원이 필요하기 때문에 애드온이 어떻게 커뮤니티 프로젝트가 될 수 있는지 모르겠습니다.

나는 위의 내용이 우리의 세계관이며 다른 사람들도 많다는 것을 이해합니다. 이 글을 쓰는 이유는 다음과 같습니다.

• Reactive를 커뮤니티 프로젝트로 추출하는 경우 우리는 50개 이상의 솔루션을 다른 프레임워크로 마이그레이션해야 합니다.
• 따라서 다른 프레임워크에서 개발자를 재교육하고 해당 프로젝트를 마이그레이션할 시간을 가질 수 있도록 최대한 빨리 (커뮤니티)에 이 프로젝트의 위치를 ​​알려달라고 요청합니다.

기능을 추가해주세요

@mgechev 나는 당신의 걱정을 이해하지 못합니다. 이 제안은 두 세계를 초보자 개발자 인터페이스로 통일되고 직관적으로 결합하는 것에 관한 것입니다. 둘 중 하나를 선택하는 것이 아니라 조합을 가능하게 하는 것입니다. 예를 들어 개발자 x는 멋진 반응형 구성 요소를 빌드하기로 결정합니다. 그리고 개발자 y는 그다지 반응적이지 않은 프로젝트에서 그것을 사용하기로 결정했습니다. 왜 안 돼? 왜 그는 ngrx 접착제에 의존해야 합니까?
두 세계의 차이점은 궁극적인 스마트 구성 요소와 중앙 상태 저장소에 상태를 저장/관리하는지 여부이며 이것이 ngrx가 있어야 하는 부분이지만 구성 요소의 경우 프레임워크 자체가 인에이블러여야 한다고 생각합니다.

한동안 우리가 받아온 두 가지 직교 요청이 있습니다.

1. 프레임워크에서 더 나은 일급 RxJS 지원
2. Angular의 RxJS가 적어 잠재적으로 선택 사항이 됩니다.

어느 쪽이든 괜찮지만 때때로 이것은 배터리가 포함된 프레임워크를 제외하고는 마지막 작업인 Angular에 분리된 느낌을 주기도 합니다.

개인적으로 모든 Angular 패키지(HTTP, Router, Forms)에 대해 비 RxJS 버전을 사용하는 방법이 궁금합니다. 나는 이것들의 좋은 비 RxJS 버전이 없다고 생각합니다. 이것이 그들이 처음에 RxJS를 가지고 있는 이유입니다.

즉....내가 뭔가를 놓치고 있지 않는 한, (2)는 실현 가능하지 않습니다.

추신 저는 이러한 요청을 "직교"라고 설명하지 않습니다. "반대"에 더 가깝습니다.

Angular의 RxJS가 적어 잠재적으로 선택 사항이 됩니다.

@mgechev에 대한 호기심으로 Github 문제가 있습니까? (나는 본 적이 없습니다.) 아니면 이것은 더 Google 직원의 것입니까?

@pauldraper github에서 누군가가 rxjs가 얼마나 끔찍하게 복잡한지에 대해 불평하고 완전히 선택 사항이 되기를 원하는 문제를 적어도 하나는 보았습니다. 개인적으로 나는 rxjs를 좋아하지만 두 팀과 함께 일하면서 주니어와 시니어 개발자 모두에게 두려움과 혐오감을 불러일으켰습니다. 또한 직교는 반대보다 더 나은 용어입니다. 두 요청을 동시에 구현할 수 있기 때문입니다(각 솔루션은 반응적이고 명령적으로 소비하는 여러 API 옵션을 제공하여 다른 솔루션을 방해하지 않고 작동할 수 있음).

github의 rxjs에 대해 불평하는 모든 댓글에는 수천 명의 개발자가 문제 없이 사용하고 즐기고 있을 것입니다.

다음 은 Angular discord에서 토론하면서 위에 게시한 양식의 결과입니다(거의 200명이 응답했습니다).

당연히 형태가 가장 큰 골칫거리 지만 분명히 @MikeRyanDev 가 마침내 무언가를 요리하고 있을지도 모릅니다 .

github의 rxjs에 대해 불평하는 모든 댓글에는 수천 명의 개발자가 문제 없이 사용하고 즐기고 있을 것입니다.

나는 rxjs를 사랑하지만 그렇게 낙관적이지는 않습니다. 나는 가파른 학습 곡선으로 무언가를 배우기 위해 시간을 할애해야 한다는 생각이 악몽처럼 너무 지쳐버린 많은 개발자들과 함께 일했습니다. 그리고 코딩보다 돈 버는 데 훨씬 더 신경을 쓰는 사람들이 많습니다. D 또는 하루 만에 배울 수 없는 것은 쓰레기라고 생각하는 공격적인 주니어 개발자입니다.

나는 가파른 학습 곡선으로 무언가를 배우기 위해 시간을 할애해야 한다는 생각이 악몽처럼 너무 지쳐버린 많은 개발자들과 함께 일했습니다. 그리고 코딩보다 돈 버는 것에 훨씬 더 신경을 쓰는 많은 사람들이

그것들은 개발자 Angular가 그 당시에 소진되어 배우고 싶지도 않고 충족시키려고 하는 것입니까? :) 그리고 누가 어쨌든 이 시점에서 관심을 갖습니다. Angular는 한동안 사용되어 왔으며 아무데도 가지 않으며 관찰 가능한 수명 주기, 관찰 가능한 입력, 관찰 가능한 이벤트를 추가하면 견인력을 절대 잃지 않을 것입니다. 이 세 가지 작은 것을 추가하기만 하면 사람들은 잠시 동안 만족할 것입니다. 그게 다입니다(그리고 기본 패키지를 완성하려면 https://indepth.dev/component-features-with-angular-ivy/를 따라가십시오).

이것이 모든 것을 말해줍니다. IMHO Angular는 일관성을 유지하고 더 많은 RxJS를 사용해야

Angular가 그 때 해결하려고 하는 것이 바로 개발자입니까? :)

예, rxjs를 사용하여 코드를 작성하려는 개발자에게만 제공하는 것은 허세입니다. rxjs를 사용하는 것을 선호하지만 Angular가 두 개발자 모두를 만족시키기를 바랍니다. Angular가 다른 생각을 하는 사람들이 아닌 우리에게만 제공되어야 하는 이유는 무엇입니까? 특히 우리가 다수가 아니라 소수에 속한다고 믿을 때.

다시 말하지만, 관찰 가능한 수명 주기, 입력, 이벤트를 추가할 때와 같이 "완전히 반응적"으로 진행하는 것은 당신이 말하는 것에 어떤 식으로든 영향을 미치지 않지만 다른 그룹을 매우 행복하게 만들 것입니다.

그리고 컴포넌트 기능은 반응형 프로그래밍을 좋아하든 좋아하지 않든 유용합니다.

@fxck 나는 그것에 대해 한 순간도 동의하지 않았습니다. 나는 rxjs를 사용하기를 원하지 않는 많은 사람들이 있고 그것에 대해 불평하기 위해 github 문제를 열었습니다.

Angular가 코어를 개발하기로 결정한 방법(반응적이든 아니든)에도 불구하고 이상적인 세계에서는 반대 요구를 충족하기 위해 위에 빌드된 반대 패키지가 있습니다(예: @angular/reactive 또는 @angular/imperative - 더 나은 이름으로). 잘하면).

커뮤니티에 가는 이 두 가지 중 하나는 저에게 어떤 사람들에게는 다운그레이드이며 저에게는 훌륭한 반응 프레임워크가 될 것이라는 각도가 처음부터 함께 가야 하는 이유였습니다.

참고로 저는 앵귤러 리액티브를 유지하고 명령형 확장을 사용하는 것이 더 쉬울 것이라고 생각합니다. 코어와 확장 패키지의 단순성을 위해 필수 요소를 반응형으로 연결하는 것보다 브리지하기가 더 쉽기 때문입니다.

면책 조항: 가정을 기반으로 공식화한 마지막 요점 - 핵심 명령을 작성하는 것이 훨씬 더 쉽다면 놀라지 않을 것입니다. - 확장 반응은 더 복잡할 것입니다.

@mgechev에 대한 호기심으로 Github 문제가 있습니까? (나는 본 적이 없습니다.) 아니면 이것은 더 Google 직원의 것입니까?

내부 Google 제품이 아닙니다. 당신은 (내가 팀에 합류했을 때와 마찬가지로) 외부 요구 사항과 내부 요구 사항 사이의 교차점이 얼마나 큰지에 놀랄 것입니다. 주요 차이점은 Google 직원이 Google 직원이 아닌 사람과 요구 사항이 거의 동일하다는 점을 제외하고 빌드 시스템 및 종속성 관리에 있습니다.

우리는 수많은 외부 회사, 내부 팀, 개인 기여자 등 수천 명의 개발자와 연락하고 있습니다. 두 경우 모두 RxJS에 완전히 참여하고 싶어하는 사람들과 그것이 그들에게 올바른 선택이 아니라고 생각하는 사람들이 있습니다. 두 진영 모두 훌륭한 논거를 가지고 있습니다.

이것은 우리가 서두르고 싶은 결정이 아닙니다. 특히 잘 정립된 해결 방법/커뮤니티 솔루션이 있는 경우 커뮤니티에서 수행된 작업은 추가 데이터 포인트를 수집하고 현재 변수 세트에 대한 최적의 솔루션을 설정하는 데 도움이 됩니다.

Angular 앱을 개발할 때 하나의 통합된 접근 방식을 반응형 또는 필수(프로젝트당 선택)로 사용하는 것이 매우 유용할 것이라고 생각합니다. 혼합 및 일치 기능은 개발 경험을 지원하지 않으며 비 DRY 코드(예: 비반응적 입력)를 생성합니다.

단독으로는 아무 일도 일어나지 않기 때문에 많은 개발자를 리액티브 프로그래밍으로 재교육하는 데 어려움을 겪는 기업 환경을 충분히 이해할 수 있습니다. 따라서 명령형을 삭제하는 것은 기업의 최적의 위치에서 각도를 벗어나게 되며, 각도와 같은 프레임워크에 대한 대규모 핵심 사용자 기반을 구성하므로 현실적이지 않게 될 것입니다.

즉, 내가 현실적이지 않다고 생각하는 것은 명령형 인터페이스 위에 반응형 인터페이스를 구축하는 것입니다. 다른 방향은 관찰 가능 항목의 출력을 항상 변수에 쓸 수 있으므로 매우 간단합니다. 변수는 명령적으로 사용할 수 있습니다. 사실 이것이 Angular가 이미 많은 곳에서 하고 있는 일입니다.

따라서 나는 Angular를 핵심에서 완전히 반응하도록 만든 다음 맨 위에 명령형 "래퍼"를 만드는 데 투표합니다.

이 접근 방식의 주요 문제는 명령형 사용자의 경우 더 큰 마이그레이션 단계일 가능성이 매우 높습니다. 이는 Angular 팀이 방지하려고 하는 것과 정확히 일치할 수 있는 기업 환경에서 불가능하므로 핵심에서 해야 할 일을 제안해야 합니다.

@mgechev 이것은 몇 번이나 제기되었으므로 반응성 코어/명령형 확장에 대한 귀하의 생각과 설 수 있는 다리가 있는지 듣는 것이 흥미로울 것입니다.

두 경우 모두 RxJS에 완전히 참여하고 싶어하는 사람들과 그것이 그들에게 올바른 선택이 아니라고 생각하는 사람들이 있습니다. 두 진영 모두 훌륭한 논거를 가지고 있습니다.

좋습니다. RxJS로 본격적인 작업을 정의하시겠습니까? 관찰 가능한 수명 주기, 관찰 가능한 입력 및 관찰 가능한 이벤트를 추가하는 방법은 무엇입니까? 그리고 아니요, 이들 중 어느 것도 실제로 "잘 확립된 해결 방법/커뮤니티 솔루션"이 없습니다.

@fxck 이들 중 어느 것도 실제로 "잘 확립된 해결 방법/커뮤니티 솔루션"이 없습니다.

사실입니다. 나는 이러한 솔루션 중 하나를 작성했으며 템플릿의 잘못된 유형 검사에 의존하는 하나의 큰 해킹으로 인해서만 작동합니다. 이 스레드에 게시된 몇 가지 다른 솔루션도 확인했으며 각각에는 다음 문제 중 하나 이상이 있습니다.

• 구독 누출
• 사용자에 대한 상용구 요구 사항
• 내 라이브러리에서 사용한 것보다 나쁘지는 않지만 나쁘지 않은 해킹입니다.

내가 생각하는 한, 이것을 멋지게 하는 것은 불가능합니다.

관찰 가능한 이벤트는 훨씬 더 나쁩니다. 커뮤니티 솔루션이 많지 않으며 일반적으로 추가 빌드 단계(일부 경우 monorepo 설정에서 SSR 중단)와 그 위에 해킹이 필요합니다(예를 들어 클래스 확장을 사용하는 경우). Angular는 기본적으로 이를 지원하지 않기 때문에 수명 주기 관찰 가능한 이벤트를 가져옵니다. https://github.com/typebytes/ngx-template-streams/issues/8

수명 주기 이벤트는 틀림없이 "가장 쉬운" 것이지만 여전히 클래스 확장 또는 사용자 지정 데코레이터에 의존해야 하며 어느 것도 이상적이지 않습니다.

@fxck 내가 아는 한 부모 클래스(eug) 또는 사용자가 자체 파괴 수명 주기 이벤트(더 나쁜 경우)에서 호출해야 하는 메서드를 사용하지 않고 수명 주기 이벤트 구독을 정리할 수 없습니다.

수명 주기 이벤트는 틀림없이 "가장 쉬운" 것이지만 여전히 클래스 확장 또는 사용자 지정 데코레이터에 의존해야 하며 어느 것도 이상적이지 않습니다.

사용자 지정 데코레이터를 사용하여 수명 주기 이벤트(반응형으로 만들기 위해)도 구현하려고 시도했지만 고통스럽습니다. ~클래스 확장 없이 100번 해킹 없이 가능한지 모르겠네요~. 각도를 확장하는 사용자 가능성은 지금까지 매우 열악하며 이를 수행하기 위해 해킹이나 많은 상용구에 의존합니다.

@tonivj5 구성 요소 기능 이 공개 API인 경우 상속 없이 수명 주기를 구현하는 잠재적인 방법이라고 보십니까 ?

@ntziolis 하하 기능을 언급해야 하는 것이 재미있습니다. 저는 실제로 ngx-sub-form의 수명 주기 부분에서 작업하고 있으며 기능은 정확히 제가 도움이 될 것이라고 생각하는 것입니다. 그 동안 아이비로 구성 요소 공장을 패치하는 것은 매우 가능합니다. 나는 이것이 ngx-sub-form 외부에서 매우 유용하다고 생각하므로 이 논리를 별도의 lib로 분할할 것이라고 생각합니다.

@ntziolis 이 시점에서 Ivy 약속이 실제로 전달되는 것을 볼 수 있을지 확신할 수 없습니다.

각진 효과를 확인 했습니까? (ngrx/effects 아님) https://dev.to/stupidawesome/reactive-adventures-in-angular-introducing-angular-effects-1epf 이 도구를 사용하면 완전히 반응하는 애플리케이션을 작성할 수 있습니다.
부모 및 자식 구성 요소 간의 양방향 관찰 가능 상태 포함
https://dev.to/stupidawesome/exploring-the-angular-effects-api-2gol
버전 9.1.0은 Vue 3의 구성 API를 기반으로 하는 구성/후크 모델을 도입합니다.
Angular가 반응성과 함께 작동하는 것은 정말 다음 단계라고 생각합니다.

@mgechev

이것은 특히 잘 확립된 해결 방법/커뮤니티 솔루션이 있다는 점을 고려할 때 서두르고 싶은 결정이 아닙니다.

궁금합니다. 우리는 누구이며 얼마나 많은 Google 직원이 Angular 의사 결정 과정에 적극적으로 기여하고 있습니까?

당신은 이것이 서두르지 말아야 할 결정이 아니라고 말했지만, 서두르지 않는다는 당신의 정의가 무엇인지 궁금합니다. 이것은 'Fixed by Ivy' 태그를 때리고 더 많은 개발자가 상황을 다시 시끄럽게 만들기 시작할 때까지 무시하는 것 중 하나입니까? 반응 작업에 대해 염두에 둔 대상 버전이 있습니까? 아니면 먼저 릴리스해야 하는 다른 최신 컴파일러 버전이 있습니까?

주어진 시간에 일반적으로 2500개의 미해결 문제가 있다는 사실이 내부 토론에서 나온 적이 있습니까?

@ntziolis , @zakhenry가 말했듯이 features 가 도움이 될 것이라고 생각합니다.

@ntziolis 나는 수명 주기에 대해 다른 시도를 했고 작동하는 POC가 있습니다 (클래스 확장이 없고 수명 주기 인터페이스를 구현하지 않음). 프라이빗 API에 의존합니다(:exclamation:)

@tonivj5 하하 당신의 글을 읽을 기회가 없었지만 제 솔루션도 거의 출시될 뻔했습니다 :) https://github.com/cloudnc/ngx-observable-lifecycle

내가 작업하고 있는 라이브러리의 아이디어는 다른 라이브러리가 자체 수명 주기 인식 기능을 만들기 위해 연결할 수 있는 공통 기반을 갖는 것입니다. 동일한 후크에 액세스하려는 여러 함수가 있는 경우 구성 요소 def에 장식된 하나의 후크만 있도록 작동할 수 있어야 합니다.

CI와 단위 테스트를 정렬하기만 하면 됩니다.

주어진 시간에 일반적으로 2500개의 미해결 문제가 있다는 사실이 내부 토론에서 나온 적이 있습니까?

Lol, 2019년 중반 이후로 2500개의 공개 문제가 없었습니다.

$ github_issue_stats history -i2m -n20 -sangular/angular

+-------------------------+--------------------+
|         period          |       issues       |
+-------------------------+--------------------+
| This month (2020-05)    | 2855 (+137, -112)  |
| Last month (2020-03)    | 2830 (+495, -550)  |
| 2 months ago (2020-01)  | 2885 (+601, -575)  |
| 3 months ago (2019-11)  | 2859 (+437, -352)  |
| 4 months ago (2019-09)  | 2774 (+411, -305)  |
| 5 months ago (2019-07)  | 2668 (+441, -369)  |
| 6 months ago (2019-05)  | 2596 (+488, -349)  |
| 7 months ago (2019-03)  | 2457 (+425, -373)  |
| 8 months ago (2019-01)  | 2405 (+428, -330)  |
| 9 months ago (2018-11)  | 2307 (+425, -391)  |
| 10 months ago (2018-09) | 2273 (+515, -466)  |
| 11 months ago (2018-07) | 2224 (+641, -541)  |
| 12 months ago (2018-05) | 2124 (+690, -624)  |
| 13 months ago (2018-03) | 2058 (+605, -444)  |
| 14 months ago (2018-01) | 1897 (+773, -679)  |
| 15 months ago (2017-11) | 1803 (+815, -979)  |
| 16 months ago (2017-09) | 1967 (+671, -431)  |
| 17 months ago (2017-07) | 1727 (+664, -518)  |
| 18 months ago (2017-05) | 1581 (+854, -548)  |
| 19 months ago (2017-03) | 1275 (+987, -796)  |
| 20 months ago (2017-01) | 1084 (+671, -505)  |
+-------------------------+--------------------+

내 취향에 따라 토론 없이 열린 각 문제를 닫는 프로젝트보다 명확한 커뮤니티 토론/합의가 있을 때까지 문제를 토론에 공개하는 오픈 소스 프로젝트를 선호합니다. 또한 유지 관리자가 제안 수락 가능성을 차단하기 전에 커뮤니티에 시간이 지남에 따라 우려 사항을 설명하는 단계이기도 합니다.

@agalazis 이 문제는 4 1/2년 동안 공개되었으며 지난 3년 동안 거의 무시되었습니다.

@agalazis 이 문제는 4 1/2년 동안 공개되었으며 지난 3년 동안 거의 무시되었습니다.

Angular 팀 구성원이 왜 이것이 아직 5일 전에 열려 있는지 설명하므로 당신이 옳지 않습니다.

@etay2000 어떤 결정은 전체 프로젝트의 발전에 영향을 미치기 때문에 때때로 어려울 수 있습니다. 그것은 수용 가능합니다. 개발자는 시간이 지남에 따라 가까운 장래에 기능에 의존할 수 없다는 것을 깨달을 수 있지만 가능성이 있다면 왜 조기에 종료합니까? 가장 쉬운 방법은 제안을 거부하고 문제를 종료하는 것이지만 이유가 있어서 발생하지 않았다고 생각합니다.

@beeman

Angular 팀 구성원이 왜 이것이 아직 5일 전에 열려 있는지 설명하므로 당신이 옳지 않습니다.

엄지손가락을 아래로 내리는 이모티콘이 정말 마음에 드시나요? 그런데 그게 정말 설명이 되었나요? 4년이 지난 후 그는 결정을 서두르고 싶지 않다고 말했습니다.

@agalazis
일부 결정이 어렵다는 점에는 동의하지만 어려운 결정을 내리는 것을 연기할 수 있는 허용 가능한 시간 프레임으로 간주되어야 하는 것은 무엇입니까? 2855개의 모든 미해결 문제가 이러한 어려운 결정을 포함하는 것은 아니지만 많은 문제도 꽤 오랫동안 존재해 왔습니다.

@etay2000 수락 여부는 오픈 소스입니다. 문제를 여는 사람들은 유지 관리자보다 훨씬 많습니다. 예를 들어 Typescript 프로젝트에는 거의 두 배나 많은 문제가 있으며 내가 거기에서 한 다른 제안도 오랜 시간이 걸렸습니다. 토론에서 기능이 있는 것만큼 화려하지는 않지만 다른 많은 관점을 볼 수 있었던 많은 대안이 나왔기 때문에 신경 쓰지 않습니다.

@agalazis 네 말이 맞아. 내가 (잘못된) 작은 프로젝트에서보다 Google에서 유지 관리하는 오픈 소스 프로젝트에서 더 많은 것을 기대했던 것 같다.

@beeman 엄지손가락 아래 이모티콘을 여기에 삽입하십시오: -------->

@etay2000 중요한 결정 하나하나가 수십만 가지, 프로젝트, 사람에게 영향을 미친다는 사실을 항상 기억해야 합니다. 그리고 더 중요한 것은 완벽하지 않은 결정과 공개 API를 도입한 후 짧은 시간에 일부 획기적인 변경으로 이어질 악몽입니다. 각 PR에서 각 단계가 어떻게 검토되는지 거의 볼 수 있으며, 완벽하지 않은 경우 몇 주, 몇 달 또는 몇 년을 기다립니다.

@agalazis 네 말이 맞아. 내가 (잘못된) 작은 프로젝트에서보다 Google에서 유지 관리하는 오픈 소스 프로젝트에서 더 많은 것을 기대했던 것 같다.

모르겠어 바둑도 다트도 봐. Google은 실제로 50년 동안 엄청나게 인기 있는 커뮤니티 요청을 무시하는 것으로 꽤 유명합니다. D 일반적으로 언어/프레임워크 등에 대한 접근 방식입니다. 매우 보수적 입니다. 영역에 혁명을 일으키고 Google에서 몇 년 동안 이를 채택하지 않고 있는 새로운 언어와 아이디어가 등장하는 것을 볼 수 있습니다. 예를 들어 Dart보다 오래 전에 null 안전 히트 Kotlin, TypeScript 및 Scala가 있습니다. 이런 종류의 접근 방식에는 장점과 단점이 있다고 생각하지만 적어도 저에게는 Google에서 개발한 것이 제 정신에 맞지 않기 때문에 가능한 한 피하는 경향이 있습니다.

(여러분 죄송합니다만 저는 해야 합니다.)

@beeman 엄지손가락 아래 이모티콘을 여기에 삽입하십시오: -------->

@etay2000 이런 종류의 댓글이 여기의 행위 위반이 아니라면 어떻게 도움이 되는지 모르겠습니다. 나는 모두가 어떻게 엄지손가락을 치켜드는지 알고 있다고 확신합니다. 그래서 풍자의 요점은 무엇입니까?

다시 말하지만, 아무도 Angular를 사용하도록 강요되지 않습니다. 사람들이 당신을 더 기쁘게 하는 다른 프레임워크를 찾으려고 노력할 수 있습니다.

@brunojcm 댓글 경찰이 끝난 것 같아요. 요점은 그가 내 다른 모든 의견을 무시했다는 것입니다. 그러나 나는 풍자가 행동을 위반하는 것임을 깨닫지 못했습니다.

다시 말하지만, 아무도 Angular를 사용하도록 강요되지 않습니다. 사람들이 당신을 더 기쁘게 하는 다른 프레임워크를 찾으려고 노력할 수 있습니다.

내가 정말로 그것에 대응하고 싶은 방식은 분명히 여기에 있는 행동 강령을 위반하는 것입니다.

끝났습니다. 모두가 정기적으로 예정된 프로그램으로 돌아갈 수 있습니다. 4~5년 후에 상황이 어떻게 되었는지 다시 확인하겠습니다.

@tonivj5 @zakhenry 이것이 길이 될 수 있다는 소식을 들으니 반갑 습니다 .

@mgchev 나는 이것이 예비 토론이

• 반응 코어 + 비 반응 확장 대 반대.
• 이 문제에 대해 더 구체적으로 말하면 어떤 방식으로든 기능 API를 노출할 현실적인 기회가 있다는 것입니다.
  
  
  
  • 일반 기능에 여전히 액세스할 수 있는 한 향후 변경 사항을 중단한다는 경고가 있는 경우에도 마찬가지입니다.
  
  
  • @zakhenry 가 수명 주기 이벤트에 대해 수행한 것처럼 이 API에 직접 액세스하는 대신 다른 사람이 사용할 수 있는 API를 구축하는 프로젝트가 하나 또는 매우 제한적입니다.
  
  
  • 그런 다음 이러한 래퍼 팀과 협력하여 초기에 예정된 주요 변경 사항에 대해 알릴 수 있습니다(반응 확장에 대한 제안과 매우 유사함).
  
  

Vue 3.0의 리액티브 모듈(ref 또는 react)을 직접 적용해 이 문제를 해결할 수 있다고 생각합니다.

@AnonymousArthur @vue/reactivity 패키지에 대해 이야기하는 경우 속성에 반응성을 제공하고 상대 스트림(RxJ가 무엇인지)과 아무 관련이 없기 때문에 여기에서 논의하는 것과 완전히 관련이 없습니다.

@gund 예, 동의합니다. 그러나 이 대화는 꽤 오랜 시간(4.5년)이 걸리고 아직 끝나지 않았기 때문에 subscribe/unsubscribe 또는 ngOnChange Handler를 작성하고 싶지 않은 사람들을 위해 매우 빠르게 아이디어를 팝니다(그렇지 않을 수도 있음). RxJS는 반응성 기능을 제공하며 이 대화(모두 읽지는 않음)는 입력 값을 Observable로 래핑하여 관찰 가능하게 만드는 구문 설탕으로 말하는 것에 대해 이야기하고 있으며 이것이 멋진 아이디어라고 생각합니다.

나는 이 아이디어가 정말 유용하고 처음에 @robwormald 의 프로토타입이 멋지게 보이지만 잠재적인 이점과 영향이 얼마나 작아야 하는지를 과소평가했다고 생각합니다.

몇 가지 단점을 수정하기 위해 해당 솔루션에 약간의 조정을 제안하겠습니다. 그러나 기본적으로는 동일한 접근 방식입니다.

정의 할 각도 데코레이터 @OInput() 및 유형 EventReceiver<T> 연장 Observable<T> 또한 추가하는 .value 게터 (같은 BehaviorSubject<T> ).

@robwormald 의 예에서와 같이 상위 구성 요소 측에서는 아무 것도 변경되지 않습니다. 거기에 Observable 값을 전달하려면 여전히 | async 합니다. 또는 관찰할 수 없는 유형으로 전달할 수도 있습니다. (항상 그렇듯이) 괜찮습니다.

하위 구성 요소 측 에서 제안한 내용은 다음과 같습니다(해당 제안에서 약간 벗어남).

@Component({ selector: "child" })
class Child {
  // Notice, this parallels the patterns of `@Output()`.
  @OInput() foo = new EventReceiver<MyType>();

  constructor() {
    // The reactive way to listen to input changes in the class.
    this.foo.subscribe((v) => {
      console.log('foo changed', v);
    });
    // Or you can bind to `foo | async` in the template.
  }

  // But this would also support less reactive patterns in parallel,
  // both for ease of migration and for cases where developers don't
  // want to migrate fully. 
  ngOnChanges(changes: SimpleChanges) {
    if (changes['foo']) {
      console.log('foo changed', changes['foo'].currentValue); // Unchanged
      console.log('foo changed', this.foo.value);  // Previously this would have been just `this.foo`
    }
  }
}

이제 이 접근 방식의 이점은 다음과 같습니다.

• 이는 원하는 경우 상위 및 하위 구성요소 모두에서 효과적으로 완전히 반응하는 설계를 가능하게 합니다.
• 상위 구성 요소에서 Angular의 기존 입력 디자인 패턴을 유지하므로 구성 요소가 강제로 적용되거나 주변에서 디자인할 필요가 없습니다.
• 부모와 자식 컨텍스트는 완전히 독립적이며 부모는 자식이 Input 또는 OInput 사용하는지 알 필요가 없으므로 이 변경으로 인한 교차 구성 요소 버그의 위험이 제거됩니다.
• Angular는 이전과 같이 기존 수명 주기 이벤트에 모두 연결된 상태로 유지하기 때문에 원하는 경우 단일 하위 구성 요소를 부분적으로 마이그레이션하는 것이 상대적으로 쉽습니다.
• Angular는 이 기능을 구현하기 때문에 모든 EventReceiver 는 내부적으로 takeUntil(ngOnDestroyEvent) 통해 파이프를 포함할 수 있으므로 대부분의 경우 구성 요소가 파괴될 때 구독 취소를 기억할 필요가 없습니다. 이러한 관찰 가능 항목이 자동으로 완료되기 때문입니다. . (예, 메모리 누수 감소!)
• 이 하위 구성 요소에서 이것은 오늘날의 @Output() 패턴과 매우 유사하게 보이고 기능하므로 멋진 병렬 처리와 이들을 멋지게 연결할 수 있는 잠재적 기능을 제공합니다.
  
  
  
  • 참고 사항: 후속 조치로 ReplaySubject<T>(1) 를 사용하여 양방향 바인딩에 대한 동작을 보다 원활하고 일관되게 연결하는 @InputOutput() 를 제안하는 것이 좋습니다. 그러나 그것은 나름의 도전과 논거가 있기 때문에 여기에서 제안 하지 않습니다 .
  
  
• 이 작업을 수행하는 새로운 유형의 상용구는 없으며 @Output() 만큼 간단합니다.
• Angular는 Observable 가 부모에 의해 입력되는 변경 사항에 대해 매끄럽게 switch() 이므로 동일한 Observable 인스턴스를 고수하지 않는 것과 같은 약한 반응 패턴은 특별한 경우가 필요하지 않습니다( switch() ed) 하위 구성 요소.

내가 선택한 OInput 이름에 대한 참고 사항: 분명히 논쟁의 여지가 있습니다. 그러나 "Observable Input"의 약자이고 이것이 미러링되는 "Output"처럼 보이기 때문에 개인적으로 그 이름을 좋아합니다.

친애하는 Angular 팀. 2020년에는 무엇이든 기대해주세요 :-)

또한 @jcomputer 솔루션은 내가 원하는 것입니다. 다른 데코레이터 이름의 열렬한 팬은 아니지만 @ViewChild 가 { read } 갖는 것과 유사한 매개변수를 추가하는 것이 가능합니다. 예:

@Input({ observable: true }) 
@Input({ asObservable: true }) 
@Input({ asSubject: true })

2020년에 기대할 수 있는 것이 너무 많습니다. :D 물론 이(및 위에 나열된 다른 문제)가 새로운 기능이 아닌 버그로 간주되지 않는 한. :)

https://twitter.com/ThomasBurleson/status/1283902827467886592

@fxck 여기에서 인기가 없는 의견이 있을 수 있지만 솔직히 말해서 2020년이 Angular 팀이 양식, 라우터 등에 대한 많은 버그를 수정하기로 결정했다면 저는 0 기능 에 전혀 화를 내지 않을 것입니다: 어깨를 으쓱:.

즉, 최근 사건과 관련된 문제일 수 있으며 현재 Angular 팀에서 복잡한 일이 진행되고 있다고 가정합니다. 나는 그들이 지금까지 Angular를 적극적으로 구축해 온 위대한 사람들인 heart: 를 유지할 수 있기를 바랍니다

주제넘어서 죄송합니다. 날아 가다

@maxime1992 나도 괜찮을거야.

여기에 인기가 없는 의견이 있을 수 있지만 솔직히 말해서 2020년이 Angular 팀이 양식, 라우터 등에 대한 많은 버그를 해결하기로 결정했다면 나는 기능 이

하지만 나를 불안하게 만드는 것은 우리 없이도 우리에게 영향을 미치는 Angular 팀 내부에 장기적으로 건강에 해로운 HR 프로세스가 있다는 사실입니다. 특히 이 지역에 대한 대규모 투자의 관점에서.

내 POV에서 그들은 주로 BOT를 통해 문제를 해결하여 문제를 해결하고 있습니다. 응답 없이 떠나고 봇에 의해 닫힙니다.,.. :-/

@montella1507 아니오, 이것은 사실이 아닙니다. 봇은 이미 닫힌 문제만 잠급니다. 그리고 Angular 팀원들이 새로운 이슈가 나왔을 때 설명하고 재현해야 할 사항을 설명하려고 할 때 많은 경우에 많은 노력을 기울이는 것은 이미 사실입니다. 시간이 많이 걸리는 과정이며 많은 인내가 필요합니다.

Angular 팀을 비난하고 기능과 변경 사항을 빨리 얻지 못하는 것에 대해 불평하는 사람들을 위해:
나는 당신의 고통을 이해합니다. 나는 또한 Angular에서 이 기능을 보고 싶습니다. 개인적으로 좋아하지 않는 많은 것들을 변경하고 싶습니다.

그러나 Angular는 반짝이는 새 장난감이 모두 있고 릴리스마다 수많은 기능을 제공하는 프레임워크가 아닐 수도 있습니다. 그리고 그건 괜찮습니다. 보다 엔터프라이즈급을 목표로 하고 안정성과 신뢰성을 제공하는 프레임워크가 있어야 합니다. 그리고 Angular는 적어도 내 경험에 비추어 볼 때 잘 수행합니다.

나는 Vue를 더 좋아한다. 개인 프로젝트에 사용하고 있습니다. 그러나 내 프로젝트는 빨리 구식으로 느껴지기 시작하고 새로운 구성 요소 스타일로 업그레이드하고 싶은 충동을 느낍니다. 또한 업그레이드를 수행할 때 항상 이상한 방식으로 문제가 해결됩니다. 생태계도 호환성을 유지하기가 더 어려운 것 같습니다.

대조적으로 Angular는 성숙하고 안정적입니다. 자주 변경되지는 않지만 종속성을 업데이트하여 코드를 리팩토링하는 작업이 줄어들고 상용 제품에 유용하다는 의미이기도 합니다. 지식은 또한 더 오랫동안 관련성을 유지하며, 따라가려고 하는 대신 심층적으로 이동할 수 있습니다.

@manfreed 사람들은 반짝이는 새 장난감을 요구하는 것이 아니라 프레임워크 디자인의 간과에 대한 수정을 요구하고 있습니다. 현재 우리는 핵심 기능을 위해 때때로 Observable을 사용해야 하고 때로는 Observable을 사용할 수 없습니다. 관찰 가능한 것을 싫어하는 사람들은 좌절합니다. 관찰 가능한 것을 좋아하는 사람들은 좌절합니다. 그리고 우리 중 많은 사람들이 우리가 포기하고 다른 프레임워크로 넘어간 상황에 너무 실망했습니다. 나는 약간의 방향성인 Angular를 계속 사용하고 싶었고 정말 훌륭한 프레임워크가 될 수 있었습니다. 그러나 잘못된 관리, 실용주의의 부족, 실수에 대한 블로그 게시물은 모두 객관적으로 실망스럽습니다.

@insidewhy 인내심을

로드맵에서 앞서 언급한 특정 문제에 대한 언급은 없었습니다. 저는 슬프게도, 언급, 인정, ...이 논의가 Angular discord에 이어지기를 정말로 바랐습니다.

나는 그들에게 의심의 여지를 주었고 그 중간 로드맵 기사 의 논평에서 물었습니다. Minko의 응답:

그는 몇 달 전에 여기에서 말한 것을 거의 반복했습니다. 이러한 rxjs 관련 문제 중 어느 것도 곧 수정되지 않을 것이므로 그렇습니다.

내 요점을 이해하는 것은 끝났지만 마지막으로 한 번만 더 시도해 보겠습니다. Angular가

• 관찰 가능한 수명 주기
• 관찰 가능한 입력
• 관찰 가능한 템플릿 이벤트

이들 중 어느 것도 이전 버전과의 호환성을 깨뜨리고 학습 곡선을 증가시키지 않으며 다른 API와 일치하지 않으며 성능에 거의 영향을 미치지 않는다고 상상할 수 있습니다 . 그래서 어쨌든 앞에 놓인 다른 작업과 비교하여 어떻게 그렇게 까다롭고 더 길고 신중한 계획이 필요한지 알 수 있습니다. 한 번에 하나씩 추가하여 관심을 갖고 있음을 보여주십시오. 제발.

@fxck :+1: 확실히.

• 관찰 가능한 수명 주기
• 관찰 가능한 입력
• 관찰 가능한 템플릿 이벤트

@insidewy 인내심을 가지고

사람들에게 5년 이상의 인내를 요구하는 것은 많은 경쟁자들이 관심을 받기 위해 경쟁하는 경주에서 과거를 달리고 있을 때 그다지 실용적이지 않습니다.

@ insidewhy 더 일반적으로 의미했습니다.

@fxck Google은 4000개의 앱이 (내 마지막 계산에 의해) 각지고 본질적으로 매우 유사하며 이러한 프로젝트와 동료 검토 사이를 전환하는 것이 (내 생각에) 매우 매끄럽습니다. 우리 회사에서도 Angular의 큰 이점 중 하나는 내가 다른 팀의 코드를 검토하지 않고도 동료 검토가 전체 조사를 시작하지 않는 상태에 있다는 것을 알 수 있다는 것입니다.

이제 이러한 유용한 RxJS 바로 가기를 코어에 구현한다고 가정해 보겠습니다. 그러면 어떻게 될까요? 특정 경우에 어떤 편향이 올바른지에 대한 명확한 지침 없이 절차적 편향 대 반응적 편향으로 끝날 가능성이 있습니다. 지금까지의 토론을 읽은 후 Angular 팀의 대답은 "이것은 낮은 우선 순위입니다"(귀하의 흐름에서 알 수 있듯이)가 아니라 실제로 "우리는 편을 들고 싶지 않습니다"에 더 가까운 것 같습니다.

여기 Angular 커뮤니티의 고급 RxJS 사용자는 소수입니다. Typescript, DI, 템플릿 및 Angular의 다양한 라이브러리를 사용하고 나면 매일 프레임워크를 사용하는 데 거의 1년이 걸리고 이제 준비가 완료되기 때문입니다. RxJS를 완전히 이해하려면 동료 리뷰에서 고위급 사람들이 반응성 편향으로 떠나게 하는 것은 사람들을 훨씬 더 소외시키며, 말 그대로 Angular가 필요로 하는 마지막 것입니다.

Angular의 목표(내가 보기에)는 "X tech를 사용하는 것이 더 좋기 때문에 사용하세요."와 관련된 대화를 줄이고 조정하고, 구현 중인 비즈니스 로직에 대한 동료 리뷰에서 대화를 유지하는 것입니다. 우리가 이미 가지고 있는 것보다 더 "고급" 각도와 "초보자" 각도 사이에서 구성 요소를 계층화하고 싶습니까?

이것은 틀림없이 우리가 상태 관리에서 본 것과 동일한 주장입니다. 왜 Angular가 많은 가능한 패턴 중에서 어느 것이 올바른지 결정해야 합니까?

Angular 팀 구성원 중 한 명을 인용하겠습니다.

그건 그렇고, 이것들(관찰 가능한 수명 주기, 관찰 가능한 입력, 관찰 가능한 템플릿 이벤트)에 대해 전혀 발전된 것이 없습니다.

이것은 틀림없이 우리가 상태 관리에서 본 것과 동일한 주장입니다. 왜 Angular가 많은 가능한 패턴 중에서 어느 것이 올바른지 결정해야 합니까?

상태 관리와 이것의 차이점은 상태 관리는 커뮤니티에서 수행할 수 있으며 이를 방지하는 앵귤러 코어 내부에는 아무것도 없다는 것입니다. 불행히도 Angular는 내가 언급한 세 가지 모두를 적절하게 구현하는 방법을 제공하지 않습니다. (수정: 댓글 링크 수정)

저는 양식, 라우터, 플렉스 레이아웃, 유니버설 등과 같은 패키지를 포함하여 Angular 팀이 코어, cli 및 구성 요소에 집중할 수 있도록 최대한 많은 커뮤니티를 커뮤니티에 남기고 싶습니다. 그러나 이를 위해서는 예를 들어 고차 구성 요소 를 허용하는 것과 같이 커뮤니티에 충분한 진입점을 제공해야 합니다. 그러나 그들은 몇 년 동안 그렇게 하지 못했고(종종 아이비가 먼저 필요하다고 말함) 현재 계획에서 이에 대해 인정/토론하기를 거부합니다.

지금까지의 토론을 읽은 후 Angular 팀의 대답은 "이것은 낮은 우선 순위입니다"(귀하의 흐름에서 알 수 있듯이)가 아니라 실제로 "우리는 편을 들고 싶지 않습니다"에 더 가까운 것 같습니다.

네, 그리고 무섭습니다.

@fxck 나는 우리가 이것에 대해 같은 페이지에 있다고 생각합니다. 포럼이나 동료 엔지니어들과 함께 RxJS를 언급할 때마다 인용할 수 있는 대부분의 인용문은 "아직도 이것을 이해하지 못하는데 어떻게 더 배우나요?"라고 말하고 싶습니다. 또는 "운영자가 얼마나 많은지 압도됩니다." 또는 "이 PR에서 이 파이프라인을 읽는 데 문제가 있습니다." 숙련된 RxJS 엔지니어 1명당 15명의 숙련된 Angular 엔지니어가 눈썹을 찌푸리고 있는 것 같습니다.

네, 그리고 무섭습니다.

이것은 우리가, 조금 과장하지 "필요" @angular/core 이러한 패턴을 가지고, 사실 어떤 프로젝트에 오늘 사용할 수있는이 문제에서 많은 많은 변종과 라이브러리가 있습니다. 앞서 언급한 옵션을 사용하는 데 있어 유일한 주저는 미래에 Angular가 표준 @angular/core 대체품으로 제공하는 것으로 마이그레이션해야 할 수도 있다는 것입니다. 우리가 npm uninstall 하고 모든 typescript 오류를 수정하는 것이 정말로 그렇게 어려운가요?

모든 각도 프로젝트에 영향을 미치고 작동하지 않는 경우 문서화하고 마이그레이션하는 데 수많은 시간이 필요한 주요 아키텍처 결정은 저에게 훨씬 더 무섭게 보입니다.

• https://angular.io/guide/migration-renderer
• https://medium.com/@amcdnl/the -new-http-client-in-angular-4-3-754bd3ff83a8

이것은 약간의 쌍곡선입니다. 이러한 패턴을 갖기 위해 @angular/core가 "필요"하지 않습니다. 사실 이 문제에는 오늘날 모든 프로젝트에서 사용할 수 있는 많은 변형과 라이브러리가 있습니다.

아니요, 그렇지 않습니다. 각 솔루션에는 해킹이 필요하거나 변경될 수 있는 내부 API에 의존합니다. 그것이 요점입니다. @insidewhy 가 https://github.com/angular/angular/issues/5689#issuecomment -630661006이라고 말한 것과 템플릿 이벤트 스트림에 대해 그 아래에서 말한 것을 읽으십시오.

// 댓글 수정 링크 수정

아니요, 그렇지 않습니다. 각 솔루션에는 해킹이 필요하거나 변경될 수 있는 내부 API에 의존합니다.

커뮤니티에서 이를 처리할 수 있도록 하려면 어떤 내부 API 또는 유형을 공개/일반화해야 한다고 생각하십니까? 만약 이 디자인이 앞으로 나아갈 방향이 명확하지 않아서 홀딩 패턴이라면, 계속해서 같은 드럼을 두드리는 것보다 우리 자신의 디자인을 허용하도록 요청하는 것이 적절해 보입니다.

@insidewhy 가 코어 내부에서 수행하려고 시도한 다른 댓글을 읽어

@fxck 저는 이것을 핵심으로 구현하려는 시도의 역사나 이 문제가 5년 동안 어떻게 공개되었는지에 대해 논의하지 않을 것입니다. 커뮤니티가 스스로 디자인을 개발할 수 있도록 내부를 공개하지 못하는 이유는 무엇입니까?

Yo @insidewhy , 이것이 당신의 라이브러리가 의존하는 유형 검사 해킹인지 궁금합니다. 분명히 TS 4.0을 사용하여 더 이상 작동하지 않습니다.

초기화 전에 'serviceStackId$' 속성이 사용되었습니다.ts(2729)

Yo @insidewhy , 이것이 당신의 라이브러리가 의존하는 유형 검사 해킹인지 궁금합니다. 분명히 TS 4.0을 사용하여 더 이상 작동하지 않습니다.

아니요, 템플릿 컴파일러에 있었습니다. 이것은 다른 것입니다. 제길. 아 글쎄. 당신이 그것을 고치고 싶다면 내가 당신을 관리자 목록에 추가할 수 있습니다.

@fxck 실제로 데코레이터 기반 속성은 생성자가 실행될 때까지 주입되지 않으므로 ngOnInit에서 파이프된 연산자를 할당해야 합니다. 따라서 이것은 실제로 코드에 합법적인 문제입니다.

@insidewhy 나는 확실히 TS4 이전에 일을 했습니다. 그리고 이것을 확인

function ObservableInput() {
  return (target: any, propertyKey: any) => {
    Object.defineProperty(target, propertyKey, {
      set(value: any) {
        console.log(target, propertyKey, value);
      },
      get() {
        return 'ObservableInput modified value';
      },
    })
  }
}

class Foo {
    @ObservableInput()
    bar = 'original bar value';

    baz = this.bar;

    constructor() {
        console.log('loggging this.baz', this.baz);
    }
}

new Foo();

그것은 기록

this.baz ObservableInput 수정 값 로깅

그래서 나는 그것이 여전히 작동해야한다고 생각합니다. TS4에서만 컴파일러가 해당 데코레이터 내부에 값을 가진 get 가 있다는 것을 깨닫지 못하기 때문에 불평합니다.

저는 데코레이터를 사용하여 Input prop 변경을 감지하고 Input prop의 관찰 가능한 버전을 만들고 있습니다. 이 코드샌드박스 데모를 참조하십시오.

작동 방식은 다음과 같습니다.

// subjectize.ts
export function Subjectize(keyToWatch: string): PropertyDecorator {
  return (proto: any, propKey: string) => {
    const internalKey = Symbol(keyToWatch);
    Object.defineProperties(proto, {
      [keyToWatch]: {
        get() {
          return this[internalKey];
        },
        set(value) {
          this[internalKey] = value;
          this[propKey].next(value);
        }
      }
    });
  };
}

// counter.component.ts
import { Component, Input } from "@angular/core";
import { ReplaySubject } from "rxjs";
import { Subjectize } from "./subjectize";

@Component({
  selector: "app-counter",
  templateUrl: "./counter.component.html",
  styleUrls: []
})
export class CounterComponent {
  @Input()
  count: number;

  @Subjectize("count")
  count$ = new ReplaySubject(1);
}

@wmaurer가 지적했듯이 @Subjectize 는 작업을 완료하기 위해 "설탕"으로 취급될 수 있습니다.

getter/setter 사용하여 입력 변경 사항을 감지할 수 있다고 설명 하는 Angular의 공식 가이드

@hankchiutw 그 솔루션은 내 @BindObservable 데코레이터와 유사합니다. https://github.com/PSanetra/bind-observable#usage

@hankchiutw 감사합니다

ReplaySubject를 1로 초기화하기 때문에 대신 BehaviorSubject를 사용하기로 선택했습니다.
또한 Subjectize에서 직접 값을 초기화했습니다.

export function Subjectize<T>(keyToWatch: string): PropertyDecorator {
  return (target: Object, propKey: string) => {
    const internalKey = Symbol(keyToWatch);
    Object.defineProperties(target, {
      [keyToWatch]: {
        get(): T {
          return this[internalKey];
        },
        set(value: T) {
          this[internalKey] = value;

          if (this[propKey]) {
            this[propKey].next(value);
          } else {
            this[propKey] = new BehaviorSubject(value);
          }
        }
      }
    });
  };
}

@Component({
    changeDetection: ChangeDetectionStrategy.OnPush,
    selector: 'rol-bla',
    templateUrl: 'bla.html',
    styleUrls: [ 'bla.scss' ]
})
export class BlaComponent implements OnInit {
    @Input() world: World;
    @Subjectize<World>('world') world$: BehaviorSubject<World>;

    // ...
}

관련 속성에서 추측할 수 있어야 하기 때문에 "Subjectized" 속성에 대한 유형 작성을 피할 수 있기를 바랍니다.

꿈은 그렇게 할 수 있고 관련 Subject 소품(내 경우에는 world$)을 BehaviorSubject로 자동 생성하는 것입니다.그리고 올바르게 초기화되었습니다.

export class BlaComponent implements OnInit {
    @Input() @Subjectize() world: World;

    // ...
}

@mparpaillon 제안한 디자인은 https://github.com/PSanetra/bind-observable 에서 수행되는 방식과 거의 같습니다.
유일한 차이점은 @BindObservable() 데코레이터가 후드 아래에서 ReplaySubject를 사용한다는 것입니다. 따라서 해당 주제에 초기 값이 포함되도록 하려면 바인딩된 속성도 명시적으로 초기화해야 합니다(속성 유형이 정의되지 않은 값이나 null 값을 허용하지 않을 수 있으므로 정의되지 않은 경우에도).

스택블리츠 예시

@Component({
  selector: 'app-my-component',
  templateUrl: './my-component.component.html',
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class MyComponentComponent {
  @Input()
  @BindObservable()
  counter: number;
  counter$: ReplaySubject<number>;
}

@PSanetra 에게 감사하지만 내 솔루션(실제로는 Hank 솔루션)을 선호합니다.

@mparpaillon 나는 다른 데모 에서 당신의 꿈(하)을 위해 뭔가를 시도했습니다.

사용법은 다음과 같습니다.

export class CounterComponent {
  @Input()
  @Subjectize()
  count: number;

  @Input()
  @Subjectize("myCount$")
  anotherCount: number;
}

여기서 주제가 지정된 소품 이름을 지정하도록 선택할 수 있습니다.

기술적으로 가능하지만 개발자에게는 모호할 수 있습니다(새 클래스 멤버가 내부에서 생성되기 때문에).

@hankchiutw 감사

또한 모호성에 대해 옳을 수도 있습니다 ... 다시 감사합니다

Typescript에서는 count$ 또는 myCount$를 사용할 수 없는 것 같습니다.

클래스 멤버를 "count" 및 "anotherCount"로 선언했기 때문에 "myCount$" 및 "count$"에 액세스할 수 없습니다. 아무데도 선언하지 않았기 때문에 단순히 존재하지 않습니다.

알아요... 그게 요점입니다. Decorator에서 선언하는 방법을 찾고 있었습니다. @hankchiutw 가 솔루션을 제공했는데 그대로 작동하지 않는다는 것입니다.

@mparpaillon 내 솔루션을 살펴보십시오: https://github.com/Futhark/ngx-observable-input

@Futhark 오 덥다! 고마워