使用 Behaviorsubjects 改变价值观的利弊答案

【问题标题】：Pros and cons of using Behaviorsubjects for changing values使用 Behaviorsubjects 改变价值观的利弊
【发布时间】：2018-06-17 12:48:00
【问题描述】：

我知道您应该将（行为）主题用于可能随时间变化的值。但大多数时候，当我查看其他项目的源代码时，他们使用原始数据类型来更改值。

所以我的问题是，仅使用主题来改变这样的值有什么优点和缺点：

@Component({
    selector: 'app-test',
    template: `
        <div> 
            <div *ngIf="isLoading | async">
                <img src="loading.gif"/>
            </div>

            <div *ngIf="errorCode | async">
                An error occurred. Please try again later.
            </div>

            <ng-container *ngIf="data | async; let jobs">
                <div *ngFor="let job of jobs;">
                    {{ job.title }}
                </div>
            </ng-container>
        </div>
    `
})
export class TestComponent implements OnInit {
    errorCode = new BehaviorSubject<number | null>(null);
    isLoading = new BehaviorSubject<boolean>(true);
    data      = new BehaviorSubject<any>(null);

    constructor(
        public service: TestService,
    ) {}

    public ngOnInit() {
        this.isLoading.next(true);
        this.getData();
    }

    public getData() {
        this.service.getData().subscribe((data)=> {
            this.data.next(data);
            this.isLoading.next(false);
        }, (error: HttpErrorResponse) => {
            this.errorCode.next(error.status);
            this.isLoading.next(false);
        });
    }
}

vs 使用像这样的原始数据类型：

@Component({
    selector: 'app-test',
    template: `
        <div> 
            <div *ngIf="isLoading">
                <img src="loading.gif"/>
            </div>

            <div *ngIf="errorCode">
                An error occurred. Please try again later.
            </div>

            <ng-container *ngIf="data; let jobs">
                <div *ngFor="let job of jobs;">
                    {{ job.title }}
                </div>
            </ng-container>
        </div>
    `
})
export class TestComponent implements OnInit {
    errorCode : number | null = null;
    isLoading : boolean = true;
    data : any = null;

    constructor(
        public service: TestService,
    ) {}

    public ngOnInit() {
        this.isLoading = true;
        this.getData();
    }

    public getData() {
        this.service.getData().subscribe((data)=> {
            this.data = data;
            this.isLoading = false;
        }, (error: HttpErrorResponse) => {
            this.errorCode = error.status;
            this.isLoading = false;
        });
    }
}

很抱歉问了这么一个笼统的问题，但是这个话题让我很难过，我找不到任何确凿的答案

【问题讨论】：

标签： angular behaviorsubject

【解决方案1】：

async 是为方便开发者使用的管道。

一个常见的最佳实践是创建dry组件。这些组件不执行任何业务逻辑，只是呈现一个模板。

您可以在模板中使用async 以使组件尽可能干燥。它基本上是一个在其class 中什么都不做的组件，所有工作都在模板中完成。

干式组件风险低且易于测试。

当您开始混合使用async 管道和组件中的业务逻辑时，它开始变得复杂。我并不是说它不好或错误，但很难找到 stuff | async 和 stuff.next(value) 发生位置之间的联系。

因此，如果您有一个没有逻辑的组件，并且模板使用async，那么它很容易维护，但是如果您在模板中有async，并且该组件正在做很多工作来创建和发出值对于 observables，它变得难以维护。

不在模板中使用async 的一个优点是您可以在调试器中命中断点，并且组件的this 代表其当前状态。如果您有async，您将不知道视图中使用的可观察对象的当前值是什么。

【讨论】：

【解决方案2】：

优点：它允许对组件使用OnPush 策略。

缺点：更复杂，更难理解和测试，由于额外的复杂性，更容易引入错误。

【讨论】：

我不明白这对OnPush 通知有何好处？能否再解释一下原因。我有兴趣了解你的意思。你这里指的是宿主组件还是模板？
OnPush 告诉 Angular，它应该只在组件的输入发生更改或组件处理 dom 事件时对组件运行更改检测。因此，在第二个示例中不会检测到 HTTP 回调对组件所做的更改。他们会在第一个，因为组件的状态实际上并没有改变：新事件由可观察对象发出，异步管道订阅这些更改并确保在发出更改时更新 DOM。跨度>
是的，我同意。我认为您的答案的措辞可以更新。短语“它允许”暗示了某种限制。也许改写为“异步支持组件的 OnPush 策略”
否则会有限制。使用 OnPush 不适用于第二个 sn-p。
第二个 sn-p 不起作用，因为它没有在变化检测器上调用 markForCheck()。我认为这是一个不同的讨论主题。我只是不明白为什么你会使用 observables 来允许你使用 OnPush。无论如何你都可以使用它。两者都不需要使用。

【解决方案3】：

有几点：

优点：

observables 是异步的，因此是非阻塞的。这意味着，当 observable 等待时，可能会处理其他任务。
可能有很多观察者订阅了 observable。一旦数据到达，他们中的任何一个都会收到通知。
毕竟复杂的应用程序会更快。
异步编程已经是最先进的技术，并将在未来继续使用。

缺点：

刚开始有点复杂。
很难测试，有时很可怕。

【讨论】：