首页 文章

愚蠢的组件应该如何“愚蠢”?

提问于
浏览
17

我正在使用智能/转储组件构建我的Redux(NgRx)应用程序,但我正在努力决定愚蠢的组件应该是多么“愚蠢”......

例如,我有 smart componentposts ),其中包含 dumb componentpost-list ),其中包含 dumb componentspost ) . 直到这里一切都很好看 .

要显示一些按钮,我需要知道用户是否 admin ,我需要将属性 adminposts 一直传递到 post .

我可以将哑组件 post 连接到商店并直接从哑组件中获取它 . 或者在这种情况下组件是否愚蠢?它看起来像这样:

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

我认为这样可以节省大量的冗余 . 这是好的还是坏的做法?

3 回答

  • 6

    愚蠢的组件应该是没有任何逻辑的表示组件 .

    According to Dan Abramov Redux的作者,哑组件符合以下标准:

    • 关注事物的外观 .

    • 可以在里面包含表示和容器组件**,并且通常有一些自己的DOM标记和样式 .

    • 经常允许通过this.props.children进行遏制 .

    • 与应用程序的其余部分无关,例如Flux操作或商店 .

    • 不指定数据的加载方式或变异方式 .

    • 仅通过道具接收数据和回调 .

    • 很少有自己的状态(当他们这样做时,它是UI状态而不是数据) .

    • 被写为功能组件,除非它们需要状态,生命周期钩子或性能优化 .

    • 示例:页面,边栏,故事,UserInfo,列表 .

    In angular

    它们应该只显示信息并通过输入和输出流处理事件 .

    所以我的建议是在智能和哑巴上检查ngrx示例应用程序:https://github.com/ngrx/example-app

    你也可以在游戏中看到智能和愚蠢的 I did the implementation . https://github.com/wizardnet972/tic-tac-toe

    注意:容器组件也可以重复使用 . 组件是表示组件还是容器组件是实现细节 .

    表示组件通过@Input()接收数据并通过@Output()传递事件,但通常不维护自己的内部状态 . 在数据更新流回之前,所有决策都委托给“容器”或“智能”组件 .

    希望这很有帮助 .

  • 1

    这个问题适用于任何客户端框架,包括React / Flux以及传统的Angular 1.x应用程序(通常通过https://github.com/angular-redux/ng-redux之类的东西),以及许多内容,答案是它取决于您的用例 .

    你问了两个问题 . 愚蠢的组件应该是多么愚蠢,以及如何最好地确定组件是否应该首先是哑巴 .

    问题1:如何最好地确定组件是否应该首先是哑巴:

    在您的具体情况下,我会问一个问题:帖子列表或帖子组件是否会在帖子之外使用?是这样,使最高级别“智能组件”(也称为容器) . 例如,如果Post仅在Post List中使用,但Post List可以在Posts之外使用,那么Post List应该是智能组件,允许您更轻松地将其“删除”到其他组件中 .

    这虽然证明了一般方法 . 询问一个愚蠢的组件是否可能存在于其上方或作为其智能组件的兄弟,如果是,则提升它,如果不存在,则将其作为一个愚蠢的组件 .

    问题2:愚蠢的成分应该是多么“愚蠢”:

    一个愚蠢的组件需要传递任何更改的内容,并且作为最佳实践,可以调用基于用户操作可能发生的任何事件的方法 .

    例如:如果文本,图像或媒体基于应用程序状态的更改,则应将此数据传递给组件 . 如果存在按钮,链接,表单或其他可点击元素,至少传递可选的回调/方法来为这些元素调用将为组件的用户(即使它就是你)提供未来的灵活性,因为应用程序需求会增长 .

  • 1

    我认为'哑'可以在不同的环境中重复使用 .

    哑巴只会对它的父母感兴趣 .

    一个口头禅,我用角度2重复自己 . 如果它变得复杂和混乱,重新考虑我的策略 .

    另一层组件怎么样?管理员模式是一个孩子,非管理员是另一个孩子 . 这些子组件可以通过Input获取数据,并通过Output发出 .

相关问题