नमस्ते @laco0416 - आपकी अंग्रेजी ठीक है, चिंता न करें!

मुझे यह विचार बहुत पसंद है, और यह ऐसी चीज है जिस पर हम पहले चर्चा कर चुके हैं। यह https://github.com/angular/angular/issues/4062 (अवलोकन देखने की घटनाओं) और https://github.com/angular/angular/issues/5467 (माता-पिता से अवलोकन योग्य बाल कार्यक्रम) के साथ भी अच्छी तरह से मेल खाता है।

यह याद रखना महत्वपूर्ण है कि हर कोई ऑब्जर्वेबल का उपयोग नहीं करना चाहेगा (ये लोग गायब हैं!), इसलिए हमें दोनों उपयोग के मामलों के लिए विकल्प प्रदान करने होंगे, और इसलिए इसकी संभावना नहीं है कि हम @Input() सीधे ऑब्जर्वेबल बना देंगे। मुझे लगता है कि @ObserveInput() जैसी कोई चीज़ काम कर सकती है, और हमारे विचार से इनमें से कुछ और दिलचस्प विशेषताओं के बारे में _after_ हम एक चर्चा करेंगे।

इस बीच, इस विचार का एक बुनियादी (और _very_ प्रयोगात्मक!!! वास्तविक रूप से ऐसा न करें) कार्यान्वयन है। क्या यह वैचारिक रूप से आप क्या सोच रहे थे? http://plnkr.co/edit/Nvyd9IPBZp9OE2widOcW?p=preview

मुझे लगता है कि एक बच्चे के घटक में इनपुट गुणों को बदलना बहुत बुरा विचार है। इनपुट गुण "केवल पढ़ने के लिए" होना चाहिए। आपका डेटा हमेशा माता-पिता से बच्चे तक जाना चाहिए (और कभी भी विपरीत दिशा में नहीं)।

@alexpods मेरा मानना ​​​​है कि यहां विचार बिल्कुल ठीक है - इसकी _listening_ इनपुट गुणों में परिवर्तन के लिए _as_ एक अवलोकन योग्य, मूल्यों को अपस्ट्रीम उत्सर्जित नहीं करता है, जो कि जहां तक ​​​​मेरा संबंध है, बिल्कुल ठीक है।

@रोबवर्मल्ड

आपकी अंग्रेजी ठीक है, चिंता न करें!

आपको धन्यवाद! मैं बहुत राहत महसूस कर रहा हूँ।

आपका @ObserveInput वही है जो मैं चाहता हूँ!
साथ ही, @Input में कोई ब्रेकिंग परिवर्तन नहीं है। मुझे लगता है कि यह एक बहुत अच्छा समाधान है।

@alexpods मुझे भी बिल्कुल।

यह एक अवलोकन योग्य के रूप में इनपुट गुणों में परिवर्तन को सुन रहा है, मूल्यों को अपस्ट्रीम उत्सर्जित नहीं कर रहा है, जहां तक ​​​​मेरा संबंध है, बिल्कुल ठीक है।

मैं रोब की तरह ही सोचता हूं।

@ laco0416 ओह, गलतफहमी के लिए खेद है। वाक्यांश "अगर इनपुट संपत्ति को बच्चे के घटक में बदल दिया गया था" तो मुझे भ्रमित कर दिया।

मुझे नहीं पता कि मुझे यहां टिप्पणी करनी चाहिए या मुझे एक नया मुद्दा खोलना चाहिए। कृपया मुझे बताएं कि क्या मैं गलत जगह पर अनुरोध जोड़ रहा हूं।

मैं (है, लेकिन, अब तक नाकाम रहने) की कोशिश कर रहा किया गया है एक इस तरह के एक डेकोरेटर लिखने के लिए, और फिर मैं ठोकर खाई पर @robwormald के plunkr है, जो काम करता है _almost_ पूरी तरह से (लेकिन काफी नहीं)।

इस दृष्टिकोण से मुझे जो उत्साहित हुआ वह यह था कि यह ngOnChanges जीवनचक्र हुक में लाभ उठा रहा है।
मैं जो देखना चाहता हूं वह _all_ लाइफसाइकिल हुक को वेधशालाओं के रूप में उजागर करने का कोई तरीका है, यानी onChanges$: Observable<{[key: string]: SimpleChange}> , onInit$: Observable<{}> , आदि।

ऑब्जर्वेबल के रूप में सभी जीवनचक्र हुक उपलब्ध होने से मुझे सभी चीजों को आरएक्स करने में मदद मिलेगी ;-)

इस पर कोई अपडेट?

AFAIK, नहीं।
@robwormald क्या आपके पास कोई खबर है?

मुझे पता है कि यह पुराना है, लेकिन यह बहुत अच्छा होगा! @robwormald इस पर कोई शब्द?

मैं एक ऑब्जर्वेबल के रूप में बदलते हुए @Input संपत्ति मूल्यों को प्रदान करना पसंद करूंगा , ठीक उसी तरह जैसे @ObserveInput डेकोरेटर करता है। माता-पिता के घटकों को ऑब्जर्वेबल पास करना हमेशा संभव नहीं होता है, खासकर जब आप किसी मौजूदा (कोणीय 1) एप्लिकेशन को माइग्रेट कर रहे हों। एक घटक के भीतर वेधशालाओं को "शामिल" करने में सक्षम नहीं होने से आरएक्सजेएस की शक्ति और लालित्य का लाभ उठाना बहुत कठिन हो जाता है, हालांकि।

दुर्भाग्य से, रोब मजाक नहीं कर रहा था जब उसने कहा कि वह @ObserveInput इस संस्करण का उपयोग न करे। जिस समस्या में मैं चल रहा हूं वह यह है कि वेधशालाएं "वर्ग-स्तर" पर बनाई जाती हैं (यदि वह शब्दावली समझ में आती है) और इसलिए घटक के सभी उदाहरणों में साझा की जाती है। यह अच्छा नहीं है, जाहिर है। तत्काल समय पर वेधशाला बनाना मेरे लिए भी काम नहीं करता था। ऐसा लगता है कि कोणीय उस मामले में परिवर्तन का पता लगाने के लिए सही ढंग से तार नहीं करता है।

क्या किसी ने @ObserveInput बेहतर कार्यान्वयन का प्रबंधन किया है या आधिकारिक समर्थन पर कोई खबर है?

@lephyrus जबकि एक आधिकारिक @ObserveInput डेकोरेटर बहुत अच्छा होगा, @Input संपत्ति मूल्यों को बदलने का एक अवलोकन प्राप्त करने के लिए यह सख्ती से जरूरी नहीं है। डेकोरेटर बस बहुत ही सुंदर "चीनी" होगा।

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() तर्क का उपयोग क्यों करना पड़ा - मुझे अभी तक इसे देखने का समय नहीं मिला है।) फिर से: मर्सी गॉल! :आँख मारना:

@lephyrus आपका स्वागत है, gärn gescheh ;-)

मैं इस्तेमाल किया Observable.create() एक को पकड़ पाने के लिए Observer क्रम में एक ऐसा करने में सक्षम होने के लिए next() । मैं एक Subject उपयोग कर सकता था जो एक Observable और एक Observer , लेकिन मेरा मानना ​​है कि Subject ( Observer Subject ( 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 , उत्तर के लिए धन्यवाद। क्या आप अपने नमूने को एक कार्यशील संस्करण के साथ विस्तारित करने में सक्षम होंगे जहां आप "कॉन्फ़िगरेशन" ऑब्जेक्ट का उपयोग करते हैं? मैं बस अपना काम नहीं कर सकता। एक नमूना गिट रेपो? :)

@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 ऐसा मौलिक उपयोग-मामला, विश्वास नहीं कर सकता कि इसे अभी तक हल नहीं किया गया है!

मुझे अंत में सबसे अच्छा समाधान मिल गया है और यह दोहराव के बिना और एओटी संकलन के साथ काम करता है :) रहस्य @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 प्रति इनपुट विषय गेटर और सेटर बनाने के लिए क्लास प्रोप को हटाने के बारे में बात किए बिना बहुत कुछ लगता है और यह कि आपके इनपुट का प्रकार गलत है और input = value करना वास्तव में देखने योग्य पर मूल्य उत्सर्जित करेगा और आप नहीं हैं अपना विषय पूरा करना।

आप यहां मेरे विचार का एक कार्यान्वयन उदाहरण पा सकते हैं, सजावटी दृष्टिकोण प्रयोगात्मक है लेकिन मुझे लगता है कि विरासत दृष्टिकोण का उपयोग करना बहुत सुरक्षित होना चाहिए (ध्यान रखें कि मैंने इसे अभी यहां दिखाने के लिए किया है, इसका उपयोग नहीं किया जाता है)।

@ghetolay इससे कोई फर्क नहीं पड़ता कि विषय पूरा हो गया है, जब दृश्य बंद हो जाता है तो स्ट्रीम में कोई और सदस्यता नहीं होती है और इसे जीसी द्वारा निपटाया जा सकता है। देखने योग्य पर मूल्य उत्सर्जित करना मूल रूप से इसका मुद्दा है। कोणीय संकलक वर्तमान में इनपुट संपत्ति प्रकारों की जांच नहीं करता है, उम्मीद है कि जब तक यह कुछ और आधिकारिक उपलब्ध होगा;)

changes$ घटक के लिए BehaviorSubject इंटरफ़ेस को लीक करता है, आदर्श रूप से इसे Observable<...> रूप में टाइप किया जाना चाहिए, इसके अलावा यह उचित लगता है, अगर थोड़ा और वर्बोज़।

कई विषयों के मुद्दे के लिए... चाहे आप n विषयों का उपयोग कर रहे हों या 1 आपके पास अभी भी n सदस्यताएँ हैं। जब आपके पास 1 विषय होता है तो आप प्रत्येक सदस्यता में एक नक्शा ऑपरेटर और एक फ़िल्टर ऑपरेटर जोड़ते हैं, इसका प्रदर्शन ओवरहेड केवल n विषयों का उपयोग करने से बहुत कम नहीं होगा, यह और भी खराब हो सकता है।

इनपुट पैरामीटर की टाइपिंग की उपेक्षा कर खुद को, डेकोरेटर आधारित संस्करण की तुलना में observables के उपभोक्ताओं के लिए एक अधिक typesafe एपीआई प्रदान करता है SimpleChange के आधार पर प्रकार any ।

@ओहजेम्स

जब दृश्य बंद हो जाता है तो स्ट्रीम के लिए कोई और सदस्यता नहीं होती है और इसे जीसी द्वारा निपटाया जा सकता है

आप मान रहे हैं कि सभी सदस्यताएँ दृश्य से जुड़ी होंगी और दृश्य के समान जीवन चक्र प्राप्त करेंगी। मैं इस बारे में कोई धारणा नहीं बना रहा हूं कि ऑब्जर्वेबल का उपभोग कैसे किया जाएगा।

देखने योग्य पर मूल्य उत्सर्जित करना मूल रूप से इसका मुद्दा है। कोणीय संकलक वर्तमान में इनपुट संपत्ति प्रकारों की जांच नहीं करता है, उम्मीद है कि जब तक यह कुछ और आधिकारिक उपलब्ध होगा;)

मेरा मतलब उपयोगकर्ता के लिए था, उपयोगकर्ता अभी भी संपत्ति तक पहुंच और सेट कर सकता है। तो यह संपत्ति को सेट करेगा जैसे कि यह एक संख्या थी, सिवाय इसके कि इसे एक अवलोकन योग्य के रूप में टाइप किया गया है और यह संपत्ति को कभी भी सेट नहीं करेगा बल्कि इसे उत्सर्जित करेगा। यह मेरे लिए बेहद भ्रमित करने वाला है।

जहां तक ​​कई विषयों के मुद्दे की बात है... चाहे आप n विषयों का उपयोग कर रहे हों या 1 आपके पास अभी भी n सदस्यताएँ हैं। जब आपके पास 1 विषय होता है तो आप प्रत्येक सदस्यता में एक नक्शा ऑपरेटर और एक फ़िल्टर ऑपरेटर जोड़ते हैं, इसका प्रदर्शन ओवरहेड केवल n विषयों का उपयोग करने से बहुत कम नहीं होगा, यह और भी खराब हो सकता है।

यहां इस तरह की बहस में नहीं जाएंगे क्योंकि हम जल्द ही मुख्य उद्देश्य के बारे में ध्यान खो देंगे।

मैंने Subject को उजागर नहीं करने के लिए अद्यतन किया है और परिवर्तनों में टाइपिंग जोड़ने के लिए कुछ बनाया है।
मैं BehaviorSubject का उपयोग नहीं कर रहा हूं, लेकिन एक सादा Subject क्योंकि मैं उन अवलोकनीय को मूल्य धारक के रूप में नहीं बल्कि समय के साथ परिवर्तन के रूप में देख रहा हूं।
मुझे अभी एक दोष मिला है: एसिंक पाइप का उपयोग करते समय, पहला मान उत्सर्जित नहीं होता है क्योंकि एसिंक पाइप पहले उत्सर्जन के बाद सदस्यता लेगा। मैं उस मामले को ठीक से संभालने के लिए बाद में अपना कोड अपडेट करूंगा।

यहाँ लिंक फिर से है: https://stackblitz.com/edit/angular-observableinput?file=observablechanges%2Fimpl.ts

आप मान रहे हैं कि सभी सदस्यताएँ दृश्य से जुड़ी होंगी और दृश्य के समान जीवन चक्र प्राप्त करेंगी। मैं इस बारे में कोई धारणा नहीं बना रहा हूं कि ऑब्जर्वेबल का उपभोग कैसे किया जाएगा।

ठीक है, मैं आपकी बात देख रहा हूं, वेधशालाओं को पूरा करने से सभी सदस्यताएं बंद हो जाएंगी, लेकिन यह ऐसा कुछ नहीं है जो वास्तव में मुझे चिंतित करता है। हमारे ऐप में 99% सब्सक्रिप्शन एसिंक पाइप के माध्यम से होते हैं और कुछ में जिन्हें मैन्युअल रूप से बंद नहीं करना पड़ता है क्योंकि वे अक्सर रेडक्स/आदि से कंबाइनटेस्ट/स्विच मैप के माध्यम से बाहरी वेधशालाओं में स्रोत होते हैं।

यहां इस तरह की बहस में नहीं जाएंगे क्योंकि हम जल्द ही मुख्य उद्देश्य के बारे में ध्यान खो देंगे।

ठीक है, आपने एक अमान्य आलोचना उठाई है, इसलिए उसका मुकाबला करना आवश्यक था।

~ विरासत के माध्यम से अपनी कक्षा का उपयोग करने से भी काम नहीं चलेगा, एओटी कंपाइलर द्वारा उत्पन्न कोड मूल वर्गों में जीवनचक्र विधियों को कॉल नहीं करता है, देखें https://github.com/angular/angular/issues/12756#issuecomment -260804139, आप कक्षा के सभी उपभोक्ताओं के लिए ngOnDestroy() { super.ngOnDestroy() } और ngOnChanges लिए एक और जोड़ने की आवश्यकता होगी। ~ <- कुछ सीमाओं के साथ कोणीय 4.4 के रूप में तय किया गया लगता है।

मैंने एसिंक पाइप का उपयोग करने के बारे में अपनी चिंता की समीक्षा की है और चूंकि आपके पास अभी भी इनपुट तक पहुंच है, मुझे नहीं लगता कि उपयोग कोई समझ में आ रहा था। यदि आप केवल टेम्पलेट पर इनपुट मान को बांधना चाहते हैं तो आप सीधे इनपुट से जुड़ सकते हैं, यहां किसी भी अवलोकन योग्य और एसिंक का उपयोग करने की आवश्यकता नहीं है। यदि आप इससे एक नया अवलोकन योग्य बनाना चाहते हैं तो आपको ठीक वही प्राप्त करने में सक्षम होना चाहिए जो आप आसानी से चाहते हैं (शायद कहीं startWith का उपयोग करके)।

तो मुझे लगता है कि मेरा पिछला बयान ठीक है:

मैं व्यवहार विषय का उपयोग नहीं कर रहा हूं बल्कि एक सादा विषय का उपयोग कर रहा हूं क्योंकि मैं उन अवलोकन योग्य को मूल्य धारक के रूप में नहीं देख रहा हूं बल्कि समय के साथ परिवर्तन के रूप में देख रहा हूं। यदि आपको किसी इनपुट मूल्य तक पहुंच की आवश्यकता है, तो संपत्ति अभी भी मौजूद है और आप इसे समकालिक रूप से संदर्भित कर सकते हैं।

यह कोड अत्यधिक प्रयोगात्मक है, यह केवल किसी प्रकार का पॉक है और मैंने केवल उस स्टैकब्लिट्ज पर इसके साथ खेला है।
तो मुझे यह नहीं कहना चाहिए था कि यह बहुत सुरक्षित था क्षमा करें और यह एओटी के साथ काम नहीं कर सकता जैसा आपने कहा है।
बस कोशिश की और दोनों दृष्टिकोण वर्तमान में एओटी (कोणीय v4.3.6, cli v1.4.1) के साथ काम करते हैं।

यहां मेरा मुख्य बिंदु यह है कि सभी इनपुट परिवर्तनों वाले changes देखने योग्य से जाने से आपको ऑपरेटरों का उपयोग करके आपको कुछ भी करने की संभावना मिलती है: जब कोई इनपुट बदल जाता है तो प्रतिक्रिया करें, जब केवल 1 इनपुट बदल जाए, जब इनपुट की मनमानी संख्या बदल गया, जब यह एक विशिष्ट मूल्य से दूसरे आदि में बदल गया ...
आप जो अवलोकनीय चाहते हैं उसकी रचना कर सकते हैं।

इसके अलावा कार्यान्वयन के लिए प्रबंधन के लिए केवल 1 विषय है और उपयोगकर्ता बनाम 1 प्रति इनपुट के लिए उपयोग करने के लिए 1 संपत्ति है।

जो चीज मैं बदल सकता हूं वह सिर्फ नए मूल्यों का उत्सर्जन करना होगा, न कि SimpleChanges वस्तु के रूप में उपयोगकर्ता शायद pair और map का उपयोग SimpleChange के समान संरचना प्राप्त करने के लिए कर सकता है। SimpleChanges इसलिए इसे बाद में कुछ इसी तरह फिर से तैयार करने के लिए इसे विघटित करना मूर्खतापूर्ण होगा।

पुनश्च:

ठीक है, आपने एक अमान्य आलोचना उठाई है, इसलिए उसका मुकाबला करना आवश्यक था।

आपके लिए अमान्य ।

यह एक व्यक्तिगत दृष्टिकोण नहीं है जब हम प्रदर्शन की बात कर रहे हैं, ये वस्तुनिष्ठ मापन योग्य तथ्य हैं। आपको लगता है कि 6 अतिरिक्त ऑपरेटरों की तुलना में 3 विषय अधिक ओवरहेड के बराबर हैं, निश्चित रूप से आप सही हैं लेकिन यह मानने का कोई तर्कसंगत आधार नहीं है कि जब तक आप कुछ माप नहीं करते।

कई इनपुट पर प्रतिक्रिया करने के लिए ... सुनिश्चित करें कि आप केवल स्विचमैप या गठबंधन नवीनतम या कई अन्य ऑपरेटरों के साथ काम करने के लिए डिज़ाइन किए गए किसी भी अन्य ऑपरेटर का उपयोग कर सकते हैं। आप इस बारे में बहुत ही बोल्ड और व्यापक बयान दे रहे हैं, अगर आप वाकई इस बातचीत को जारी रखना चाहते हैं तो चलिए इसे इस इश्यू ट्रैकर से हटा दें।

यहाँ विभिन्न कमियों और लाभों के साथ एक संस्करण है, लेकिन इसके लिए एक आधार वर्ग की आवश्यकता है:

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 आपने गलत समझा है, इनपुट अवलोकन योग्य नहीं हैं इसलिए async पाइप मदद नहीं करता है।

@ohjames मेरे मामले में अच्छी तरह से, यह एक अवलोकन के लिए async पाइप का उपयोग करके काम करता है। और जब मैं माता-पिता से देखने योग्य मूल्य अद्यतन करता हूं, तो मान बाल घटक में दिखाई देता है।

@najibla यह @Input संपत्तियों को वेधशालाओं में बदलने के बारे में है, यह उस मामले से संबंधित है जिसका आप वर्णन कर रहे हैं।

यानी आपको इनपुट गुणों को दृश्य में देखने योग्य में बदलने की आवश्यकता नहीं है, चाहे एक घटक एक अवलोकन योग्य का उपयोग करके इनपुट संपत्ति को बदलने के लिए प्रतिक्रिया करता है या नहीं, एक घटक में ही अलग किया जाना चाहिए। अन्यथा आपको अपने घटक के इंटरफ़ेस को बदलना होगा यदि आप किसी संपत्ति को एक अवलोकन योग्य के रूप में उपभोग करने का निर्णय लेते हैं जो कोणीय के सामान्य "अवलोकन योग्य पहले" दृष्टिकोण के साथ बाधाओं पर है।

@icepeng वास्तव में आपको वह बिल्कुल सही नहीं मिला है, यह एक मानक इनपुट को एक अवलोकन योग्य में बदलने के बारे में है। तो नया पैटर्न वास्तव में होगा:

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

... तो यह एक अवलोकन योग्य के रूप में prop अंदर AppChildComponent तक पहुंचने का एक तरीका प्रदान करता है, भले ही यह एक अवलोकन योग्य नहीं है (या यदि यह एक अवलोकन योग्य था तो आपको अवलोकन योग्य प्राप्त होगा ) अब निश्चित रूप से यदि आपके उदाहरण में पहले स्थान पर prop$ था तो यह समझदार प्रतीत नहीं हो सकता है (आप पहले से ही इनपुट के साथ अवलोकन योग्य पास कर सकते हैं)। हालांकि यह बहुत अधिक मूल्य प्रदान करता है जब पारित इनपुट पहले से ही देखने योग्य नहीं होता है (उदाहरण के लिए index से ngFor )।

एक इनपुट (जो अभी पूरी तरह से संभव है) के साथ देखने योग्य पास करने में समस्या यह है कि यह OnPush साथ काफी काम नहीं करेगा।

@fxck ठीक है, आप सही कह रहे हैं कि ngOnChanges को तब नहीं कहा जाएगा जब अवलोकन योग्य उत्सर्जन (क्योंकि इनपुट वही रहता है), लेकिन जब तक आप एसिंक पाइप का उपयोग @Input से गुजरने वाले अवलोकन योग्य की सदस्यता के लिए करते हैं OnPush ठीक काम करेगा क्योंकि async पाइप मैन्युअल रूप से चाइल्ड कंपोनेंट के चेंज डिटेक्टर को ट्रिगर करता है।

हां, इसे @icepeng की ओर निर्देशित किया गया था।

@ohjames @fxck मुझे नहीं पता था कि अवलोकन योग्य पास करना अभी संभव था, गलत जानकारी के लिए खेद है।

चूंकि प्रत्यक्ष रूप से देखने योग्य गुजरना संभव है, मुझे यकीन नहीं है कि @ObserveInput उपयोगी होगा।
मुझे लगता है कि अगर मूल्य जो बदला जा सकता है वह देखने योग्य नहीं है, यह पहले से ही एक समस्या है।
बस एक व्यक्तिगत राय।

@icepeng इस पर विचार करें:

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

हुप्स के माध्यम से कूदने के बिना यहां index को देखने योग्य के रूप में उपभोग योग्य कैसे बनाया जाए?

या यह भी विचार करें कि आप एक तृतीय-पक्ष पुस्तकालय लिख रहे हैं और अपने पुस्तकालय के उपभोक्ताओं को अपने घटक को अवलोकन करने के लिए मजबूर नहीं करना चाहते हैं (कई उपयोगकर्ता धाराओं के साथ सहज नहीं हैं और आरएक्सजे से बचते हैं)।

ऐसे कई अन्य उदाहरण हैं जहां यह उपयोगी है।

@ohjames index प्रत्येक child-component लिए स्थिर मान होगा, इसलिए मुझे नहीं लगता कि इसे देखने योग्य होना चाहिए। हालाँकि, अब मुझे समझ में आया कि लोग यह सुविधा क्यों चाहते हैं। और आपका समाधान तृतीय-पक्ष पुस्तकालय लिखने के लिए अच्छा लगता है।

BehaviorSubject दृष्टिकोण बेहतर लगता है, अच्छा होगा यदि कोणीय कोर उस तरह @NgChanges() डेकोरेटर प्रदान करता है।

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

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

क्या इसे लागू करना संभव है?

1 की बफर लंबाई के साथ एक रीप्लेऑब्जर्वेबल बेहतर होगा, जब आपके पास संपत्ति तक पहुंच हो तो व्यवहार विषय के मूल्य अर्थशास्त्र की कोई आवश्यकता नहीं है।

इसे लागू करना संभव है या नहीं, इसके लिए कई अलग-अलग कार्यान्वयन और विकल्पों के लिए समस्या इतिहास की जाँच करें। कोई भी महान नहीं है और कुछ एकमुश्त टूट गए हैं, इसे ठीक से करने के लिए हमें जुड़े हुए पीआर या कुछ इसी तरह की आवश्यकता है।

मेरे 2 सेंट: ऑब्जेक्ट के रूप में। परदे के पीछे के पक्ष में मूल्यह्रास किया गया है, मेरा समाधान एक प्रॉक्सी का विस्तार करना था (हाँ आप मुझे नहीं पता, कारण मैंने इसे कंस्ट्रक्टर से वापस क्यों किया) और फिर इससे संबंधित किसी भी कुंजी को सुनने के लिए। $get(keyName) विधि के माध्यम से एक ऑब्जर्वेबल के रूप में ऑब्जेक्ट। आप इसे किसी भी वस्तु के साथ उपयोग कर सकते हैं, न केवल कोणीय वर्ग एक।

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 के माध्यम से है, मुझे आश्चर्य है कि पीआर इस मुद्दे से जुड़ा नहीं है।

यह तब तक नहीं होगा जब तक हम आइवी को शिप नहीं कर देते
बुधवार, 21 फरवरी, 2018 को सुबह 7:56 बजे जेम्स पाइक नोटिफिकेशन @github.com ने लिखा:

@bryanrideshark https://github.com/bryanrideshark का सबसे अच्छा मौका
यह समर्थित किया जा रहा है #10185 . के माध्यम से
https://github.com/angular/angular/issues/10185 मुझे लगता है, आश्चर्य हुआ कि
पीआर इस मुद्दे से जुड़ा नहीं है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/angular/angular/issues/5689#issuecomment-367372931 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAgpkvtGA4w8uHgiz0QsdYwBgqgM2EpAks5tXDyWgaJpZM4Gwr8f
.

आपकी अंग्रेजी बहुत अच्छी है और आपका कोणीय बड़ा है।

@ pldin601 आपकी विधि observable-input पैकेज देखें जो AOT के साथ अच्छा काम करता है।

@ pldin601 आपके कोड के साथ समस्या यह है कि यह गतिशील रूप से ngOnDestroy जीवनचक्र विधि जोड़ता है। एओटी संकलित कोड केवल ngOnDestroy कॉल करता है यदि संकलक स्थिर रूप से अपने अस्तित्व का अनुमान लगा सकता है। तो आपकी विधि केवल तभी काम करेगी जब डेकोरेटर का उपयोग करने वाला प्रत्येक घटक ngOnDestory को भी परिभाषित करता है (यदि आवश्यक नहीं है तो यह खाली हो सकता है)। अन्य सभी मामलों में यह सब्सक्रिप्शन को लीक कर देगा, जिससे घटकों को कचरा एकत्र होने से रोका जा सकेगा।

मुझे लगता है कि यह धारा 3.2 के पूरा होने के बाद होगा (और उम्मीद है कि इस आवश्यकता को ध्यान में रखा जाएगा)?
https://is-angular-ivy-ready.firebaseapp.com/#/status

क्या आइवी 7.0.0 का हिस्सा होगी?

मैंने एक डेकोरेटर लागू किया है जो एक संपत्ति को एक देखने योग्य साथी संपत्ति से बांध सकता है। इसका उपयोग कोणीय इनपुट गुणों पर किया जा सकता है, लेकिन किसी अन्य संपत्ति पर भी। यह @ohjames के @ObservableInput() डेकोरेटर से प्रेरित है , लेकिन बसने वालों के बीच प्रकार बेमेल के कारण होने वाली संभावित समस्याओं से बचा जाता है।

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 * जाने के लिए प्रोत्साहित करेगा और पुश चेंज डिटेक्शन के साथ ऑप्टिमाइज़ करेगा (यह मेरी राय में एक मुख्य ग्राउंडब्रेकिंग फीचर होना चाहिए)

*गैर-अवलोकन योग्य इनपुट के साथ संगतता समझौता किए बिना या हाइब्रिड इनपुट के लिए अतिरिक्त बॉयलरप्लेट की आवश्यकता के बिना: सेटर कॉलिंग नेक्स्ट ऑन सब्जेक्ट

एओटी के साथ और बिना एंगुलर 4, 5 और 7 में ऑब्जर्वेबल-इनपुट का इस्तेमाल किया। ऐसा लगता है कि यह अच्छा काम कर रहा है। मुझे पूरा यकीन है कि जब मैंने इसे लिखा था तो मैं अस्पष्ट रूप से जानता था कि मैं क्या कर रहा था।

उम्मीद है कि वे इसे ढांचे में जोड़ देंगे और इसके उपयोग को प्रोत्साहित करेंगे 2 साप्ताहिक डाउनलोड एनपीएम उन लाभों की तुलना में पर्याप्त नहीं है जो एक्सडी प्रदान करते हैं यदि वे इसे जोड़ते हैं तो मैं शर्त लगाता हूं कि लोग देखेंगे कि उस दृष्टिकोण का पालन करना आसान है

मैं उपयोगकर्ता परिभाषित observer साथ एसिंक इनपुट के लिए निम्नलिखित एपीआई का प्रस्ताव करता हूं

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

जब भी मूल्य बदलता है तो कोणीय आंतरिक केवल observer.next(newValue) कॉल कर सकता है।

@HostBinding समर्थन को भी न भूलें!

इसे और भी शानदार बनाने के लिए इसे कंस्ट्रक्टर @Input इंजेक्शन के साथ जोड़ा जाना चाहिए। इस तरह हम "सख्तप्रॉपर्टी इनिशियलाइज़ेशन" को बहुत ही शानदार तरीके से ठीक कर सकते हैं:

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 हाँ, हालाँकि आपको एक घटक से दूसरे में वेधशालाओं के रूप में इनपुट के लिए एक अलग डेकोरेटर की आवश्यकता होगी।

@ beenneq @ 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

मुझे लगता है कि यह एक छद्म आवश्यकता है। सबसे पहले, इनपुट डेकोरेटर एक ऑब्जर्वेबल टाइप वैल्यू को स्वीकार कर सकता है, दूसरी बात, अगर कंपोनेंट को इनपुट के रूप में ऑब्जर्वेबल की आवश्यकता होती है, तो इसे स्पष्ट रूप से थ्रो एरर होना चाहिए, जब एक नॉन-ऑब्जर्वेबल वैल्यू प्राप्त हो, बजाय चुपचाप ऑब्जर्वेबल टाइप वैल्यू में बदलने के।

यह जावास्क्रिप्ट में निहित प्रकार के रूपांतरण के समान है, भ्रमित हो सकता है यहां तक ​​​​कि बग और खोजने में मुश्किल हो सकती है।

यह गलत इनपुट को चुप कराने के बारे में नहीं है। यह घटकों में एक सामान्य इंटरफ़ेस को उजागर करने के बारे में है (जो गैर-अवलोकन योग्य इनपुट है)। यह आपको बाहरी दुनिया में इसके इंटरफ़ेस को तोड़े बिना rx कार्यक्षमता को पेश करने की स्वतंत्रता देता है। एक अन्य लाभ मुख्य रूप से परिवर्तनशीलता और आंतरिक स्थिति को उठा रहा है क्योंकि सब कुछ इनपुट का एक परिवर्तन होगा जो उस बिंदु से पुश परिवर्तन का पता लगाता है और कोई ब्रेनर नहीं है।

इसके विपरीत, उजागर करना, एक इंटरफ़ेस जिसके लिए वेधशालाओं की आवश्यकता होती है, वह भद्दा लगता है और लोगों को (मूल्य) प्रदान करने के लिए मजबूर करता है क्योंकि आपके घटक ने ऐसा कहा है जो मुझे अजीब लगता है।

साथ ही यह मूक रूपांतरण के बारे में नहीं है, यह rxjs के माध्यम से परिवर्तनों की सदस्यता लेने के लिए एक एपीआई है। यह देखते हुए कि angular.http और राउटर वेधशाला प्रदान करते हैं, यह बहुत अजीब है कि इनपुट परिवर्तन से निपटने में कॉलबैक और आरएक्सजे की दुनिया को एकीकृत करने के लिए बहुत अधिक बॉयलर प्लेट की आवश्यकता नहीं होती है।

ऐसा नहीं है कि मुझे उपरोक्त कुछ चतुर समाधानों से प्यार नहीं है, लेकिन कभी-कभी इसे करने के लिए 'मानक' तरीके का थोड़ा सा पुनर्गठन यहां वास्तविक समस्या को हल करने के लिए पर्याप्त है जो स्पष्टता/अनाड़ीपन की कमी है। इसके अलावा मैं अभी भी किसी दिन ऐसा करने के लिए 'आधिकारिक' पोस्ट-आइवी तरीके की उम्मीद कर रहा हूं।

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

फिर आप RxJS के साथ इनपुट को संयोजित करने के लिए बस combineLatest(this.service.magicInput$, this.inputs, config$)...... जैसा कुछ डाल सकते हैं।

या तो BehaviorSubject या ReplaySubject काम करता है। व्यवहार विषय आमतौर पर सुरक्षित और अधिक अनुमानित होता है।

• व्यवहारविषय - यदि आपके पास कोई डिफ़ॉल्ट है तो उपयोग करें
• 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 बहुत ज्यादा बॉयलरप्लेट।

मैंने अपना खुद का डेकोरेटर वहां लगाने का फैसला किया। यह मेरा पहला एनपीएम पैकेज है इसलिए मुझे यकीन है कि कुछ ऐसा है जो मुझे याद आ रहा है, लेकिन यहां यह है: 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));
  }
}

@ एमएफपी 22 वास्तव में अच्छा है, मुझे कोई कारण नहीं दिखता कि ऐसा कुछ क्यों नहीं बनाया जाना चाहिए। एफवाईआई, पैकेज के लिए एनपीएम पर जीथब लिंक पुराना है, यह यहां जाता है:

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

मुझे लगता है कि यह बहुत पुराना मुद्दा है लेकिन यह सुविधा बहुत अद्भुत है और मैं इसे कोणीय में देखने के लिए वास्तव में उत्साहित हूं।

इससे भी अच्छी बात यह है कि अवलोकन योग्य इनपुट के साथ आपको 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>;

    ...
}

मुझे लगता है कि यह बहुत पुराना मुद्दा है लेकिन यह सुविधा बहुत अद्भुत है और मैं इसे कोणीय में देखने के लिए वास्तव में उत्साहित हूं।

इससे भी अच्छी बात यह है कि अवलोकन योग्य इनपुट के साथ आपको 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)।

मैंने एक छोटा डेकोरेटर हेल्पर ( @ObservableInput ) लागू किया है जो आंतरिक रूप से @Input डेकोरेटर का विस्तार करता है और इस तरह की रचना की अनुमति देता है। आप इसे यहां देख सकते एनपीएम पैकेज के रूप में भी)। मैं सरल उदाहरणों के साथ परीक्षण कर रहा हूं, लेकिन मेरे पास विस्तारित परियोजनाओं के लिए इसका उपयोग करने का समय नहीं था। किसी भी प्रतिक्रिया का स्वागत है :)

यहां एक उपयोग उदाहरण:

@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 साल से खुला है। मुझे लगता है कि प्रतिक्रियाशील प्रोग्रामिंग दृष्टिकोण को सुविधाजनक बनाने के लिए इसका होना आवश्यक है

आइवी अंत में यहाँ है, तो मुझे लगता है कि किसी के पास इस पर काम करने का समय है? कृपया कृपया कृपया!

ओएमजी मैं सदस्यता लेता हूं कि इसकी बहुत आवश्यकता है। इनपुट डेटा को एक प्रतिक्रियाशील स्रोत के रूप में उत्सर्जित किया जाना चाहिए, और आपको इसे ngOnChanges में काम करने के लिए वर्कअराउंड का उपयोग करना होगा

वास्तव में इसके लिए तत्पर हैं

मुझे एहसास है कि कोणीय खुला स्रोत है, लेकिन क्या यह सोचना गलत या भोला है कि Google द्वारा चलाए जा रहे प्रोजेक्ट को 5 साल से कम समय में भारी तारांकित और अनुरोधित मुद्दों को हल करने में सक्षम होना चाहिए? क्या कुछ वित्तीय मुद्दे हैं जिनके बारे में मुझे जानकारी नहीं है जो Google को एंगुलर पर काम करने के लिए अधिक डेवलपर्स को काम पर रखने से रोक रहे हैं?

@ etay2000 मुझे नहीं पता, मुझे लगता है कि यह अजीब है कि आप rxjs के साथ कोणीय में 75% चीजें कैसे कर सकते हैं और फिर मौलिक और आमतौर पर घटक इनपुट के रूप में उपयोग किए जाने वाले किसी चीज़ के लिए, अचानक आप प्रक्रियात्मक में मजबूर हो जाते हैं दुनिया। आपको हमेशा अपनी परियोजना का यह महत्वपूर्ण हिस्सा मिला है जो अवलोकन योग्य दुनिया के साथ काम नहीं कर सकता है, इसलिए आपको हमेशा बॉयलरप्लेट का उपयोग करने के लिए उन्हें एक साथ वापस चिपकाने के लिए मजबूर होना पड़ता है। आप अपनी परियोजना के लिए पूरी तरह कार्यात्मक दृष्टिकोण कभी हासिल नहीं कर सकते। तो 4 साल के लिए खुला यह मुद्दा मुझे व्यावहारिकता की कमी की याद दिलाता है जिसने मुझे कोणीय और अन्य ढांचे से दूर कर दिया, इसके लिए यह बहुत उपयोगी है। यदि आप हर चीज के लिए rxjs का उपयोग करना चाहते हैं, तो शायद cycle.js एक बेहतर समाधान है, और यदि आप बिल्कुल भी rxjs का उपयोग करने के लिए बाध्य नहीं होना चाहते हैं, तो शायद Vue है। आधे समय वेधशालाओं का उपयोग करने और दूसरे आधे का उपयोग करने में सक्षम न होने का कोई मतलब नहीं है। एक उच्च सीखने की अवस्था के साथ एक बहुत शक्तिशाली अमूर्त को एकीकृत करने के लिए और फिर इसे पूरी तरह से एकीकृत करने में विफल होने के लिए बस चौंकाने वाला है।

मुझे लगता है कि प्राथमिकता की श्रृंखला इस प्रकार है

आंतरिक Google उपयोगकर्ताओं की आवश्यकताएं -> कंपाइलर के साथ कुछ भी करने के लिए तेज़ होना -> ऐप आकार के साथ कुछ भी करने के लिए छोटा होना -> कुछ भी जो नए लोगों को परेशान नहीं करता है -> डेवलपर्स वास्तव में क्या चाहते हैं

और जबकि टेक लीड कहेंगे कि वे सहमत हैं कि यह महत्वपूर्ण है, तथ्य यह है कि इगोर और मिस्को टेम्प्लेट संकलन, व्यू बाइंडिंग और रेंडरिंग के संदर्भ में अधिकांश समस्याओं के बारे में सोचते हैं। कोई फर्क नहीं पड़ता कि एंगुलर के उपभोक्ता क्या कह रहे हैं, यह उनके लिए महत्वपूर्ण है, समाधान हमेशा टेम्प्लेटिंग सिस्टम को बदलना है, या एक नया रेंडरर लिखना है, या कंपाइलर को बेहतर बनाना है।

स्रोत: https://medium.com/@jeffbcross/jeffs-letter-to-the-angular-team-and-community-5367934a16c9)

बस कुछ सबसे ऊपर उठाए गए मुद्दों को देखें।

प्रस्ताव: नमूदार के रूप में इनपुट #5689

5 साल पहले बनाया गया, एक प्रासंगिक टीम के सदस्य से अंतिम उत्तर - 5 साल पहले, वर्तमान स्थिति अज्ञात है।

टेम्प्लेट #13248 . में कोल्ड इवेंट स्ट्रीम का समर्थन करें

4 साल पहले बनाया गया, एक प्रासंगिक टीम के सदस्य से अंतिम उत्तर - 1 साल पहले, वर्तमान स्थिति - आइवी के उतरने की प्रतीक्षा कर रहा है।

प्रस्ताव: वेधशालाओं के रूप में घटक जीवनचक्र हुक प्रदान करें #10185

4 साल पहले बनाया गया, एक प्रासंगिक टीम के सदस्य से अंतिम उत्तर - 3 साल पहले, वर्तमान स्थिति अज्ञात है।

प्रस्ताव: घटक घोषणा में तत्वों को होस्ट करने के लिए निर्देश जोड़ने की क्षमता की आवश्यकता है। #8785

4 साल पहले बनाया गया, एक प्रासंगिक टीम के सदस्य से अंतिम उत्तर - 2 साल पहले, वर्तमान स्थिति अज्ञात है।

as local-val बिना *एनजीआईएफ #15280 . के

4 साल पहले बनाया गया, एक प्रासंगिक टीम के सदस्य से अंतिम उत्तर - 2 साल पहले, वर्तमान स्थिति अज्ञात है।

गतिशील सामग्री प्रक्षेपण के लिए समर्थन #8563

4 साल पहले बनाया गया, एक प्रासंगिक टीम के सदस्य से अंतिम उत्तर - 3 साल पहले, वर्तमान स्थिति अज्ञात है।

एनजी-सामग्री डिफ़ॉल्ट सामग्री #12530

4 साल पहले बनाया गया, एक प्रासंगिक टीम के सदस्य से अंतिम उत्तर - कभी नहीं, वर्तमान स्थिति अज्ञात।

फिर घटकों की विशेषताएं जैसी चीजें हैं, जो उच्च क्रम के घटकों की अनुमति देती हैं, फिर निश्चित रूप से कई और सबसे ऊपर उठाए गए मुद्दे हैं, लेकिन मुझे आशा है कि इन्हें संबोधित किया जाएगा (अर्थात, संबोधित किया गया है, जरूरी नहीं कि उन्हें आइवी के तुरंत बाद लागू होने की उम्मीद है) ), क्योंकि उन्हें ढांचे और प्रतिक्रियाशीलता के रोजमर्रा के उपयोग के साथ करना है, जो मुझे लगता है कि कोई भी तर्क नहीं देगा, जो कि ज्यादातर लोग उपयोग कर रहे हैं (दिया गया ngrx सबसे लोकप्रिय राज्य प्रबंधन lib है)।

मेरा ऐप आधा बेक किया हुआ है (केवल तकनीकी सीमाओं के कारण, कुछ को केवल कोर में ठीक से किया जा सकता है) "पॉलीफिल" और इनमें से अधिकांश मुद्दों को हैक करता है, इस उम्मीद में कि मैं एक दिन कोणीय मूल में ड्रॉप कर पाऊंगा प्रतिस्थापन। लेकिन किसी तरह यह आता नहीं दिख रहा है।

तो हाँ, मान लीजिए कि कुछ सबसे बड़ी प्रतिक्रियाशीलता/डेवलपर्स अनुभव से संबंधित मुद्दों की स्थिति को संबोधित करने वाली एक ब्लॉग पोस्ट की वास्तविक रूप से सराहना की जाएगी।

हम इस सुविधा के पहले संस्करण को स्वयं कोड करने का प्रयास कैसे करेंगे? मैं हूँ
कोविड बात के दौरान बोरियत से मरना, कौन मेरे साथ जुड़ना चाहता है?

कई लोगों ने पहले ही किया था, उदा। https://github.com/insidewhy/observable-input

इनमें से अधिकांश के साथ समस्या यह है कि उन्हें कुशलतापूर्वक करने के लिए, आपको संकलक या कोणीय के अन्य आंतरिक भागों को संशोधित करने की आवश्यकता है।

यह गिनती नहीं है। मेरा मतलब है कि चलो कोणीय में उचित योगदान करते हैं
सार। आखिरकार, हमारे पास स्रोत कोड उपलब्ध है। दरअसल, मुझे नहीं लगता कि इस मामले में हमें कंपाइलर को छूने की भी जरूरत पड़ेगी।

@ganqqwerty मैंने उस पुस्तकालय को लिखने से पहले इसे कोणीय के अंदर लागू करने की कोशिश की। हालांकि कोणीय बेहद जटिल है। इसके लिए निष्पक्ष होने के लिए, कोड रिएक्ट और इसके पागल पांच-सौ-लाइन-लंबे-फ़ंक्शंस की तुलना में कहीं अधिक पठनीय और समझने योग्य है, लेकिन यह "परिष्कृत" है। और मुझे अभी भी उस कार्यान्वयन को करने के लिए प्रयास करने में खुशी होती अगर मुझे लगता कि यह सार्थक था। लेकिन मैं इसे @fxck के ऊपर पुनरावृति के ठीक कारणों के लिए सार्थक नहीं देखता। कोणीय टीम समुदाय की बात नहीं सुनती है, वे सामान्य रूप से कोणीय की उपयोगिता की परवाह किए बिना लगातार अनुकूलन और प्रदर्शन पर ध्यान देते हैं। मुझे उस ढांचे की परवाह नहीं है जो अच्छा प्रदर्शन करता है जब यह मुझे पांच साल पहले प्रदर्शित की गई साधारण समस्याओं के लिए बॉयलरप्लेट को लागू करने के लिए मजबूर करता है। इसलिए मैंने एंगुलर के बारे में परवाह करना बंद करने का फैसला किया, उन परियोजनाओं का समर्थन करने के लिए आवश्यक न्यूनतम प्रयास को लागू किया जिन पर मैं पहले से ही काम कर रहा था और भविष्य की सभी परियोजनाओं के लिए जहां भी और जब भी संभव हो, इससे बचें।

यह केवल मेरे विचार से एंगुलर की समस्या नहीं है, बल्कि Google के कई प्रस्तावों के साथ है। यह समस्या और अन्य जो ऊपर सूचीबद्ध @fxck Google में स्थानिक समस्याओं के अधिक उदाहरण हैं। यदि आप डार्ट या गोलैंग को देखते हैं, तो आप देखेंगे कि डेवलपर्स बहुत प्रसिद्ध आम तौर पर सामना की जाने वाली समस्याओं को उठाते हैं और मुद्दों को 5+ वर्षों के लिए खुला रखते हैं।

मैं मानता हूं कि इसे जोड़ा जाना चाहिए, लेकिन वाह, इस धागे पर नफरत थोड़ी ज्यादा है, मेरा मतलब है कि हम कुछ ऐसा जोड़ने की बात कर रहे हैं जो कोड की कुछ पंक्तियों को बचाता है। @Input से सजाए गए एक सेटर के साथ अब आपके पास अवलोकन योग्य इनपुट हो सकते हैं और आपका अपना विषय जिस पर आप मूल्यों को धक्का देते हैं:

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

यदि वह बहुत अधिक बॉयलरप्लेट है, तो हमारे पास पहले से ही कुछ सरल तृतीय पक्ष विकल्प हैं:

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

मैं कोणीय के विकास से खुश हूं, और निश्चित रूप से इस तरह की एक छोटी (यद्यपि वांछनीय) सुविधा के कारण आश्चर्यजनक रूप से पूर्ण विशेषताओं और विश्वसनीय ढांचे को नहीं छोड़ूंगा

सामान्य समस्या मुख्य रूप से इस दृष्टिकोण से है कि लोग इसे कैसे देखते हैं। किसी के लिए, यह कोड की कुछ पंक्तियाँ हैं और कुछ भी बदलना/जोड़ना बहुत आसान लगता है, लेकिन वास्तव में, बहुत बड़ा दायरा और कई दुष्प्रभाव हैं। उन सभी को ध्यान में रखा जाना चाहिए और हमेशा की तरह, विषयों की कतार लंबी है और हर चीज का कुछ मूल्य, अतिरिक्त मूल्य और प्राथमिकता होती है।

मैं यह बताना चाहता हूं कि मैं व्यक्तिगत रूप से इन सभी मुद्दों को तुरंत हल करने की उम्मीद नहीं करता हूं।

लेकिन मुझे उम्मीद है, कि अब, आइवी रास्ते से हट गया है और कुछ समय के लिए जंगल में बाहर हो गया है, शीर्ष 25 अपवोट मुद्दों पर किसी प्रकार का आधिकारिक अपडेट प्रकाशित किया जाएगा।

मेरा मतलब है, मुझे इस आकार की एक परियोजना के लिए यह संभव नहीं लगता है कि परियोजना प्रबंधन में प्राथमिकता नहीं है और शीर्ष 25 (या जो कुछ भी) ऊपर उठाए गए मुद्दों के लिए किसी प्रकार की योजना है। इनमें से अधिकांश के पास effort टैग भी है। बस एक ब्लॉग पोस्ट करें, समुदाय को बताएं कि आप इनके बारे में जानते हैं और आपके पास उनके लिए किसी प्रकार की योजना है।

मैं निश्चित रूप से कोणीय को नहीं छोड़ूंगा, इसकी सभी कमियों के लिए मुझे अभी भी यह अन्य सभी विकल्पों की तुलना में बहुत बेहतर लगता है। लेकिन मुझे लगता है कि यह कहना उचित है कि "सामुदायिक संबंध प्रबंधन" (जीथब विशिष्ट पर) में इसकी कमी है।

// संपादित करें

क्या आप अच्छे लोगों को इस पोल को भरने में कोई आपत्ति होगी? आपकी वर्तमान स्थिति और विचार की गई सभी बातों को देखते हुए, इनमें से कौन सी समस्या आपको सबसे अधिक प्रभावित करती है / आपके डेवलपर अनुभव को सबसे अधिक बेहतर बनाएगी https://forms.gle/cprhx239kuqwWd5M8

@fxck इसे लिखने के लिए धन्यवाद। मुझे आश्चर्य होने लगा था कि क्या सभी ने इस तथ्य को स्वीकार कर लिया है कि एंगुलर टीम वही करेगी जो वे चाहते हैं, जब वे चाहेंगे। जबकि यह निश्चित रूप से उनका अधिकार है, मुझे यह भी लगता है कि जब लोग डेवलपर्स की आवाज को लगातार अनदेखा करते हैं तो लोगों को उन्हें कॉल करना आवश्यक होता है। मैं सहमत हूं कि मुझे नहीं लगता कि कोई भी मुद्दों के तत्काल समाधान की उम्मीद करता है, लेकिन 4-5 वर्षों के लिए उन्हें अनदेखा करना या जब तक समस्या स्वचालित रूप से बंद नहीं हो जाती तब तक प्रतीक्षा करना किसी भी परियोजना के लिए वास्तव में गैर-पेशेवर लगता है, अकेले Google चलाने वाले प्रोजेक्ट को छोड़ दें। उन्होंने खुले मुद्दों के एक समूह में 'फिक्स्ड बाय आइवी' टैग जोड़कर कुछ समय खरीदा, फिर उसके बाद कुछ भी नहीं किया।

मैं निश्चित रूप से कोणीय को नहीं छोड़ूंगा, इसकी सभी कमियों के लिए मुझे अभी भी यह अन्य सभी विकल्पों की तुलना में बहुत बेहतर लगता है। लेकिन मुझे लगता है कि यह कहना उचित है कि "सामुदायिक संबंध प्रबंधन" (जीथब विशिष्ट पर) में इसकी कमी है।

मुझे लगता है कि यह वाक्य मेरे विचारों को पूरी तरह से समेट देता है।

@chriszrc मैंने वास्तव में इस धागे में 'नफरत' के रूप में कुछ भी व्याख्या नहीं की है। अधिक लोगों की तरह अंततः कोणीय के साथ अपनी कुंठाओं को नियमित रूप से एक समय में वर्षों तक मुद्दों की अनदेखी करना। यह विशेष रूप से इस मुद्दे के बारे में भी नहीं है, यह किसी प्रकार के सामुदायिक संपर्क को बनाए रखने के सिद्धांत के बारे में है। क्या एंगुलर टीम को किसी और से इतना बेहतर माना जाता है कि उन्हें लगता है कि वे डेवलपर अनुरोधों को अनदेखा कर सकते हैं क्योंकि वे जानते हैं कि सभी के लिए सबसे अच्छा क्या है?

@chriszrc मुझे इस धागे में कोई नफरत नहीं दिख रही है, बस समझने योग्य निराशा का एक गुच्छा है। मुझे लगता है कि "कोड की कुछ पंक्तियों को सहेजना" के साथ इस अनुरोध और संबंधित निराशा की तुलना करना एक अतिशयोक्ति है। यह केवल यह मुद्दा नहीं है जो समुदाय को निराश कर रहा है बल्कि लोकप्रिय मुद्दों के महत्वपूर्ण संग्रह को @fxck ने ऊपर उठाया है जिसे उपेक्षित किया गया है।

सभी को नमस्कार, इस सूत्र पर चुप्पी के लिए क्षमा करें। कुछ समय से हमें दो ओर्थोगोनल अनुरोध मिल रहे हैं:

1. ढांचे में बेहतर प्रथम श्रेणी RxJS समर्थन
2. कोणीय में कम RxJS, संभावित रूप से इसे वैकल्पिक बना रहा है

दोनों अनुरोध हमारे रडार पर हैं, और दोनों के अपने फायदे और नुकसान हैं। उदाहरण के लिए, यदि हम पहली दिशा में जाते हैं, तो हम आरएक्सजेएस के अभिव्यंजक, अर्थपूर्ण रूप से समृद्ध एपीआई के लिए नए इंजीनियरों के लिए ढांचे को कम सुलभ बना देंगे। बहुत से लोगों को अपने कोणीय ऐप्स में हर जगह RxJS का उपयोग करने में चिंता होती है, जिससे स्रोत कोड को विभिन्न अनुभव स्तरों वाले टीम के सदस्यों के लिए पढ़ना मुश्किल हो जाता है।

उसी समय, हमारे पास पहले से ही बहुत सारे प्रतिक्रियाशील एपीआई हैं, लेकिन एंगुलर द्वारा पेश किए गए कुछ प्राइमेटिव पूरी तरह से अनिवार्य हैं, और चीजें बहुत अच्छी तरह से वायर नहीं होती हैं। उस ने कहा, यह प्रतिक्रियाशीलता समर्थन में सुधार करने के लिए समझ में आता है, लेकिन क्या यह कोणीय के मूल का हिस्सा होना चाहिए या एक सामुदायिक परियोजना (उदाहरण के लिए ngrx - कोणीय का प्रतिक्रियाशील विस्तार) को सौंपा जाना चाहिए, जिसके साथ हम निकट सहयोग कर रहे हैं?

इस समस्या को हल करने के कई तरीके हैं, लेकिन हमें इस पर विचार करने की आवश्यकता है:

• पिछड़ी संगतता - न केवल स्रोत कोड के लिए बल्कि प्रशिक्षण संसाधनों के लिए भी
• सीखने की अवस्था
• वर्तमान एपीआई के साथ संगति
• परियोजनाओं में संगति
• प्रदर्शन - रनटाइम और प्रारंभिक लोड समय दोनों

हम कुछ शीर्ष GitHub मुद्दों को प्राथमिकता देने की प्रक्रिया में हैं, सबसे अधिक अनुरोधित और प्रभावशाली सुधारों को देखते हुए जिन्हें हम संबोधित कर सकते हैं। मैं कहूंगा कि यह अधिक चुनौतीपूर्ण लोगों में से एक है, इसलिए डेट पर जाना कठिन है।

@mgchev उत्तर देने के लिए धन्यवाद। यदि rxjs और प्रतिक्रियाशील एपिस किसी अन्य एक्सटेंशन (मेरे व्यक्तिगत वोट नहीं) में विभाजित होने जा रहे हैं, तो क्या यह संभवतः अधिक समझ में आता है कि यह किसी विशेष राज्य-स्टोर/रेडक्स कार्यान्वयन के साथ नहीं है? मैं जल्दी से ngrx से ngxs पर चला गया (जो कि कम बॉयलरप्लेट की तरह महसूस होता था, और सज्जाकारों के साथ अधिक "कोणीय") और फिर अंत में अकिता के लिए, जो कि मेरा वर्तमान पसंदीदा है और जिसे मैं सबसे अधिक विकसित कर रहा हूं। या अगर यह ngrx के साथ जुड़ जाता है, तो कम से कम वास्तव में केवल उन हिस्सों को जोड़ना आसान बना देता है जिनकी हमें ज़रूरत है, इसलिए हम ngrx का उपयोग करने या उन निर्भरताओं को शामिल करने में बंद नहीं हैं-

यदि rxjs और प्रतिक्रियाशील एपिस दूसरे विस्तार में विभाजित होने जा रहे हैं (मेरा व्यक्तिगत वोट नहीं)

मैं यह नहीं कह रहा हूं कि ऐसा होने वाला है। अपनी टिप्पणी में मैं सिर्फ विकल्पों की एक अधूरी सूची साझा कर रहा हूं ताकि मैं परियोजना के दायरे और हमारे पास मौजूद विभिन्न विचारों को दिखा सकूं।

@mgchev वास्तव में, उत्तर के लिए धन्यवाद।

हालांकि, मुझे आश्चर्य है कि अगर एंगुलर का प्रतिक्रियाशील हिस्सा किसी तरह सामुदायिक परियोजना में "पदावनत" हो जाता है, तो क्या इसका मतलब यह नहीं होगा कि प्रतिक्रियाशील एंगुलर का द्वितीय श्रेणी का नागरिक बन जाएगा?

@mgchev मुझे लगता है कि आपका दर्द एक ही बार में दो दिशाओं में फटा जा रहा है। हमारी टीम वास्तव में अनिवार्य/प्रतिक्रियाशील टुकड़ों को विभाजित करने का विरोध नहीं करती है।

इस तरह के विभाजन के लिए हमारी आवश्यकताएं यहां होंगी:

• अनिवार्य और प्रतिक्रियाशील दोनों का उपयोग करने के लिए देशी महसूस करने की आवश्यकता है और न ही इसे महसूस किया जाना चाहिए
• प्रतिक्रियाशील को सक्षम करने के लिए विशिष्ट राज्य प्रबंधन समाधान के साथ कोई संबंध नहीं (पूर्ण प्रकटीकरण हमने अब तक अकिता का उपयोग करने के लिए सभी 50+ परियोजनाओं को स्थानांतरित कर दिया है)
• दोनों विकल्पों को एक ही संस्करण में एक ही समय में जारी करने की आवश्यकता है (कोई अंतराल / देरी नहीं)
• कोई "पसंदीदा" नहीं हो सकता है, कुछ भी कोणीय को देशी महसूस करते हुए दोनों दुनिया में काम करने की आवश्यकता होगी
• कोणीय टीम द्वारा समर्थित दोनों दृष्टिकोणों के लिए पूर्ण आधिकारिक समर्थन (हमारे अनुभव के आधार पर यह ग्राहक की हार्ड स्टॉप ग्राहक आवश्यकता है)

ऊपर के आधार पर:

• 2 मुख्य विकल्प हैं:
  
  
  
  • कोर अनिवार्य + एडऑन रिएक्टिव
  
  
  • कोर प्रतिक्रियाशील + एडऑन अनिवार्य
  
  
• इसे अनिवार्य बनाने के लिए प्रतिक्रियाशील लपेटना बहुत सीधे आगे है, ऐसा दूसरे तरीके से नहीं है
• इसलिए हम कोर में प्रतिक्रियाशील का उपयोग करने के लिए मतदान करेंगे और ऐडऑन में अनिवार्य एपीआई शामिल होंगे
• शून्य विलंब के कारण + कोई पसंदीदा आवश्यकता नहीं होने के साथ-साथ आवश्यक आधिकारिक समर्थन के कारण मैं यह नहीं देखता कि एडऑन एक सामुदायिक परियोजना कैसे हो सकती है

मैं समझता हूं कि उपरोक्त दुनिया के बारे में हमारा दृष्टिकोण है और कई अन्य हैं। मेरे द्वारा इसे लिखने का कारण यह है:

• यदि आप एक सामुदायिक परियोजना में प्रतिक्रियाशील निकालने पर उतरते हैं तो हमें 50+ समाधानों को दूसरे ढांचे में स्थानांतरित करना होगा (फिर से यह ग्राहक संचालित होगा, हमारी पसंद नहीं)
• इसलिए मैं हमें (समुदाय को) जल्द से जल्द यह बताने के लिए कहूंगा कि आप इस पर कहां उतरते हैं, इसलिए हमारे पास अपने डेवलपर्स को एक और ढांचे पर फिर से प्रशिक्षित करने और उन परियोजनाओं को स्थानांतरित करने का समय है।

कृपया सुविधा जोड़ें

@mgchev मुझे आपकी चिंता नहीं है। यह प्रस्ताव दो दुनियाओं को एक समान और सीधे नौसिखिए डेवलपर्स इंटरफेस के साथ जोड़ने के बारे में है। यह एक या दूसरे को चुनने के बारे में नहीं है बल्कि संयोजन को सक्षम करने के बारे में है। उदाहरण के लिए डेवलपर x एक भयानक प्रतिक्रियाशील घटक बनाने का निर्णय लेता है। और डेवलपर y इसे अपने इतने प्रतिक्रियाशील प्रोजेक्ट में उपयोग करने का निर्णय नहीं लेता है। क्यों नहीं? उसे किसी एनजीआरएक्स गोंद पर निर्भर रहने की आवश्यकता क्यों है?
दो दुनियाओं के बीच का अंतर यह है कि क्या आप अपने अंतिम स्मार्ट घटक बनाम केंद्रीय राज्य स्टोर में राज्य को स्टोर/प्रबंधित करते हैं और यही एनजीआरएक्स के बारे में होना चाहिए, लेकिन घटकों के लिए मुझे लगता है कि ढांचा ही सक्षम होना चाहिए।

कुछ समय से हमें दो ओर्थोगोनल अनुरोध मिल रहे हैं:

1. ढांचे में बेहतर प्रथम श्रेणी RxJS समर्थन
2. कोणीय में कम RxJS, संभावित रूप से इसे वैकल्पिक बना रहा है

मैं किसी भी तरह से ठीक हो जाऊंगा, लेकिन कभी-कभी यह कभी-कभी कोणीय को एक असंबद्ध अनुभव देता है, जो कि बैटरी-शामिल ढांचे को छोड़कर आखिरी चीज है।

व्यक्तिगत रूप से, मैं यह देखने के लिए उत्सुक हूं कि आपके पास सभी कोणीय पैकेजों (HTTP, राउटर, फॉर्म) के लिए गैर-RxJS संस्करण भी कैसे होंगे। मुझे संदेह है कि इनमें से अच्छे गैर-आरएक्सजेएस संस्करण नहीं हैं, यही वजह है कि उनके पास पहले स्थान पर आरएक्सजेएस है।

कहने का तात्पर्य यह है कि .... जब तक मैं कुछ याद नहीं कर रहा हूँ, (2) संभव नहीं है।

पीएस मैं उन अनुरोधों को "ऑर्थोगोनल" के रूप में वर्णित नहीं करूंगा; अधिक "विपरीत" की तरह।

कोणीय में कम RxJS, संभावित रूप से इसे वैकल्पिक बना रहा है

जिज्ञासा से बाहर @mgchev , क्या इसके लिए कोई

@pauldraper मैंने

जीथब पर आरएक्सजे के बारे में शिकायत करने वाली हर एक टिप्पणी के लिए शायद हजारों देव बिना किसी समस्या के इसका उपयोग कर रहे हैं और इसका आनंद ले रहे हैं।

यहां उस फॉर्म के परिणाम

आश्चर्य रूपों गधा में सबसे बड़ी दर्द @brandonroberts कर रहे हैं, लेकिन जाहिरा तौर पर और @MikeRyanDev हो सकता है कुछ खाना पकाने, पिछले पर।

जीथब पर आरएक्सजे के बारे में शिकायत करने वाली हर एक टिप्पणी के लिए शायद हजारों देव बिना किसी समस्या के इसका उपयोग कर रहे हैं और इसका आनंद ले रहे हैं।

भले ही मैं rxjs से प्यार करता हूं, मैं इतना आशावादी नहीं हूं। मैंने बहुत सारे देवों के साथ काम किया है, जो इतने जले हुए हैं कि एक कठिन सीखने की अवस्था के साथ कुछ सीखने के लिए समय देना एक बुरा सपना है। और बहुत से लोग जो कोडिंग की तुलना में पैसा कमाने के बारे में अधिक परवाह करते हैं: डी या आक्रामक जूनियर देव जो सोचते हैं कि वे एक दिन में जो कुछ भी नहीं सीख सकते हैं वह कचरा होना चाहिए।

मैंने बहुत सारे देवों के साथ काम किया है, जो इतने जले हुए हैं कि एक कठिन सीखने की अवस्था के साथ कुछ सीखने के लिए समय देना एक बुरा सपना है। और बहुत से लोग जो कोडिंग से ज्यादा पैसा कमाने की परवाह करते हैं

वे देव हैं जो एंगुलर को पूरा करने की कोशिश कर रहे हैं, जल गए हैं और बिना सीखना चाहते हैं? :) और जो इस समय वैसे भी परवाह करता है। कोणीय कुछ समय के लिए आसपास रहा है, यह कहीं भी नहीं जा रहा है और यदि आप अवलोकन योग्य जीवनचक्र, अवलोकन योग्य इनपुट, अवलोकन योग्य घटनाओं को जोड़ते हैं तो यह बिल्कुल भी नहीं खोने वाला है। बस उन तीन छोटी चीजों को जोड़ें और लोग थोड़ी देर के लिए खुश होंगे, बस (और मूल पैकेज को पूरा करने के लिए https://indepth.dev/component-features-with-angular-ivy/ के साथ इसका पालन करें)।

यह सब कहता है। IMHO कोणीय को सुसंगत रहना चाहिए और अधिक RxJS का उपयोग करना चाहिए: बिना RxJS के साथ यह कोणीय नहीं होगा।

वे देव हैं जो एंगुलर को पूरा करने की कोशिश कर रहे हैं? :)

हां, केवल उन डेवलपर्स को पूरा करना दिखावा होगा जो rxjs का उपयोग करके कोड लिखना चाहते हैं। भले ही मैं rxjs का उपयोग करना पसंद करता हूं, मैं चाहता हूं कि एंगुलर डेवलपर्स के दोनों सेटों को पूरा करे। एंगुलर को केवल हमें ही क्यों पूरा करना चाहिए, न कि जो अलग सोचते हैं? खासकर जब मैं मानता हूं कि हम अल्पसंख्यक हैं, बहुसंख्यक नहीं।

फिर से, "पूरी तरह से प्रतिक्रियाशील" जा रहा है, जैसा कि देखने योग्य जीवन चक्र, इनपुट, घटनाओं को जोड़ने से आप जिन लोगों के बारे में बात कर रहे हैं उन्हें प्रभावित नहीं करेंगे, लेकिन दूसरे समूह को बहुत खुश करेंगे।

और घटक सुविधाएँ उपयोगी हैं चाहे आप प्रतिक्रियाशील प्रोग्रामिंग पसंद करें या नहीं।

@fxck मैं इससे एक सेकंड के लिए भी असहमत नहीं था। मैं आपकी पिछली टिप्पणी का जवाब सिर्फ यह बताने के लिए दे रहा था कि ऐसे कई लोग हैं जो rxjs का उपयोग नहीं करना चाहते हैं और उनमें से कई ने इसके बारे में शिकायत करने के लिए github मुद्दों को खोला है।

कोणीय कैसे कोर विकसित करने का निर्णय लेता है - प्रतिक्रियाशील रूप से या नहीं, आदर्श दुनिया में विपरीत जरूरतों को पूरा करने के लिए शीर्ष पर बनाया गया विपरीत पैकेज होगा (उदाहरण के लिए @angular/reactive या @angular/imperative - बेहतर नामों के साथ उम्मीद है)।

इन दोनों में से कोई भी समुदाय में जाना मेरे लिए कुछ लोगों के लिए डाउनग्रेड है और मेरे लिए कोणीय एक महान प्रतिक्रियाशील ढांचा होने का दृष्टिकोण पहले स्थान पर इसके साथ जाने का एक कारण था।

एक तरफ ध्यान दें, मुझे लगता है कि कोणीय प्रतिक्रियाशील रखना और अनिवार्य एक्सटेंशन रखना आसान होगा, क्योंकि प्रतिक्रियाशील के लिए अनिवार्यता को ब्रिज करने के बजाय पुल करना आसान है - कोर और एक्सटेंशन पैकेज दोनों की सादगी के लिए बोलना।

अस्वीकरण: आखिरी बिंदु जिसे मैंने धारणाओं के आधार पर तैयार किया है - आश्चर्य नहीं होगा यदि मूल अनिवार्यता लिखना बहुत आसान है - विस्तार प्रतिक्रियाशील अधिक जटिल होगा।

जिज्ञासा से बाहर @mgchev , क्या इसके लिए कोई

Google की आंतरिक चीज़ नहीं है। आपको आश्चर्य होगा (जैसे मैं था, जब मैं टीम में शामिल हुआ था), बाहरी और आंतरिक आवश्यकताओं के बीच का अंतर कितना बड़ा है। मुख्य अंतर निर्माण प्रणाली और निर्भरता प्रबंधन में है, इसके अलावा गोगलर्स की गैर-गोगलर्स के समान ही आवश्यकताएं हैं।

हम हजारों डेवलपर्स के संपर्क में हैं - बहुत सी बाहरी कंपनियां, आंतरिक टीमें, और व्यक्तिगत योगदानकर्ता। दोनों ही मामलों में ऐसे लोग हैं जो RxJS के साथ पूर्ण रूप से जाना पसंद करेंगे और अन्य जो नहीं सोचते कि यह उनके लिए सही विकल्प है। दोनों खेमों में बेहतरीन तर्क हैं।

यह कोई निर्णय नहीं है जिसे हम जल्दी करना चाहते हैं, विशेष रूप से यह देखते हुए कि अच्छी तरह से स्थापित वर्कअराउंड/सामुदायिक समाधान हैं समुदाय में किया गया कार्य हमें अतिरिक्त डेटा बिंदु एकत्र करने और चर के वर्तमान सेट के लिए एक इष्टतम समाधान स्थापित करने में मदद करता है।

मुझे लगता है कि एक कोणीय ऐप विकसित करते समय एक एकीकृत दृष्टिकोण प्रतिक्रियाशील या अनिवार्य (यह प्रति परियोजना एक विकल्प है) अत्यधिक फायदेमंद होगा। मिश्रण और मिलान करने की क्षमता विकास के अनुभव में सहायता नहीं करती है और गैर डीआरवाई कोड (जैसे गैर प्रतिक्रियाशील इनपुट) बनाती है।

अलगाव में कुछ भी नहीं होता है, इसलिए मैं कॉर्पोरेट वातावरण को पूरी तरह से समझ सकता हूं कि प्रतिक्रियाशील प्रोग्रामिंग के लिए बड़ी मात्रा में देवों को फिर से प्रशिक्षित करने के लिए कठिन समय है। इसलिए अनिवार्यता को छोड़ना वास्तव में कोणीय को कॉर्पोरेट स्वीट-स्पॉट से बाहर ले जाएगा, जो यथार्थवादी होने देता है बस ऐसा नहीं होने वाला है क्योंकि यह कोणीय जैसे ढांचे के लिए एक बड़ा कुंजी उपयोगकर्ता आधार बनाता है।

उस ने कहा कि मैं यथार्थवादी होने के रूप में नहीं देखता एक अनिवार्य के शीर्ष पर एक प्रतिक्रियाशील इंटरफ़ेस बना रहा है। दूसरी दिशा बहुत सीधे आगे है क्योंकि आप हमेशा एक वेरिएबल के आउटपुट को एक चर में लिख सकते हैं जिसे तब अनिवार्य रूप से उपयोग किया जा सकता है। वास्तव में कवर के तहत कई जगहों पर कोणीय पहले से ही यही कर रहा है।

इसलिए मैं इसके मूल में कोणीय को पूरी तरह से प्रतिक्रियाशील बनाने के लिए वोट देता हूं और फिर शीर्ष पर अनिवार्य "रैपर" बनाता हूं।

इस दृष्टिकोण के साथ मुख्य मुद्दा अनिवार्य उपयोगकर्ताओं के लिए बड़े प्रवासन कदम होने की संभावना है। जो कॉर्पोरेट वातावरण में एक गैर है जो कि ठीक वही हो सकता है जिसे कोणीय टीम रोकने की कोशिश कर रही है, इसलिए सुझाव को मूल में अनिवार्य है।

@mgchev चूंकि इसे दो बार उठाया गया है, प्रतिक्रियाशील कोर/अनिवार्य विस्तार के बारे में आपके विचार सुनना दिलचस्प होगा और यदि इसके पास खड़े होने के लिए कोई पैर है?

दोनों ही मामलों में ऐसे लोग हैं जो RxJS के साथ पूर्ण रूप से जाना पसंद करेंगे और अन्य जो नहीं सोचते कि यह उनके लिए सही विकल्प है। दोनों खेमों में बेहतरीन तर्क हैं।

बढ़िया, जानकर अच्छा लगा। RxJS के साथ पूर्ण रूप से जाने को परिभाषित करें? देखने योग्य जीवनचक्र, देखने योग्य इनपुट और देखने योग्य घटनाओं को जोड़ना उसमें कैसे फिट होता है? और नहीं, इनमें से किसी के पास वास्तव में "अच्छी तरह से स्थापित वर्कअराउंड/सामुदायिक समाधान" नहीं है।

@fxck इनमें से किसी के पास वास्तव में "अच्छी तरह से स्थापित वर्कअराउंड/सामुदायिक समाधान" नहीं है।

यह सच है। मैंने इनमें से एक समाधान लिखा था और यह केवल एक बड़ी हैक के कारण काम करता है जो टेम्पलेट्स में खराब टाइप-चेकिंग पर निर्भर करता है। मैंने इस धागे में पोस्ट किए गए कुछ अन्य समाधानों की भी जांच की है और उनमें से प्रत्येक में निम्न में से कम से कम एक समस्या है:

• सदस्यता लीक
• उपयोगकर्ता पर बॉयलरप्लेट आवश्यकताएं
• हैक उतना ही बुरा है, जितना बुरा नहीं, जितना मैंने अपनी लाइब्रेरी में इस्तेमाल किया था।

जहां तक ​​मेरा सवाल है, यह अच्छी तरह से करना असंभव है।

देखने योग्य घटनाएं और भी बदतर हैं, इतने सारे सामुदायिक समाधान नहीं हैं, उन्हें आमतौर पर अतिरिक्त बिल्ड चरण की आवश्यकता होती है (जो कुछ मामलों में मोनोरेपो सेटअप में एसएसआर को तोड़ देता है) और उसके ऊपर भी हैक (यदि आप उदाहरण के लिए क्लास एक्सटेंशन का उपयोग कर रहे हैं) जीवनचक्र देखने योग्य घटनाएँ प्राप्त करें, क्योंकि हे, कोणीय उस मूल रूप से समर्थन नहीं करता है) https://github.com/typebytes/ngx-template-streams/issues/8

जीवनचक्र की घटनाएं यकीनन "सबसे आसान" होती हैं, लेकिन फिर भी उन्हें क्लास एक्सटेंशन या कस्टम डेकोरेटर पर निर्भर रहना पड़ता है, जिनमें से कोई भी आदर्श नहीं है।

@fxck जहां तक ​​​​मुझे पता है कि माता-पिता वर्ग (ईघ) या उपयोगकर्ता को अपने स्वयं के नष्ट जीवन चक्र घटना (इससे भी बदतर) से कॉल करने के बिना जीवन चक्र घटना सदस्यता को साफ करना संभव नहीं है।

जीवनचक्र की घटनाएं यकीनन "सबसे आसान" होती हैं, लेकिन फिर भी उन्हें क्लास एक्सटेंशन या कस्टम डेकोरेटर पर निर्भर रहना पड़ता है, जिनमें से कोई भी आदर्श नहीं है।

मैंने कस्टम डेकोरेटर्स के साथ भी जीवनचक्र की घटनाओं (इसे प्रतिक्रियाशील बनाने के लिए) को लागू करने की कोशिश की थी और यह एक दर्द है। ~ बिना क्लास एक्सटेंशन के मुझे नहीं पता कि यह 100 हैक्स के बिना संभव है या नहीं। कोणीय को विस्तारित करने की उपयोगकर्ता-संभावना अब तक बहुत खराब है और इसे करने के लिए यह हैक्स या बहुत सारे बॉयलरप्लेट पर निर्भर करता है।

@ tonivj5 यदि घटक सुविधा सार्वजनिक एपीआई होगी तो क्या आप इसे विरासत के बिना जीवन चक्र को लागू करने के संभावित तरीके के रूप में देखते हैं?

@ntziolis हाह मज़ेदार आपको सुविधाओं का उल्लेख करना चाहिए, मैं वास्तव में ngx-sub-form के जीवनचक्र भाग पर काम कर रहा हूँ और सुविधाएँ कुछ ऐसा है जो मुझे लगता है कि मदद करेगा। इस बीच, आइवी के साथ कंपोनेंट फैक्ट्री को पैच करना बहुत संभव है। मैं इसे एनजीएक्स-सब-फॉर्म के बाहर बहुत उपयोगी होने के रूप में देखता हूं, इसलिए मुझे लगता है कि मैं इस तर्क को एक अलग काम में विभाजित कर दूंगा

@ntziolis इस बिंदु पर मैं अनिश्चित हूं कि क्या हम कभी आइवी वादों को वास्तव में वितरित होते देखेंगे।

क्या आपने कोणीय प्रभाव की जाँच की है? (एनजीआरएक्स/इफेक्ट्स नहीं) 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 के कंपोजिशन एपीआई पर आधारित कंपोजिशन/हुक मॉडल पेश करेगा।
मुझे लगता है कि प्रतिक्रियाशीलता के साथ काम करने के लिए कोणीय के लिए यह वास्तव में अगला कदम है।

@mgchev

यह कोई निर्णय नहीं है जिसे हम जल्दी करना चाहते हैं, विशेष रूप से यह देखते हुए कि अच्छी तरह से स्थापित समाधान/सामुदायिक समाधान हैं

बस जिज्ञासु, हम कौन हैं और कितने Googler सक्रिय रूप से कोणीय निर्णय लेने की प्रक्रिया में योगदान करते हैं?

आप संकेत करते हैं कि यह एक निर्णय नहीं है जिसे जल्दी किया जाना चाहिए, लेकिन मैं सोच रहा हूं कि जल्दबाजी में आपकी परिभाषा क्या है? क्या यह उन लोगों में से एक है जो उस पर 'फिक्स्ड बाय आइवी' टैग थप्पड़ मारते हैं और इसे तब तक अनदेखा करते हैं जब तक कि अधिक डेवलपर्स शोर करना शुरू नहीं करते हैं? क्या किसी प्रतिक्रियाशील कार्य के लिए कोई लक्षित संस्करण दिमाग में है या क्या अन्य नए कंपाइलर संस्करण पहले जारी किए जाने हैं?

क्या यह तथ्य कि किसी भी समय आम तौर पर 2500 खुले मुद्दे होते हैं, आंतरिक चर्चाओं में कभी सामने आते हैं?

@ntziolis , जैसा कि @zakhenry ने कहा, मुझे लगता है कि features मदद करेगा

@ntziolis मैंने जीवनचक्र के साथ अन्य प्रयास किए हैं और मेरे पास एक कार्यशील POC है (बिना वर्ग विस्तार के और न ही जीवनचक्र इंटरफेस लागू करता है)। यह निजी एपीआई पर निर्भर करता है (: विस्मयादिबोधक :)

@ tonivj5 हाँ मुझे आपका पढ़ने का मौका नहीं मिला है, लेकिन मैंने लगभग अपना समाधान भी जारी कर दिया है :) https://github.com/cloudnc/ngx-observable-lifecycle

जिस काम पर मैं काम कर रहा हूं, उसके साथ विचार यह है कि एक सामान्य आधार हो जिसके लिए अन्य libs अपने स्वयं के जीवन-चक्र जागरूक कार्यक्षमता बनाने के लिए हुक कर सकें। यह इस तरह काम करने में सक्षम होना चाहिए कि यदि एक ही हुक तक पहुंच के लिए कई फ़ंक्शन हैं, तो घटक डीफ़ पर सजाया गया केवल एक हुक है।

मेरे पास यह सब काम कर रहा है, बस सीआई और यूनिट परीक्षणों को सॉर्ट करने की जरूरत है।

क्या यह तथ्य कि किसी भी समय आम तौर पर 2500 खुले मुद्दे होते हैं, आंतरिक चर्चाओं में कभी सामने आते हैं?

योग्य, 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 से बहुत अधिक अनदेखा किया गया है।

एक एंगुलर टीम का सदस्य समझा रहा था कि यह अभी भी सिर्फ 5 दिन पहले क्यों खुला है

@ etay2000 कुछ निर्णय कुछ समय कठिन होते हैं क्योंकि वे पूरी परियोजना के विकास को प्रभावित करते हैं और यह स्वीकार्य है डेवलपर्स यह महसूस कर सकते हैं कि वे निकट भविष्य में समय बीतने के साथ इस सुविधा पर भरोसा नहीं कर सकते हैं, लेकिन अगर कोई संभावना है तो इसे समय से पहले क्यों मारें? मेरा मानना ​​है कि सबसे आसान काम प्रस्ताव को अस्वीकार करना और मुद्दे को बंद करना था लेकिन ऐसा किसी कारण से नहीं हुआ।

@बीमन

एक एंगुलर टीम का सदस्य समझा रहा था कि यह अभी भी सिर्फ 5 दिन पहले क्यों खुला है, इसलिए आप सही नहीं हैं।

आप वास्तव में उन थम्स डाउन इमोजीस को पसंद करते हैं? हालांकि यह वास्तव में एक स्पष्टीकरण था? 4+ वर्षों के बाद उन्होंने कहा कि वे निर्णय में जल्दबाजी नहीं करना चाहते हैं।

@अगलाज़ीस
मैं मानता हूं कि कुछ निर्णय कठिन होते हैं, लेकिन उन कठोर निर्णयों को टालने के लिए एक स्वीकार्य समय सीमा क्या मानी जानी चाहिए? सभी 2855 खुले मुद्दों में ये कड़े फैसले शामिल नहीं हैं, फिर भी उनमें से बहुत कुछ काफी समय से आसपास भी हैं।

@ etay2000 इसे स्वीकार करें या नहीं यह खुला स्रोत है जो लोग मुद्दों को खोलते हैं वे अनुरक्षकों की तुलना में बहुत अधिक हैं। उदाहरण के लिए टाइपस्क्रिप्ट प्रोजेक्ट में लगभग दोगुने मुद्दे खुले हैं और एक अन्य प्रस्ताव जो मैंने वहां किया था, उसमें भी काफी समय लगा। मुझे कोई आपत्ति नहीं है क्योंकि चर्चा के बाद से कई विकल्प सामने आए जो कि सुविधा के रूप में फैंसी नहीं हैं, लेकिन कई अन्य दृष्टिकोणों को देखने में कामयाब रहे

@agalazis आप सही हैं, मुझे लगता है कि मैं (गलत तरीके से) Google द्वारा बनाए गए ओपन सोर्स प्रोजेक्ट से एक छोटी परियोजना से अधिक की अपेक्षा करता हूं।

@beeman यहां थम्स डाउन इमोजी डालें: -------->

@ etay2000 आपको हमेशा याद रखना चाहिए कि ऐसा प्रत्येक महत्वपूर्ण निर्णय सैकड़ों हजारों चीजों, परियोजनाओं और लोगों को प्रभावित करता है। और जो और भी महत्वपूर्ण है, एक सही निर्णय नहीं है और सार्वजनिक एपीआई पेश करना, जो उसके बाद थोड़े समय में कुछ ब्रेकिंग बदलाव लाएगा, वह सिर्फ एक दुःस्वप्न है। आप लगभग प्रत्येक पीआर पर देख सकते हैं कि प्रत्येक चरण की समीक्षा कैसे की जाती है, और यदि सही नहीं है, तो यह बस प्रतीक्षा करता है, सप्ताह, महीने या साल भी।

@agalazis आप सही हैं, मुझे लगता है कि मैं (गलत तरीके से) Google द्वारा बनाए गए ओपन सोर्स प्रोजेक्ट से एक छोटी परियोजना से अधिक की अपेक्षा करता हूं।

मुझे नहीं पता, जाओ और डार्ट भी देखो। Google वास्तव में आधे दशक के लिए बेहद लोकप्रिय सामुदायिक अनुरोधों को अनदेखा करने के लिए बहुत प्रसिद्ध है: डी आम तौर पर भाषाओं/ढांचे/आदि के लिए उनका दृष्टिकोण। बहुत रूढ़िवादी है । आप नई भाषाओं और विचारों को सामने आते हुए देख सकते हैं जो क्षेत्रों में क्रांति लाते हैं और Google अभी भी उन्हें वर्षों से नहीं अपना रहा है, उदाहरण के लिए डार्ट से बहुत पहले शून्य सुरक्षा हिट कोटलिन, टाइपस्क्रिप्ट और स्काला। मुझे लगता है कि इस तरह के दृष्टिकोण के फायदे और नुकसान हैं, लेकिन मेरे लिए कम से कम मैं Google द्वारा विकसित चीजों से बचने के लिए जहां संभव हो, क्योंकि यह वास्तव में मेरे लोकाचार के साथ फिट नहीं है।

(इसके लिए सभी को खेद है, लेकिन मुझे यह करना होगा।)

@beeman यहां थम्स डाउन इमोजी डालें: -------->

@ etay2000 मुझे नहीं पता कि इस तरह की टिप्पणी कैसे मदद करती है, अगर यहां आचरण का उल्लंघन नहीं है। मुझे पूरा यकीन है कि हर कोई अंगूठा लगाना जानता है, तो व्यंग्य का क्या मतलब है?

एक अनुस्मारक के रूप में, किसी को कोणीय का उपयोग करने के लिए मजबूर नहीं किया जाता है, आप एक और ढांचा खोजने की कोशिश कर सकते हैं जहां लोग आपको अधिक खुश करते हैं।

@brunojcm मुझे लगता है कि पार्टी अब खत्म हो गई है कि टिप्पणी पुलिस यहां है। मुद्दा यह था कि उसने मेरी अन्य सभी टिप्पणियों को अस्वीकार कर दिया था, लेकिन मुझे नहीं पता था कि कटाक्ष आचरण का उल्लंघन था।

एक अनुस्मारक के रूप में, किसी को कोणीय का उपयोग करने के लिए मजबूर नहीं किया जाता है, आप एक और ढांचा खोजने की कोशिश कर सकते हैं जहां लोग आपको अधिक खुश करते हैं।

जिस तरह से मैं वास्तव में इसका जवाब देना चाहता हूं वह निश्चित रूप से यहां की आचार संहिता का उल्लंघन करेगा।

मेरा काम हो गया, हर कोई अपनी नियमित रूप से निर्धारित प्रोग्रामिंग पर लौट सकता है। मैं अगले 4-5 वर्षों में वापस आकर देखूंगा कि चीजें कैसे निकलीं।

@tonivj5 @zakhenry यह सुनकर बहुत अच्छा लगा कि यह एक अवसर हो सकता है।

@mgchev मैं समझता हूं कि यह प्रारंभिक चर्चा भी नहीं है, लेकिन आपके विचार सुनना अच्छा लगेगा:

• प्रतिक्रियाशील कोर + गैर प्रतिक्रियाशील विस्तार बनाम दूसरी तरफ।
• और इस मुद्दे के लिए और अधिक विशिष्ट है कि फीचर एपीआई को किसी भी तरह से उजागर करने का कोई वास्तविक मौका है।
  
  
  
  • भले ही यह भविष्य में ब्रेकिंग परिवर्तनों की चेतावनी के साथ ही हो, जब तक कि सामान्य func अभी भी सुलभ हो।
  
  
  • जैसा कि @zakhenry ने जीवनचक्र की घटनाओं के लिए किया है, मुझे शीर्ष पर एपीआई बनाने वाली एक या बहुत सीमित संख्या में परियोजनाएं दिखाई देती हैं जिनका उपयोग दूसरों द्वारा सीधे इन एपिस तक पहुंचने के बजाय किया जा सकता है
  
  
  • फिर आप इन रैपर टीम के साथ काम कर सकते हैं ताकि उन्हें आने वाले ब्रेकिंग परिवर्तनों के बारे में जल्द ही बता सकें (इसलिए प्रतिक्रियाशील एक्सटेंशन पर आपके सुझाव के समान ही)
  
  

मुझे लगता है कि आप लोग सीधे Vue 3.0 के रिएक्टिव मॉड्यूल (रेफरी या रिएक्टिव) को लागू कर सकते हैं और इस मुद्दे को हल कर सकते हैं।

@AnonymousArthur यदि आप पैकेज @vue/reactivity बारे में बात कर रहे हैं तो यह पूरी तरह से असंबंधित है जो हम यहां चर्चा कर रहे हैं क्योंकि यह गुणों को प्रतिक्रियाशीलता प्रदान कर रहा है और इसका प्रतिक्रियाशील धाराओं से कोई लेना-देना नहीं है (जो कि RxJs है)।

@ गुंड हाँ, मैं सहमत हूँ। हालांकि इस वार्तालाप में काफी लंबा समय लगता है (4.5 वर्ष) और अभी तक समाप्त नहीं हुआ है, इसलिए मैं बहुत जल्दी एक विचार (शायद नहीं) पॉप अप करता हूं जिसके लिए सदस्यता/सदस्यता समाप्त करना या ngOnChange हैंडलर लिखना नहीं चाहता। आरएक्सजेएस प्रतिक्रियाशीलता सुविधा प्रदान करता है और यह वार्तालाप (यह सब कुछ नहीं पढ़ा) अवलोकन योग्य के साथ इनपुट मूल्य को एक वाक्यात्मक चीनी के रूप में लपेटने के बारे में बात कर रहा है ताकि इसे देखने योग्य बनाया जा सके और मुझे लगता है कि यह एक शानदार विचार है।

मुझे लगता है कि यह विचार वास्तव में उपयोगी है और शुरुआत में @robwormald का प्रोटोटाइप बहुत अच्छा लग रहा है, लेकिन मुझे लगता है कि इसने संभावित लाभों को कम कर दिया है और प्रभाव को कितना कम करने की आवश्यकता होगी।

मुझे कुछ कमियों को ठीक करने के लिए उस समाधान पर थोड़ा सा सुझाव देना चाहिए, लेकिन मूल रूप से एक ही दृष्टिकोण:

कोणीय परिभाषित करेगा एक डेकोरेटर @OInput() और एक प्रकार EventReceiver<T> कि फैली Observable<T> लेकिन यह भी कहते हैं एक .value गेटर (जैसे BehaviorSubject<T> )।

मूल घटक पक्ष पर , जैसा कि @robwormald के उदाहरण में है, कुछ भी नहीं बदलता है। यदि आप वहां एक अवलोकन योग्य मान पास करना चाहते हैं, तो आपको अभी भी | 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`
    }
  }
}

अब यहाँ इस दृष्टिकोण के लाभ हैं, जो मुझे लगता है कि थोड़े कम बिके थे:

• यदि वांछित हो, तो यह माता-पिता और बच्चे दोनों घटकों में प्रभावी ढंग से पूरी तरह प्रतिक्रियाशील डिजाइन सक्षम बनाता है।
• मूल घटकों में, एंगुलर के मौजूदा इनपुट डिज़ाइन पैटर्न को बनाए रखता है, ताकि कोई भी घटक इसमें मजबूर न हो या इसके चारों ओर डिज़ाइन न करना पड़े।
• माता-पिता और बच्चे के संदर्भ पूरी तरह से स्वतंत्र हैं, माता-पिता को यह जानने की आवश्यकता नहीं है कि क्या बच्चा Input या OInput , इस परिवर्तन से क्रॉस-कंपोनेंट बग के जोखिम को समाप्त करता है।
• यदि वांछित है, तो एक एकल बच्चे के घटक को आंशिक रूप से माइग्रेट करना अपेक्षाकृत आसान है, क्योंकि कोणीय इन सभी को पहले की तरह मौजूदा जीवनचक्र की घटनाओं से जोड़े रखता है।
• चूंकि कोणीय इस सुविधा को लागू करता है, सभी EventReceiver s में आंतरिक रूप से takeUntil(ngOnDestroyEvent) माध्यम से एक पाइप शामिल हो सकता है, इसलिए अधिकांश मामलों को उनके घटक के नष्ट होने पर सदस्यता समाप्त करने की याद रखने की आवश्यकता नहीं होगी, क्योंकि ये वेधशालाएं स्वचालित रूप से पूर्ण हो जाएंगी . (याय कम मेमोरी लीक!)
• इस चाइल्ड कंपोनेंट में, यह आज के @Output() के पैटर्न के समान दिखता है और कार्य करता है, इसलिए कुछ अच्छी समानता और उन्हें अच्छी तरह से जोड़ने की संभावित क्षमता देता है।
  
  
  
  • साइड नोट: फॉलो-अप के रूप में, मुझे लगता है कि @InputOutput() का प्रस्ताव देना अच्छा होगा जो दो-तरफा बाध्यकारी के लिए व्यवहार को जोड़ने के लिए ReplaySubject<T>(1) का उपयोग करता है। लेकिन इसकी अपनी चुनौतियां और तर्क हैं, इसलिए मैं यहां इसका प्रस्ताव नहीं कर रहा हूं।
  
  
• यह काम करने के लिए कोई नए प्रकार का बॉयलरप्लेट नहीं है, यह @Output() जितना आसान है।
• कोणीय मूल रूप से switch() में परिवर्तन से अधिक होगा Observable माता-पिता द्वारा इनपुट किया जा रहा है, इसलिए कमजोर प्रतिक्रियाशील पैटर्न जैसे कि एक ही अवलोकन योग्य उदाहरण के साथ चिपके नहीं होने के लिए विशेष-आवरण की आवश्यकता नहीं है ( switch() एड) चाइल्ड कंपोनेंट्स में।

मेरे द्वारा चुने गए OInput नाम के बारे में साइड नोट: जाहिर है कि यह बहस के लिए खुला है। हालाँकि, मुझे व्यक्तिगत रूप से वह नाम पसंद है क्योंकि यह "अवलोकन योग्य इनपुट" के लिए छोटा है और क्योंकि यह "आउटपुट" जैसा दिखता है जो कि यह दर्पण है।

प्रिय कोणीय टीम। कृपया हमें 2020 में आगे देखने के लिए कुछ दें :-)

इसके अलावा @jcomputer समाधान वही है जो मैं चाहता हूं। एक अलग डेकोरेटर नाम का बहुत बड़ा प्रशंसक नहीं है, लेकिन हो सकता है कि @ViewChild में { read } समान पैरामीटर जोड़ना संभव हो। उदाहरण:

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

2020 में आगे देखने के लिए बहुत कुछ है। :D बेशक यह (और ऊपर सूचीबद्ध अन्य मुद्दे) एक बग के रूप में गिना जाता है और एक नई सुविधा नहीं है। :)

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

@fxck मेरी यहां एक अलोकप्रिय राय हो सकती है, लेकिन ईमानदारी से अगर 2020 वर्ष है, तो कोणीय टीम ने फॉर्म, राउटर आदि पर बहुत सारे बग को खत्म करने का फैसला किया है, मैं 0 सुविधाओं के साथ बिल्कुल भी पागल नहीं होगा: श्रग:।

उस ने कहा, शायद यह हाल की घटनाओं से संबंधित एक मुद्दा है और मुझे लगता है कि इस समय कोणीय टीम में जटिल चीजें चल रही हैं। मुझे आशा है कि वे उन महान लोगों को रखने का प्रबंधन करेंगे जो अब तक सक्रिय रूप से कोणीय का निर्माण कर रहे हैं: दिल:। लेकिन यह एक और कहानी है।

ऑफ टॉपिक के लिए खेद है। उड़ जाना

@ maxime1992 यह मेरे लिए भी ठीक रहेगा।

मेरी यहां एक अलोकप्रिय राय हो सकती है, लेकिन ईमानदारी से अगर 2020 साल है तो एंगुलर टीम ने फॉर्म, राउटर आदि पर बहुत सारे बग को खत्म करने का फैसला किया है, मैं 0 सुविधाओं के साथ बिल्कुल भी पागल नहीं होता

लेकिन जो बात मुझे परेशान करती है, वह यह है कि एंगुलर टीम के अंदर दीर्घकालिक अस्वस्थ एचआर प्रक्रियाएं हैं जो हमें प्रभावित करती हैं, हमारे बिना। खासकर इस क्षेत्र में बड़े पैमाने पर निवेश की दृष्टि से।

मेरे पीओवी से, वे मुख्य रूप से बीओटी के माध्यम से उन्हें बंद करके मुद्दों को ठीक कर रहे हैं - बिना प्रतिक्रिया के छोड़कर और बॉट द्वारा बंद कर रहे हैं।, ..: - /

@ montella1507 नहीं, यह बिल्कुल सच नहीं है। बॉट केवल पहले से बंद मुद्दों को लॉक करता है। और यह पहले से ही सच है कि एंगुलर टीम के सदस्यों के पास कई मामलों में बहुत प्रयास होते हैं जब वे यह समझाने की कोशिश करते हैं कि नए मुद्दों को दर्ज करने पर वर्णन करने और पुन: पेश करने के लिए क्या आवश्यक है। यह एक बहुत ही समय लेने वाली प्रक्रिया है और इसके लिए बहुत अधिक धैर्य की आवश्यकता होती है।

उन लोगों के लिए, जो एंगुलर टीम को दोष दे रहे हैं और जल्दी से सुविधाएँ और परिवर्तन नहीं मिलने की शिकायत कर रहे हैं:
मैं आपका दर्द समझता हूं। मैं इस सुविधा को एंगुलर में भी देखना पसंद करूंगा, मैं बहुत सी चीजें भी बदलूंगा जो मुझे व्यक्तिगत रूप से पसंद नहीं हैं।

लेकिन हो सकता है कि एंगुलर का मतलब एक ऐसा ढांचा नहीं है जिसमें सभी चमकदार नए खिलौने हों और प्रत्येक रिलीज में बहुत सारी सुविधाएँ हों। और यह मेरे साथ ठीक है। ऐसे ढांचे होने चाहिए जो अधिक उद्यम-स्तर का लक्ष्य रखते हों और स्थिरता और विश्वसनीयता प्रदान करते हों। और कोणीय यह ठीक करता है, कम से कम मेरे अनुभव से।

मुझे Vue ज्यादा पसंद है। मैं इसे अपनी निजी परियोजनाओं के लिए उपयोग करता हूं। लेकिन मेरी परियोजनाएं जल्दी पुरानी लगने लगती हैं और मुझे एक नई घटक शैली में अपग्रेड करने का आग्रह महसूस होता है। साथ ही, जब मैं अपग्रेड करता हूं, तो चीजें हमेशा अजीब तरीके से टूटती हैं। पारिस्थितिकी तंत्र को भी अनुकूलता बनाए रखने में कठिन समय लगता है।

इसके विपरीत कोणीय परिपक्व और स्थिर होता है। यह अक्सर नहीं बदलता है, लेकिन इसका मतलब यह भी है कि जब आप अपनी निर्भरता को अद्यतन रखते हैं, तो आपके पास अपने कोड को फिर से तैयार करने में कम काम होता है, और यह वाणिज्यिक उत्पादों के लिए मूल्यवान है। आपका ज्ञान भी लंबे समय तक प्रासंगिक रहता है, और बनाए रखने की कोशिश करने के बजाय, आप गहराई में जा सकते हैं।

@manfreed लोग चमकदार नए खिलौने की मांग नहीं कर रहे हैं, हालांकि वे ढांचे के डिजाइन में एक निरीक्षण में सुधार के लिए कह रहे हैं। वर्तमान में हमें कभी-कभी ऑब्जर्वेबल का उपयोग करने के लिए मजबूर किया जाता है, और कभी-कभी मुख्य कार्यक्षमता के लिए ऑब्जर्वेबल्स का उपयोग करने में असमर्थ होते हैं। वेधशालाओं से नफरत करने वाले निराश हैं। वेधशालाओं से प्यार करने वाले निराश हैं। और हम में से बहुत से लोग उस स्थिति से इतने निराश थे कि हमने हार मान ली और अन्य ढांचे में चले गए। मैं एंगुलर का उपयोग जारी रखना पसंद करता, थोड़ी सी दिशा और यह वास्तव में एक महान ढांचा हो सकता था। लेकिन ब्लॉग कुप्रबंधन के बारे में पोस्ट करता है, व्यावहारिकता की कमी, निरीक्षण, वे सभी निष्पक्ष रूप से निराशाजनक हैं।

@insidewhy धैर्य रखें, सड़क पर हमेशा कुछ चोटियाँ और घाटियाँ होती हैं, लेकिन इसका मतलब यह नहीं है कि दूसरों के पास भी नहीं है या कुछ प्रमुख गलतियाँ हैं। इसका मतलब केवल इतना है कि चीजें वास्तव में जितनी तेजी से और प्रभावी ढंग से आगे बढ़ सकती हैं, उससे कहीं अधिक तेजी से आगे बढ़ सकती हैं।

रोडमैप में किसी विशेष उपरोक्त मुद्दे का कोई उल्लेख नहीं था, जो मुझे दुखद लगा, मैं वास्तव में उम्मीद कर रहा था कि कुछ होगा, उल्लेख, पावती ... यह चर्चा कोणीय कलह पर हुई -

मैंने उन्हें संदेह का लाभ दिया और उस मध्यम रोडमैप लेख की टिप्पणी में पूछा, मिंको की प्रतिक्रिया:

उन्होंने कुछ महीने पहले यहां जो कहा था, उसे उन्होंने बहुत दोहराया, इनमें से कोई भी आरएक्सजे से संबंधित मुद्दों को जल्द ही ठीक नहीं किया जा रहा है, हां।

मैं अपनी बात मनवाने की कोशिश कर रहा हूं, लेकिन मुझे एक आखिरी बार कोशिश करने दो.. मैं कोणीय को

• देखने योग्य जीवनचक्र
• देखने योग्य इनपुट
• देखने योग्य टेम्पलेट ईवेंट

इनमें से कोई भी पिछड़ी संगतता को तोड़ता नहीं है

@fxck : +1: निश्चित रूप से।

• देखने योग्य जीवनचक्र
• देखने योग्य इनपुट
• देखने योग्य टेम्पलेट ईवेंट

@insidewhy धैर्य रखें

लोगों से 5 साल से अधिक धैर्य के लिए पूछना इतना व्यावहारिक नहीं है जब दौड़ में बहुत सारे प्रतियोगी भाग रहे हों और सभी ध्यान आकर्षित करने के लिए दौड़ रहे हों।

@ अंदर क्यों इसका मतलब आम तौर पर था।

@fxck Google के पास (मेरी अंतिम गणना के अनुसार) 4000 ऐप्स कोणीय और प्रकृति में अत्यधिक समान हैं, इन परियोजनाओं और सहकर्मी समीक्षा के बीच स्विच करना (मैं कल्पना करता हूं) बहुत सहज है। यहां तक ​​​​कि मेरी कंपनी में, एंगुलर के बड़े लाभों में से एक यह है कि मेरे बिना किसी अन्य टीम के कोड की समीक्षा किए बिना, मुझे पता है कि यह ऐसी स्थिति में है जहां एक सहकर्मी समीक्षा पूरी जांच को बंद नहीं करती है।

अब मान लें कि हम इनमें से प्रत्येक सहायक RxJS शॉर्टकट को कोर में लागू करते हैं, तब क्या होता है? यह संभव है कि हम एक प्रक्रियात्मक पूर्वाग्रह बनाम एक प्रतिक्रियाशील पूर्वाग्रह के साथ समाप्त हो जाएंगे, बिना स्पष्ट मार्गदर्शन के जो किसी विशेष मामले के लिए पूर्वाग्रह सही है। अब तक की चर्चाओं को पढ़ने के बाद, कोणीय टीम का जवाब "यह एक कम प्राथमिकता है" नहीं है (जैसा कि आपके प्रवाह से पता चलता है), यह वास्तव में "हम पक्ष नहीं लेना चाहते" के करीब लगता है।

यहां एंगुलर समुदाय में उन्नत आरएक्सजेएस उपयोगकर्ता एक मुखर अल्पसंख्यक हैं, क्योंकि टाइपस्क्रिप्ट, डीआई, टेम्प्लेटिंग, और एंगुलर के विभिन्न पुस्तकालयों को टटोलने के बाद, आपके पास प्रतिदिन फ्रेमवर्क का उपयोग करने के लिए लगभग 1 वर्ष है, और अब आप तैयार हैं RxJS को पूरी तरह से समझने के लिए। वरिष्ठ स्तर के लोगों को सहकर्मी समीक्षाओं में प्रतिक्रियाशीलता पूर्वाग्रहों के साथ जाने देना लोगों को और भी अधिक विमुख कर देता है, और यह वस्तुतः आखिरी चीज है जिसे कोणीय की जरूरत है।

कोणीय का लक्ष्य (जैसा कि मैं इसे देखता हूं) "एक्स तकनीक का उपयोग करें क्योंकि यह बेहतर है, यहां एक छोटा उपन्यास क्यों है" से बातचीत को कम करना और ट्यून करना है और व्यावसायिक तर्क के बारे में सहकर्मी समीक्षाओं में बातचीत को लागू करना है। क्या हम वास्तव में अपने घटकों को "उन्नत" कोणीय और "शुरुआती" कोणीय के बीच पहले से कहीं अधिक स्तरीकृत करना चाहते हैं?

यह तर्कसंगत रूप से वही तर्क है जो हमने राज्य प्रबंधन के साथ देखा है, कोणीय को कई संभावित पैटर्नों से क्यों निर्धारित करना चाहिए कि कौन सा सही है?

मैं सिर्फ आपके लिए कोणीय टीम के सदस्यों में से एक को उद्धृत करता हूं।

वैसे, इनमें से किसी के बारे में कुछ भी उन्नत नहीं है (अवलोकन योग्य जीवनचक्र, अवलोकन योग्य इनपुट, अवलोकन योग्य टेम्पलेट ईवेंट)।

यह तर्कसंगत रूप से वही तर्क है जो हमने राज्य प्रबंधन के साथ देखा है, कोणीय को कई संभावित पैटर्नों से क्यों निर्धारित करना चाहिए कि कौन सा सही है?

राज्य प्रबंधन और इसके बीच का अंतर यह है कि राज्य प्रबंधन समुदाय द्वारा किया जा सकता है, कोणीय कोर के अंदर इसे रोकने वाला कुछ भी नहीं है। दुर्भाग्य से कोणीय उन तीनों में से किसी को भी (संपादित करें: टिप्पणी करने के लिए सही लिंक)

मैं समुदाय के लिए जितना संभव हो उतना छोड़ने के लिए तहे दिल से हूं, जिसमें फॉर्म, राउटर, फ्लेक्स-लेआउट, यूनिवर्सल आदि जैसे पैकेज शामिल हैं, एंगुलर टीम को कोर, क्ली और घटकों पर ध्यान केंद्रित करने दें। लेकिन इसके लिए उन्हें समुदाय को पर्याप्त प्रवेश बिंदु प्रदान करने की आवश्यकता है, उदाहरण के लिए उच्च आदेश घटकों की अनुमति देना। लेकिन वे वर्षों तक ऐसा करने में विफल रहे (अक्सर यह कहते हुए कि आइवी को पहले जरूरत है) और अब अपनी योजनाओं में इस बारे में बात करने / स्वीकार करने से इनकार करते हैं।

अब तक की चर्चाओं को पढ़ने के बाद, कोणीय टीम का जवाब "यह एक कम प्राथमिकता है" नहीं है (जैसा कि आपके प्रवाह से पता चलता है), यह वास्तव में "हम पक्ष नहीं लेना चाहते" के करीब लगता है।

हाँ और यह डरावना है।

@fxck मुझे बहुत लगता है कि हम इस बारे में एक ही पृष्ठ पर हैं। मैं कहूंगा कि हर बार जब मैं मंचों पर या अपने साथी इंजीनियरों के साथ आरएक्सजेएस लाता हूं, तो अधिकांश उद्धरण मैं उद्धृत कर सकता हूं "मैं अभी भी इसे समझ नहीं पा रहा हूं, मैं और कैसे सीखूं?" या "मुझे यह भारी लगता है कि कितने ऑपरेटर हैं।" या "मुझे इस पीआर में इस पाइपलाइन को पढ़ने में परेशानी हो रही है"। प्रत्येक 1 अच्छी तरह से वाकिफ RxJS इंजीनियर के लिए, 15 अच्छी तरह से वाकिफ एंगुलर इंजीनियर हैं जिनकी भौंहें हैं।

हाँ और यह डरावना है।

यह थोड़ा अतिशयोक्तिपूर्ण है, हमें इन पैटर्नों को रखने के लिए @angular/core आवश्यकता नहीं है, वास्तव में इस मुद्दे के भीतर कई प्रकार और पुस्तकालय हैं जिनका उपयोग आज किसी भी परियोजना पर किया जा सकता है। पहले उल्लेख किए गए विकल्पों का उपयोग करने में एकमात्र मितव्ययिता यह है कि भविष्य में, आपको संभवतः @angular/core प्रतिस्थापन के रूप में कोणीय द्वारा प्रदान की जाने वाली किसी चीज़ पर माइग्रेट करना पड़ सकता है। क्या वास्तव में हमारे लिए npm uninstall और सभी टाइपप्रति त्रुटियों को ठीक करना इतना कठिन है?

प्रमुख वास्तुशिल्प निर्णय, जो सभी कोणीय परियोजनाओं को प्रभावित करते हैं, और यदि वे काम नहीं करते हैं, तो दस्तावेज़ और माइग्रेट करने के लिए असंख्य घंटों की आवश्यकता होती है, जो मेरे लिए और भी भयावह लगता है, और हम पहले भी वहां रहे हैं:

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

यह थोड़ा अतिशयोक्तिपूर्ण है, हमें इन पैटर्नों को रखने के लिए @ कोणीय/कोर की "आवश्यकता" नहीं है, वास्तव में इस मुद्दे के भीतर कई प्रकार और पुस्तकालय हैं जिनका उपयोग आज किसी भी परियोजना पर किया जा सकता है।

नहीं, वास्तव में नहीं, प्रत्येक समाधान के लिए हैक्स की आवश्यकता होती है या आंतरिक एपीआई पर भरोसा करते हैं जो बदल सकते हैं। यह पूरी बात है .. पढ़ें कि @insidewhy ने https://github.com/angular/angular/issues/5689#issuecomment -630661006 और जो मैंने नीचे कहा था, उसे टेम्प्लेट इवेंट स्ट्रीम के बारे में पढ़ें।

// टिप्पणी करने के लिए सही लिंक संपादित करें

नहीं, वास्तव में नहीं, प्रत्येक समाधान के लिए हैक्स की आवश्यकता होती है या आंतरिक एपीआई पर भरोसा करते हैं जो बदल सकते हैं।

समुदाय द्वारा इसे संबोधित करने की अनुमति देने के लिए आपके विचार से कौन से आंतरिक एपीआई या प्रकारों को सार्वजनिक/सामान्य बनाया जाना चाहिए? यदि यह डिज़ाइन एक होल्डिंग पैटर्न में है क्योंकि आगे कोई स्पष्ट रास्ता नहीं है, तो यह पूछना उचित लगता है कि हमें इसी ड्रम को लगातार पीटने के बजाय अपना खुद का डिज़ाइन करने की अनुमति है।

अन्य टिप्पणी पढ़ें @insidewhy उसने इसे कोर के अंदर करने की कोशिश की।

@fxck मैं इसे मूल रूप से लागू करने के प्रयासों के इतिहास पर चर्चा नहीं करने जा रहा हूं या यह मुद्दा 5 वर्षों से कैसे खुला है, अब हमें आंतरिक को खोलने से क्या रोक रहा है ताकि समुदाय को स्वयं एक डिजाइन विकसित करने की अनुमति मिल सके?

यो @insidewhy , मुझे आश्चर्य है कि क्या यह प्रकार की जाँच हैक हैक आपके काम पर निर्भर है। जाहिरा तौर पर यह अब TS 4.0 . का उपयोग करके काम नहीं करता है

संपत्ति 'serviceStackId$' का उपयोग इसके आरंभीकरण से पहले किया जाता है। ts(2729)

यो @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 संशोधित मान

इसलिए मुझे लगता है कि इसे अभी भी काम करना चाहिए, केवल टीएस 4 में संकलक शिकायत करता है क्योंकि यह नहीं पता कि उस सजावटी के अंदर एक मूल्य के साथ get ..

मैं इनपुट प्रोप परिवर्तन को समझने के लिए एक डेकोरेटर का उपयोग कर रहा हूं और इनपुट प्रोप का एक अवलोकन योग्य संस्करण बना रहा हूं। यह कोडसैंडबॉक्स डेमो देखें।

यह इस तरह काम करता है:

// 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 का उपयोग करके इनपुट परिवर्तनों को समझ सकते हैं।

@hankchiutw वह समाधान मेरे @BindObservable डेकोरेटर के समान दिखता है: https://github.com/PSanetra/bind-observable#usage

धन्यवाद @hankchiutw

चूंकि आप 1 के साथ ReplaySubject प्रारंभ कर रहे हैं, इसलिए मैंने इसके बजाय BehaviorSubject का उपयोग करना चुना।
इसके अलावा मैंने सीधे विषय में मूल्य शुरू किया है।

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

    // ...
}

मेरी इच्छा है कि मैं "विषयगत" संपत्ति पर टाइप लिखने से बच सकूं क्योंकि इसे संबंधित संपत्ति से अनुमान लगाने में सक्षम होना चाहिए :( कोई विचार है कि यह कैसे करें?

सपना ऐसा करने में सक्षम होना होगा और स्वचालित रूप से संबंधित विषय प्रोप (मेरे मामले में दुनिया $) को व्यवहार विषय के रूप में बनाना होगाऔर ठीक से प्रारंभ किया गया।

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

    // ...
}

@mparpaillon आपका प्रस्तावित डिज़ाइन बहुत अधिक है कि इसे https://github.com/PSanetra/bind-observable में कैसे किया जाता है
अंतर केवल इतना है कि @BindObservable() डेकोरेटर हुड के नीचे एक रिप्लेसब्जेक्ट का उपयोग करता है। इसलिए यदि आप चाहते हैं कि विषय में प्रारंभिक मान हो, तो आपको बाध्य संपत्ति को स्पष्ट रूप से प्रारंभ करने की भी आवश्यकता है (भले ही यह केवल अपरिभाषित हो क्योंकि यह संभव हो सकता है कि संपत्ति प्रकार अपरिभाषित या शून्य मानों की अनुमति न दे)।

स्टैकब्लिट्ज उदाहरण

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

धन्यवाद @PSanetra लेकिन मैं अपना समाधान पसंद करता हूं (जो वास्तव में हांक समाधान है)

@mparpaillon मैंने दूसरे डेमो में आपके सपने (हा) के लिए कुछ करने की कोशिश की है।

उपयोग की तरह दिखता है

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

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

जहां आप विषयगत प्रोप नाम निर्दिष्ट करना चुन सकते हैं।

हालांकि यह तकनीकी रूप से व्यवहार्य है, मुझे डर है कि डेवलपर्स के लिए संदिग्ध हो सकता है (चूंकि एक नया वर्ग सदस्य अंडरहुड बनाया गया है)।

धन्यवाद @hankchiutw ! ऐसा लगता है कि टाइपस्क्रिप्ट मुझे गिनती $ या myCount $ का उपयोग करने नहीं देता है।

इसके अलावा आप अस्पष्टता के बारे में सही हो सकते हैं... धन्यवाद फिर से

ऐसा लगता है कि टाइपस्क्रिप्ट मुझे गिनती $ या myCount $ का उपयोग करने नहीं देता है।

आपने अपने वर्ग के सदस्यों को "गिनती" और "अन्य गणना" के रूप में घोषित किया है, इसलिए आप "माईकाउंट $" और "गिनती $" तक नहीं पहुंच सकते हैं। वे बस मौजूद नहीं हैं, क्योंकि आपने उन्हें कहीं भी घोषित नहीं किया है।

मुझे पता है... यही बात है। मैं उन्हें डेकोरेटर से घोषित करने का तरीका ढूंढ रहा था। @hankchiutw ने एक समाधान की पेशकश की और मैं बस इतना कह रहा हूं कि यह काम नहीं कर रहा है

@mparpaillon मेरे समाधान पर एक नज़र डालें: https://github.com/Futhark/ngx-observable-input

@ फ़ुथार्क ओह यह गर्म है! धन्यवाद