道具钻(propsdrilling)

时间：2023-03-27 11:10:44 JavaScript

道具钻(propsdrilling)what只是通过组件层级太深，中间层组件不需要这些props，只是做一个向下的转发，这种情况称为propsdrilling。打个比方，我们买东西，从卖家到送货，要经过一系列的流程，跨省、市、区，最后到我们这里。中间的只是负责转发，他们不关心物品是什么，最终目的是负责把快递送到买家手中。我给大家举个详细的例子：有一个组件App，它有一个user属性表示当前登录的用户，然后有一个组件WelcomeMessage需要获取用户进行渲染。这是一个很常见的需求：用户登录后，显示欢迎信息xxx，那么我们来看看他的流程。App首先传递props给DashboardDashboard给DashboardContent（没有props，只是转发）DashboardContent给WelcomeMessage（没有props，只是转发）WelcomeMessage接收用户props进行渲染（最后到达需要props的地方）看代码：functionDashboard({user}){return(

Dashboard

;

);}functionDashboardContent({user}){return(

DashboardContent

;

);}functionWelcomeMessage({user}){return(

欢迎{user.name}

);}exportdefaultfunctionApp(){constuser={name:'itsuki'};return(

);}用户属性从App组件传递到WelcomeMessage组组件，然后只有WelcomeMessage组件才是真正消费props的地方。道具钻有什么问题？传递的时候肯定遇到过这样的情况，孙子组件需要访问爷爷组件的props，中间的父组件做了一层传递，但是传递的只有三层，所以问题不大明显的。但是如果组件树太复杂，如果有十层、二十层就完了，至少有20个组件需要接收一个不必要的props，只是为了某个组件使用这个props，那么如果有n个props就需要就这样过去了，不敢想象，会是一场噩梦。黑盒子看上面的代码。我们在组件中使用了一个组件，什么？厉害了，一个组件渲染这么多东西（这还是一个简单的组件，如果是真实案例，估计会更复杂），但是就像一个黑盒子，我只知道需要传递userprops下来，它能成功渲染出想要的内容，我们无法知道和组织它的内部结构，更谈不上扩展它了，因为它已经“固定”了，当需要扩展一个新的功能时，它就结束了，props必须重新传输并重新调整布局。代码看起来多么脆弱。如何解决我们要解决的问题，就像上面的例子，WelcomeMessage的props不想层层传递，也不想跨n层组件读取想要的props。那么这个时候怎么解决呢？我们不妨试试组合。可以看看官方文档是如何介绍和使用的。看一下使用组合的改进代码。functionDashboard({children}){return(

Dashboard

{children}

);}functionDashboardContent({children}){return(

DashboardContent

{children}

);}functionWelcomeMessage({user}){return(

Welcome{user.name}

);}exportdefaultfunctionApp(){return(

);}passedlike这个我们解决了道具钻取的问题，不会影响我们的扩展，比如我可能有其他组件需要相同或不同的道具？你会发现使用组合方式扩展起来更容易，如果你不能保证你的组件是否需要扩展，请保持抽象！！！exportdefaultfunctionApp(){constuser={name:'itsuki'};返回(

);}组合不限于childrenprop，你可以尝试left,right或者其他prop名称来抽象，具体看自己>

{children}

{props.left}

);}functionApp({children}){return(left}right={}>{children});}context还有一种使用Context的方式，随着Hooks的出现，使用Context是更简洁。constAuthContext=createContext({});functionApp(){constuser={name:'itsuki'};return();}functionWelcomeMessage(){const{user}=useContext(AuthContext);}return(

Welcome{user.name}

);}正如官方文档所说：Context主要应用场景原因是很多不同层级的组件需要访问相同的数据，例如用户信息、主题或语言。如果需要使用Context，请注意，这会使组件重用变得更加困难，换句话说：没有“Context”就无法重用组件。functionOtherPage(){return;}!!!报告错误，并且在没有AuthContext的情况下读取用户。后记如果这两种方法的选择取决于您，则各有优缺点。我自己的想法是，如果组件层级不复杂，组合肯定比Context好。有以下两点。第一点：Context的使用会受其约束，不能脱离“Context”。第二点：如果Context值是一个对象，其他组件依赖了对象中的某个值a，即使被依赖对象的值a没有改变，它仍然会被重新渲染。第三点：使用组合可以更灵活，你可以随意组合任意一个，让你的组件看起来不像黑盒子，更具扩展性。如果组件层级复杂或者有一些全局数据，我个人推荐使用Context，加上Hooks可以复用逻辑，还是挺舒服的。最后，我在研究如何更好地设计React。我发现了这些知识点，结合我个人博客使用Context解决道具钻孔，后来发现用组合更合适。这个有点意思，突然觉得React好强大，好的React应用一定有好的抽象，现在回头看官方文档，只能说太香了，官方文档太牛了！!!.

上一篇：无忧企业文档搜索引擎及模板制作介绍

下一篇：Promise源码渐进解读（二）

道具钻(propsdrilling)相关文章