☰

Angular コンポーネントを多数の入力/出力から単一の構成オブジェクトにリファクタリングする 質問する

tag-icon • tag-icon javascript angular angular-components
Angular コンポーネントを多数の入力/出力から単一の構成オブジェクトにリファクタリングする 質問する

@Input私のコンポーネントは、多くの場合、複数のandプロパティから開始します@Output。プロパティを追加すると、入力として単一の config オブジェクトに切り替える方がすっきりするようです。

たとえば、複数の入力と出力を持つコンポーネントを次に示します。

export class UsingEventEmitter implements OnInit {
    @Input() prop1: number;
    @Output() prop1Change = new EventEmitter<number>();
    @Input() prop2: number;
    @Output() prop2Change = new EventEmitter<number>();

    ngOnInit() {
        // Simulate something that changes prop1
        setTimeout(() => this.prop1Change.emit(this.prop1 + 1));
    }
}

そしてその使用法：

export class AppComponent {
    prop1 = 1;

    onProp1Changed = () => {
        // prop1 has already been reassigned by using the [(prop1)]='prop1' syntax
    }

    prop2 = 2;

    onProp2Changed = () => {
        // prop2 has already been reassigned by using the [(prop2)]='prop2' syntax
    }
}

テンプレート：

<using-event-emitter 
    [(prop1)]='prop1'
    (prop1Change)='onProp1Changed()'
    [(prop2)]='prop2'
    (prop2Change)='onProp2Changed()'>
</using-event-emitter>

プロパティの数が増えると、単一の構成オブジェクトに切り替える方がすっきりするようです。たとえば、単一の構成オブジェクトを受け取るコンポーネントを次に示します。

export class UsingConfig implements OnInit {
    @Input() config;

    ngOnInit() {
        // Simulate something that changes prop1
        setTimeout(() => this.config.onProp1Changed(this.config.prop1 + 1));
    }
}

そしてその使用法：

export class AppComponent {
    config = {
        prop1: 1,

        onProp1Changed(val: number) {
            this.prop1 = val;
        },

        prop2: 2,

        onProp2Changed(val: number) {
            this.prop2 = val;
        }
    };
}

テンプレート：

<using-config [config]='config'></using-config>

これで、ネストされたコンポーネントの複数のレイヤーに config オブジェクト参照を渡すだけで済みます。config を使用するコンポーネントは のようなコールバックを呼び出しconfig.onProp1Changed(...)、config オブジェクトが新しい値の再割り当てを実行します。したがって、依然として一方向のデータ フローがあるようです。さらに、プロパティの追加と削除には中間レイヤーの変更は必要ありません。

複数の入力と出力を持つ代わりに、単一の構成オブジェクトをコンポーネントへの入力として持つことには、何か欠点がありますか? このようなことを避けたり@Output、EventEmitter似たようなことをすると、後で問題が発生する可能性はありますか?

ベストアンサー1

個人的には、4 つ以上の入力と出力が必要だとわかったら、コンポーネントを再度作成するためのアプローチを確認します。おそらく、コンポーネントは 1 つ以上である必要があり、私が何か間違っているのかもしれません。とにかく、たとえそれほど多くの入力と出力が必要であっても、次の理由から 1 つの構成では作成しません。

1- 入力と出力の内部に何があるべきかを知ることは、次のように困難です: (HTML 入力要素とラベルを持つコンポーネントを検討してください)

このコンポーネントを 3 つしか入手しておらず、1 か月または 2 か月後にこのプロジェクトに戻ってくる必要がある場合、または他の誰かがあなたと協力したり、あなたのコードを使用したりすることを想像してみてください。コードを理解するのは本当に困難です。

2- パフォーマンス不足。Angular では、配列やオブジェクトを監視するよりも、単一の変数を監視する方がはるかに安価です。また、最初に示した例を考慮して、常に変化する値とともに、決して変化しない可能性のあるラベルを追跡する必要がある理由についても考えてみましょう。

3- 変数の追跡とデバッグが困難です。Angular 自体にデバッグが難しい紛らわしいエラーが伴うのに、なぜデバッグを困難にする必要があるのでしょうか。間違った入力や出力を 1 つずつ追跡して修正する方が、大量のデータを含む 1 つの構成変数で行うよりも簡単です。

個人的には、コンポーネントをできるだけ小さく分割して、それぞれをテストし、大きなコンポーネントだけではなく、小さなコンポーネントから大きなコンポーネントを作成することを好みます。

アップデート ：この方法は、一度入力して変更のないデータ（ラベルなど）に使用します。

@Component({
selector: 'icon-component',
templateUrl: './icon.component.html',
styleUrls: ['./icon.component.scss'],
inputs: ['name', 'color']
});

export class IconComponent implements OnInit {
 name: any;
 color: any;

 ngOnInit() {
 }
}

HTML:

<icon-component name="fa fa-trash " color="white"></icon-component>

このメソッドを使用すると、Angular はコンポーネント内外の変更を追跡しません。ただし、@input メソッドを使用すると、親コンポーネントで変数が変更されると、コンポーネント内の変更も取得されます。

おすすめ記事