Presentational and Container Components
https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0 There’s a simple pattern I find immensely useful when writing React applications. If?you’ve been doing React for a while,you have probably already discovered it.?This article explains it well,but I want to add a few more points. You’ll find your components much easier to reuse and reason about if you?divide them into two categories.?I call them?Container?and?Presentational?components* but I also heard?Fat?and?Skinny,?Smart?and?Dumb,?Stateful?and?Pure,?Screens?and?Components,etc. These all are not?exactly?the same,but the core idea is similar. My?presentational?components:
My?container?components:
I put them in different folders to make this distinction clear. Benefits of This?Approach
Remember,?components don’t have to emit DOM.?They only need to provide composition boundaries between UI concerns. Take advantage of that. When to Introduce Containers?I suggest you to start building your app with just presentational components first. Eventually you’ll realize that you are passing too many props down the intermediate components. When you notice that some components don’t use the props they receive but merely forward them down and you have to rewire all those intermediate components any time the children need more data,it’s a good time to introduce some container components. This way you can get the data and the behavior props to the leaf components without burdening the unrelated components in the middle of the tree. This is an ongoing process of refactoring so don’t try to get it right the first time. As you experiment with this pattern,you will develop an intuitive sense for when it’s time to extract some containers,just like you know when it’s time to extract a function. My?free Redux Egghead series?might help you with that too! Other DichotomiesIt’s important that you understand that the distinction between the presentational components and the containers is not a technical one. Rather,it is a distinction in their purpose. By contrast,here are a few related (but different!) technical distinctions:
Both presentational components and containers can fall into either of those buckets. In my experience,presentational components tend to be stateless pure functions,and containers tend to be stateful pure classes. However this is not a rule but an observation,and I’ve seen the exact opposite cases that made sense in specific circumstances. Don’t take the presentational and container component separation as a dogma. Sometimes it doesn’t matter or it’s hard to draw the line. If you feel unsure about whether a specific component should be presentational or a container,it might be too early to decide. Don’t sweat it! ExampleThis gist?by?Michael Chan?pretty much nails it. Further Reading
Footnotes* In an earlier version of this article I called them “smart” and “dumb” components but this was overly harsh to the presentational components and,most importantly,didn’t really explain the difference in their purpose. I enjoy the new terms much better,and I hope that you do too! ** In an earlier version of this article I claimed that presentational components should only contain other presentational components. I no longer think this is the case. Whether a component is a presentational component or a container is its implementation detail. You should be able to replace a presentational component with a container without modifying any of the call sites. Therefore,both presentational and container components can contain other presentational or container components just fine. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |
- oracle分析函数:二、秩运算(DENSE_RANK函数,RANK函数)
- 过拟合与正则化
- TimeoutException,TaskCanceledException C#
- UML中的几种关系(依赖,关联,泛化,实现)
- ruby – Sinatra :: Streaming with Rack没有分块响应
- swift – iOS/tvOS playground失败,“无法找到所选运行目标
- ruby-on-rails – 在RSpec中stub_model和mock_model有什么区
- Nand Flash数据存储规则与数据读写方法(一)
- ruby-on-rails – rails3中没有命名路由的远程form_tag
- 免安装flex软件的配置