Как "тупой" должен быть немой компонент?

Я создаю свое приложение Redux (NgRx) с компонентами smart/dump, но я боюсь решить, как "тупые" немые компоненты должны быть...

Например, у меня есть интеллектуальный компонент (posts), который имеет немой компонент (post-list), содержащий немые компоненты (post). Пока здесь все выглядит хорошо.

Чтобы отобразить некоторые кнопки, мне нужно знать, является ли пользователь admin или нет, и мне нужно передать свойство admin до конца от posts до post.

Могу ли я подключить немой компонент post к хранилищу и получить его непосредственно из немого компонента. Или компонент в этом случае больше тупой? Он будет выглядеть примерно так:

  private admin$: Observable<boolean>;
  constructor(private store: Store<AppState>){
    this.admin$ = this.store.let(isAdmin());
  }

Я думаю, что это сэкономит много избыточности. Это хорошая или плохая практика?

Ответ 1

Немые компоненты должны быть презентационными компонентами без какой-либо логики.

По словам Дэн Абрамов Автор Redux, немые компоненты соответствуют следующим критериям:

Заботится о том, как выглядят вещи.
Может содержать как презентационные, так и контейнерные компоненты ** внутри, и обычно имеет некоторую разметку DOM и свои стили.
Часто разрешать сдерживание через this.props.children.
Не зависимо от остальных приложений, таких как действия или магазины Flux.
Не указывайте, как данные загружаются или мутируются.
Получить данные и обратные вызовы исключительно через реквизиты.
Редко имеют собственное состояние (когда они это делают, его состояние пользовательского интерфейса, а не данные).
Записываются как функциональные компоненты, если им не нужны состояния, крючки жизненного цикла или оптимизация производительности.
Примеры: Страница, Боковая панель, История, Пользовательская информация, Список.

В angular

Они должны просто отображать информацию и обрабатывать события через входные и выходные потоки.

Итак, моя рекомендация - проверить пример приложения ngrx на смарт и немой: https://github.com/ngrx/example-app

Также вы можете увидеть, как я сделал реализацию умных и немых в игре. https://github.com/wizardnet972/tic-tac-toe

Примечание. Контейнерные компоненты также могут использоваться повторно. Является ли компонент компонентом представления или компонентом контейнера, является деталью реализации.

Презентационные компоненты получают данные через @Input() и сообщают события через @Output(), но обычно не поддерживают собственное внутреннее состояние. Все решения делегируются "контейнерам" или "умным" компонентам до тех пор, пока потоки данных не вернутся.

Надеюсь, что это поможет.

Ответ 2

Этот вопрос относится к любой клиентской платформе, включая React/Flux, а также к старым приложениям Angular 1.x(обычно с помощью https://github.com/angular-redux/ng-redux), и, как и многие другие, ответ заключается в том, что это зависит от ваших вариантов использования.

Однако вы задали два вопроса. Как глупые должны быть немые компоненты и как лучше всего определить, должен ли компонент быть немым в первую очередь.

Вопрос 1: Как лучше всего определить, должен ли компонент быть немым в первую очередь:

В вашем конкретном случае я задал бы вопрос: будут ли использоваться элементы Post List или Post вне сообщений? Итак, сделайте наивысший "уровень" умным компонентом (также называемым контейнером). Например, если Post будет использоваться только в Post List, но Post List может использоваться вне сообщений, тогда Post List должен быть интеллектуальным компонентом, позволяющим вам просто "сбрасывать" его на другие компоненты.

Это иллюстрирует общий подход. Спросите, может ли тупой компонент существовать выше или как родственный к нему интеллектуальный компонент, и если да, продвигайте его, а если нет, оставьте его как немой компонент.

Вопрос 2: Как "тупой" должен быть немой компонент:

Немой компонент должен быть передан все, что изменится, и как наилучшая практика - методы для вызова любых событий, которые могут произойти в зависимости от действия пользователя.

Например: если текст, изображения или носители основаны на изменениях в состоянии приложения, эти данные должны быть переданы компоненту. И если существуют кнопки, ссылки, формы или другие элементы, доступные для клика, передача по меньшей мере необязательных обратных вызовов/методов для вызова для них предоставит пользователям вашего компонента (даже это он) будущую гибкость по мере роста требований приложения.

Ответ 3

Я бы подумал, что "тупой" можно использовать повторно в другом контексте.

Dumb будет интересовать только родителя.

Мантра, которую я повторяю себе, используя angular 2. Если она становится сложной и запутанной, переосмыслите мою стратегию.

Как насчет другого уровня компонентов. Режим администратора - один ребенок, а не администратор - другой. Эти дочерние компоненты могут получать свои данные через Input и испускать через Output.

Ответ 4

Я полагаю, вам нужно изменить структуру ваших компонентов, например, изображение: - Smart_VS_Dumb