react 渲染道具
Hey everybody! This time I’m going to tell you about this great superpower called “render props”.
大家好！ 这次，我将向您介绍这个称为“渲染道具”的 超级大国 。
The term “render prop” refers to a technique for sharing code between React components using a prop whose value is a function.
术语“渲染道具”是指使用价值为函数的道具在React组件之间共享代码的技术。
The concept involved is also known as “children as a function” or “child as a function”. The components that implement this pattern can be called “render prop components”.
所涉及的概念也被称为“儿童作为功能”或“儿童作为功能” 。 实现此模式的组件可以称为“渲染道具组件” 。
This is one of the advanced patterns in React that is a must to master in your daily life as a programmer.
这是React中高级的模式之一，在您作为程序员的日常生活中必须掌握。
So, I hope your JavaScript is in shape because this is an awesome, super cool pattern to implement!
因此，我希望您JavaScript状况良好，因为这是一种很棒的超酷模式！
Let’s get started:
让我们开始吧：
What do we have here ?? Let’s decode!
我们有什么在这里 ？？ 让我们解码！
We have a component that receives children as a prop (it destructures it from props) and returns it as a function, with arguments. Here, children are returned with the integer 30.
我们有一个接收子项作为道具的组件(它将子项从道具中解构)，并将其作为带有参数的函数返回。 在此，子级返回整数30。
Just to make sure we are on the same page, the code above is the same as writing:
为了确保我们在同一页面上，上面的代码与编写相同：
Or in a more elaborated class Component:
或者在更详细的类Component中：
OK! Let’s get back to where we were coming from.
好！ 让我们回到原来的位置。
To invoke this component we write a function as children:
要调用此组件，我们编写一个作为子代的函数：
Okay, let’s improve the code a bit.
好的，让我们对代码进行一些改进。
I always use a little bit of bootstrap styling to make my examples simple, clean and a little bit polished.
我总是使用一些Bootstrap样式来使我的示例简单，干净并且有点精致。
Keep in mind that children are whatever exists inside the <Temperature> </Temperature> invocation.
请记住，子元素是<Temperature> </ Temperature>调用中存在的任何东西。
The Temperature component is totally transparent about what children are, it just renders them passing 30 as an integer.
Temperature组件对于孩子是什么完全透明，它只是使孩子传递30作为整数。
So the result we have in the browser is this:
因此，我们在浏览器中得到的结果是：
Let’s say something about the weather! ?
让我们说说天气吧！ ？
Okay! Nice feature you say!
好的！ 你说的不错的功能！
But why is this a nice feature? Let’s keep your brain cool! ?
但是，为什么这是一个不错的功能？ 让我们保持头脑凉爽！ ？
We have separated the controller from the view! Now we have a component called Temperature which is able to receive temperatures from an API “far far away” and render its children, whichever they are, passing the temp value into them.
我们从视图中分离了控制器！ 现在，我们有了一个名为Temperature的组件，它能够从“遥远”的API接收温度并渲染其子元素(无论它们是什么)，并将温度值传递给它们。
Make sure you understand this great benefit and superpower! The temperature Component doesn’t know its children in advance. It only knows that independent of the children it will render them and pass them the temperature value.
确保您了解这种巨大的好处和超能力！ 温度组件不预先知道其子级。 它仅知道独立于子项将渲染它们并将其传递给温度值。
Of course we could make use of composition and encapsulate the children logic into another component, for example the ShowTemperature in Celsius.
当然，我们可以利用合成并将子级逻辑封装到另一个组件中，例如摄氏温度(ShowCempius)。
Let’s do it.
我们开始做吧。
And that’s it! Why is this kewl? Because now I’m going to reuse the same thingies and do a ShowTemperatureInFahrenheit!
就是这样！ 为什么要绞呢？ 因为现在我要重用相同的东西并执行ShowTemperatureInFahrenheit！
Yeah! That’s so nice! We’ve encapsulated the render stuff into components using composition. We could keep going making a new ShowTemperature component to be invoked inside ShowTemperatureInCelsius or ShowTemperatureInFahrenheit.
是的 太好了！ 我们已经使用合成将渲染素材封装到组件中。 我们可以继续制作一个新的ShowTemperature组件，以在ShowTemperatureInCelsius或ShowTemperatureInFahrenheit内部调用。
But if we want to apply the render props pattern again to show different colors that we get from user preferences, for example?
但是，如果我们想再次应用渲染道具图案以显示从用户偏好中获得的不同颜色，例如？
Let’s try it.
让我们尝试一下。
Okay mates, this is a great tool but… “With great power comes great responsibility”.
好的，队友，这是一个很棒的工具，但是……“强大的力量伴随着巨大的责任”。
If we do one or two more render prop components we’ll deep dive into a callback hell sooner than we might expect!
如果我们再增加一个或两个render prop组件，我们将比我们预期的更快地深入到回调地狱！
When we need to extract something or get some other props that come mixed in in the React cascade flow, we’re going to start to get confused and the code will become messy and not explicit or declarative anymore.
当我们需要提取某些东西或将其他一些道具混入到React级联流中时，我们将开始感到困惑，并且代码将变得混乱，不再是显式的或声明性的。
So…how can we avoid this?
那么...我们如何避免这种情况？
Well… maybe you already thought of this. Render props is very similar in purpose to HOC (Higher Order Components).
好吧……也许您已经想到了这一点。 渲染道具的用途与HOC(高阶组件)非常相似。
Actually, we can use one or the other for almost the same purpose. A lot of ink has already been spent on that subject.
实际上，我们可以将一个或另一个用于几乎相同的目的。 在该主题上已经花费了大量墨水。
If you don’t know anything about HOCs, you can read my article about the container pattern here where I show you how to do a simple HOC.
如果您对HOC一无所知，则可以在此处阅读有关容器模式的文章，向我展示如何进行简单的HOC。
I promise to write an article about HOCs in the nearly future, because it’s also a pattern that deserves some attention.
我保证在不久的将来写一篇有关HOC的文章，因为它也是一种值得关注的模式。
So, just as a test let’s evolve our Color abstraction to a HOC:
因此，就像测试一样，让我们将颜色抽象发展为HOC：
Nice! The same result! We’ve done a Javascript function that receives a Component and returns a class which renders the WrappedComponent with the desired prop we can get somewhere else!
真好！ 结果一样！ 我们已经完成了一个Javascript函数，该函数接收一个Component并返回一个类，该类使用所需的道具呈现WrappedComponent，我们可以在其他地方得到它！
This is kind of a silly example but I think it helps point out the difference between these two patterns.
这是一个愚蠢的例子，但我认为这有助于指出这两种模式之间的差异。
So… when should you use the former or the latter?
所以……什么时候应该使用前者或后者？
Well, everything comes with a cost. I’d dare say that I find HOC to be much cleaner than render props.
好吧，一切都是有代价的。 我敢说我发现HOC比渲染道具要干净得多。
The problem is that HOCs cut the composition flow a little that makes React so great. Also in some circumstances they aren’t so performant and they tend to trigger more renders in your components — so beware of this caveat.
问题是HOC稍微减少了合成流程，这使React变得如此强大。 同样，在某些情况下，它们的性能也不那么好，它们往往会触发组件中的更多渲染-因此请注意这一警告。
As a rule of thumb, I usually try to use render props because it’s a win-win pattern that prioritises composition.
根据经验，我通常尝试使用渲染道具，因为这是优先考虑合成的双赢模式。
If you find that you’re falling into a callback hell, then switch to HOC as a second step.
如果您发现自己陷入回调地狱，请第二步切换到HOC。
If you know, for instance, React Router, you easily have the feeling why withRouter is an HOC and <Switch/> or <Router/> are render props components. It depends a lot in which context you’re working and how you want the code to be expressive and fluid.
例如，如果您知道React Router，您将很容易理解为什么withRouter是HOC，而<Switch />或<Router />是渲染道具组件。 这在很大程度上取决于您在哪种环境下工作以及如何使代码具有表现力和流畅性。
If you don’t know React Router, keep everything I told you in mind. Then, while you’re writing some code, try these patterns until you decide easily which is better according to the context or objective.
如果您不了解React Router，请牢记我告诉您的一切。 然后，在编写一些代码时，尝试使用这些模式，直到根据上下文或目标轻松决定哪个更好。
Last but not least, you can play a little bit around with the code in my GitHub repo here.
最后但并非最不重要的一点是，您可以在这里在我的GitHub存储库中使用一些代码。
And that’s it everybody! ? ? I hope you’ve enjoyed this small introduction to render props. For more information please check the Bibliography below!
就是每个人！ ？ ？ 希望您喜欢这个介绍道具的小介绍。 有关更多信息，请检查下面的参考书目！
参考书目 (Bibliography)
Thank you very much!
非常感谢你！
evedes, Nov 2018
evedes，2018年11月
react 渲染道具
480
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
