В паттерне Angular with Flux «тупые» компоненты должны генерировать события или инициировать действия? - PullRequest
0 голосов
/ 19 сентября 2018

Существует много дискуссий о умных и немых компонентах при использовании шаблона Flux с Angular.

Я закончил тем, что мой умный компонент (скажем ItemsListComponent) "управлял"состояние приложения (фрагмент состояния приложения).Компонент дампа ItemCardComponent:

<div *ngFor="let item of state$.items | async">
  <app-item-card [item]="item" (delete)="handleDelete($event)"></app-item-card>
</div>

My ItemCardComponent получает item в качестве ввода.Но тогда, должны ли излучать события ( заход на посадку A ) или инициировать действия самостоятельно ( заход на посадку B )?

@Component({
  selector: 'app-item-card',
  template: `
    <div>
      {{ item.title }}
      <button (click)="delete.emit(item.id)">Delete</button>
      <button (click)="toggleFavorite(item.id)">Favorite</button>
    </div>
  `,
})
export class ItemCardComponent {
  @Input()
  item: any;

  // Approach B
  @Output()
  delete: EventEmitter<number> = new EventEmitter();

  // Approach A
  toggleFavorite(id: number) {
    // Assume that we have access the store here
    this.store.dispatch({ type: '[Item] ToggleFavorite', payload: id });
  }
}

При подходе A у вас много шаблонного примеракод (поскольку смарт-компонент должен обрабатывать событие, а затем инициировать действия).При подходе B мы связываем компонент дампа с состоянием.

1 Ответ

0 голосов
/ 20 сентября 2018

Мы можем начать с тупого компонента, который напрямую подключен к хранилищу (отправляя событие).

Следующим шагом является ожидание, пока нам действительно не понадобится повторно использовать этот компонент.Чем мы проводим рефакторинг и разделяем компоненты smart / dump.

Преждевременная оптимизация ( обобщение ?) Является корнем всего зла

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...