react 时刻表插件_React“啊哈”的时刻

react 时刻表插件

As a teacher, one of my main goals is to maximize people’s “aha” moments.

作为一名老师，我的主要目标之一是最大限度地利用人们的“哈哈”时刻。

An “aha” moment is a moment of sudden insight or clarity, where the subject starts to makes a lot more sense. We’ve all experienced these. And the best teachers I know are able to understand their audience and adapt the lesson in order to maximize these moments.

“啊哈”时刻是突然的洞察力或清晰感的时刻，在这个时刻，主题变得更加有意义。 我们都经历过这些。 据我所知，最好的老师能够理解他们的听众并适应课程，以最大限度地利用这些机会。

Over the past few years, I’ve taught React through just about every popular medium. The entire time, I’ve taken detailed notes on what triggers these “aha” moments, specifically for learning React.

在过去的几年中，我几乎通过每种流行的媒介都教过React。 在整个过程中，我都详细记录了触发这些“啊哈”时刻的原因，特别是为了学习React。

About two weeks ago, I came across this Reddit thread, which had the same idea. It inspired me to write this article, which is my collection of these moments and reflections on other moments shared in that Reddit thread. My hope is that this will will help React concepts click for you in new ways.

大约两周前，我遇到了这个Reddit线程 ，它的想法是相同的。 这启发了我写这篇文章，这是我收集的这些时刻以及对Reddit线程中共享的其他时刻的反思。 我希望这将有助于React概念以新的方式为您点击。

见解1：道具对组件而言，参数对函数而言。 (Insight 1: Props are to components what arguments are to functions.)

One of the best parts of React is that you can take that same intuition you have about JavaScript functions, then use it to determine when and where you should create React components. But with React, instead of taking in some arguments and returning a value, your function will take in some arguments and return an object representation of your User Interface (UI).

React最好的部分之一是，您可以对JavaScript函数具有相同的直觉，然后使用它来确定何时以及在何处创建React组件。 但是使用React，您的函数将接受一些参数并返回用户界面(UI)的对象表示，而不是接受一些参数并返回值。

This idea can be summed up in the following formula: fn(d) = V, which can be read: “a function takes in some data and returns a view.”

这个想法可以用下面的公式来总结： fn(d) = V ，可以读成：“一个函数接受一些数据并返回一个视图。”

This is a beautiful way to think about developing user interfaces because now your UI is just composed of different function invocations. This is how you’re already used to building applications. And now you can take advantage of all of the benefits of function composition when building UIs.

这是考虑开发用户界面的一种好方法，因为现在您的UI只是由不同的函数调用组成。 这就是您已经习惯构建应用程序的方式。 现在，您可以在构建UI时充分利用功能组合的所有优势。

见解2：在React中，您的整个应用程序UI都是使用函数组合构建的。 JSX是这些功能的抽象。 (Insight 2: In React, your entire application’s UI is built using function composition. JSX is an abstraction over those functions.)

The most common reaction I see from first timers using React goes something like: “React seems cool, but I really don’t like JSX. It breaks my separation of concerns.”

我从使用React的初学者看到的最常见React是：“ React看起来很酷，但我真的不喜欢JSX。 这打破了我的关注点分离。”

JSX isn’t trying to be HTML. And it’s definitely more than just a templating language.

JSX并不想成为HTML。 而且绝对不只是模板语言。

There are two important things to understand with JSX.

使用JSX有两点要理解。

First, JSX is an abstraction over React.createElement, which is a function that returns an object representation of the DOM.

首先， JSX是对React.createElement的抽象， React.createElement是一个返回DOM对象表示的函数。

I know that was wordy, but basically whenever you write JSX, once it’s transpiled, you’ll have a JavaScript object which represents the actual DOM — or whatever view is representative of the platform you’re on (iOS, Android, etc). Then React is able to analyze that object and analyze the actual DOM. Then by doing a diff, React can update the DOM only where a change occurred.

我知道这很罗word，但是基本上，每当您编写JSX时，一旦将其转换，您将拥有一个JavaScript对象，该对象代表实际的DOM-或代表您所使用的平台(iOS，Android等)的任何视图。 然后，React能够分析该对象并分析实际的DOM。 然后通过比较，React只能在发生更改的地方更新DOM。

This has some performance upsides to it but more importantly shows that JSX really is “just JavaScript.”

它具有一些性能优势，但更重要的是，它表明JSX实际上是“仅JavaScript”。

Second, because JSX is just JavaScript, you get all the benefits that JavaScript provides — such as composition, linting, and debugging. But you also still get with the declarativeness (and familiarity) of HTML.

其次，由于JSX只是JavaScript，您将获得JavaScript提供的所有好处-例如合成，整理和调试。 但是您仍然可以理解HTML的声明性(和熟悉性)。

见解3：组件不必与DOM节点相对应。 (Insight 3: Components don’t necessary have to correspond to DOM nodes.)

When you first learn React you’re taught that “Components are the building blocks of React. They take in input and return some UI (the Descriptor Pattern).”

初学React时，您会学到“组件是React的基石。 他们接受输入并返回一些UI(描述符模式)。”

Does that mean that every component needs to directly return UI descriptors as we’re typically taught? What if we wanted to have a component render another component (Higher Order Component pattern)? What if we wanted a component to manage some slice of state and then instead of returning a UI descriptor, it returns a function invocation passing in the state (Render Props pattern)? What if we had a component that was in charge of managing sound rather than a visual UI, what would it return?

这是否意味着每个组件都需要按照我们通常的教导直接返回UI描述符？ 如果我们想让一个组件渲染另一个组件(高阶组件模式)怎么办？ 如果我们希望组件管理状态的一部分，然后不返回UI描述符，而是返回传递状态的函数调用(呈现道具模式)，该怎么办？ 如果我们有一个负责管理声音而不是视觉UI的组件怎么办，它将返回什么？

What’s great about React is you don’t have to return typical “views” from your components. As long as what eventually gets returned is a React element, null, or false, you’re good.

什么是伟大的大约阵营是你没有从你的组件返回典型的“意见”。 只要最终返回的是React元素，null或false，就可以了。

You can return other components:

您可以返回其他组件：

render () {   return <MyOtherComponent /&gt; }

You can return function invocations:

您可以返回函数调用：

render () {   return this.props.children(this.someImportantState) }

Or you can return nothing at all:

或者，您什么也不能返回：

render () {   return null }

I really enjoyed Ryan Florence’s React Rally talk where he covers this principle more in depth.

我真的很喜欢Ryan Florence的React Rally演讲 ，他在其中更深入地介绍了这一原理。

见解4：当两个组件需要共享状态时，我需要提升该状态，而不是尝试使它们的状态保持同步。 (Insight 4: When two components need to share state, I need to lift that state up instead of trying to keep their states in sync.)

A component-based architecture naturally makes sharing state more difficult. If two components rely on the same state, where should that state live?

基于组件的体系结构自然会使共享状态更加困难。 如果两个组件依赖于同一状态，那么该状态应存在于何处？

This was such a popular question that it spurred an entire ecosystem of solutions, which eventually ended with Redux.

这是一个非常受欢迎的问题，它刺激了整个解决方案生态系统，最终生态系统以Redux结尾。

Redux’s solution is to put that shared state in another location called a “store.” Components can then subscribe to any portions of the store they need, and can also dispatch “actions” to update the store.

Redux的解决方案是将共享状态放在另一个称为“商店”的位置。 然后，组件可以订阅他们需要的商店的任何部分，还可以调度“操作”以更新商店。

React’s solution is to find the nearest parent of both of those components and have that parent manage the shared state, passing it down to the child components as needed. There are pros and cons to both approaches, but it’s important to be aware that both solutions exist.

React的解决方案是找到两个组件的最接近的父组件，并让该父组件管理共享状态，并根据需要将其传递给子组件。 两种方法都有优点和缺点，但是重要的是要知道两种解决方案都存在。

见解5：在React中不需要继承，并且使用组合既可以实现包容又可以实现专业化。 (Insight 5: Inheritance is unnecessary in React, and both containment and specialization can be achieved with composition.)

React has always been, for good reason, very liberal in adopting functional programming principles. One example of React’s move away from inheritance and towards composition was when its 0.13 release made it clear that React wasn’t adding support for Mixins with ES6 classes.

出于充分的原因，React一直在采用函数式编程原理方面非常自由。 React从继承转向合成的一个例子是当它的0.13版本清楚地表明React并未添加对具有ES6类的Mixins的支持时。

The reason for this is that almost everything you can accomplish with Mixins (or inheritance), you can also accomplish it through composition — but with fewer side effects.

这样做的原因是，几乎可以用Mixins(或继承)完成的所有事情，也可以通过合成来完成，但副作用更少。

If you’re coming to React from an inheritance heavy mindset, this new way of thinking may be difficult, and it may feel unnatural. Luckily there are some great resources to help. Here’s one I enjoyed that isn’t React-specific.

如果您是从继承沉重的思维定势转向React的，那么这种新的思维方式可能会很困难，并且可能会感觉不自然。 幸运的是，这里有很多资源可以提供帮助。 这里有一个我喜欢是没有React过来特定的。

见解6：容器和表示组件的分离。 (Insight 6: The separation of container and presentational components.)

If you think about the anatomy of a React component, it usually involves some state, potentially some lifecycle hooks, and markup via JSX.

如果您考虑React组件的解剖结构，它通常涉及某种状态，可能涉及一些生命周期挂钩，以及通过JSX进行标记。

What if, instead of having all of that in one component, you could separate the state and the lifecycle hooks from the markup. This would leave you with two components. The first has state, life cycle methods, and is responsible for how the component works. The second receives data via props and is responsible for how the component looks.

如果可以将状态和生命周期挂钩与标记分开，而不是将所有这些都包含在一个组件中，该怎么办？ 这将使您有两个组成部分。 第一个具有状态，生命周期方法，并负责组件的工作方式。 第二个组件通过props接收数据，并负责组件的外观。

This approach allows for better reusability of your presentational components, since they’re no longer coupled to the data they receive.

这种方法可以使您的演示组件更好地重用，因为它们不再与收到的数据耦合。

I’ve also found that it allows you (and newcomers to your project) to better understand the structure of your application. You’re able to swap out the implementation of a component without seeing or caring about the UI and vice versa. As a result, designers can tweak the UI without ever having to worry about how those presentational components are receiving data.

我还发现它使您(和项目的新手)可以更好地了解应用程序的结构。 您可以交换组件的实现而无需查看或关心UI，反之亦然。 结果，设计人员可以调整UI，而不必担心这些表示组件如何接收数据。

Check out Presentational and Container Components for more detail on this.

查看演示文稿和容器组件，以获取更多详细信息。

见解7：如果您尝试使大多数组件保持纯净，则无状态的东西将变得更易于维护。 (Insight 7: If you try to keep most of your components pure, stateless things become a lot simpler to maintain.)

This is another benefit of separating your presentational components from your container components.

这是将表示性组件与容器组件分离的另一个好处。

State is the sidekick of inconsistency. By drawing the right lines of separation, you’re able to drastically improve the predictability of your application by encapsulating complexity.

国家是矛盾的代名词。 通过绘制正确的分隔线，您可以通过封装复杂性来大大提高应用程序的可预测性。

Thanks for taking the time to read my article. Follow me on Twitter and check out my blog for more insights on JavaScript and React.

感谢您抽出宝贵的时间阅读我的文章。 在Twitter上关注我，并查看我的博客以获取有关JavaScript和React的更多见解。

翻译自: https://www.freecodecamp.org/news/react-aha-moments-4b92bd36cc4e/

react 时刻表插件