React Conf 2019 的 19 个要点

React Conf ⚛️正式结束了。现场有很多精彩的演讲、精彩的人物、丰富的活动，当然还有美味的食物。我还在消化整个活动，但就会议而言，这是我迄今为止参加过的最好的一次。

开发者社区常常令人望而生畏。志愿者和组织者们做得非常出色，让大会上的每个人都感到宾至如归。他们竭尽全力让我们每个人都感到归属感，这让我印象深刻。第二天甚至还安排了一些适合内向者的活动。你有没有在大会上画过迷你人物（想想战锤）？我画过！所以，感谢所有参与的人！

这篇文章将回顾一些我最喜欢的 React Conf 精彩内容。每场演讲都值得一看，所以我推荐你去看看第一天和第二天的录音。我在文章底部附上了所有演讲的时间戳。

你可能会对清单上的某些内容感到惊讶。我也是！并非所有内容都与技术有关，但其中总有一条主线贯穿始终。

1. 开发者体验服务于用户体验

汤姆·奥奇诺 (Tom Occhino)说过这句话之后，我就忍不住想了起来。我在所有演讲中都看到过类似的内容。我意识到我为什么如此热爱开发者工具和前端。

React 旨在打造一种开发者体验，让我们能够轻松学习实现强大的功能，高效地发布和迭代，并扩展我们开发的软件。仅凭这些就让我喜欢上了 React。我觉得 Facebook 在交付方面做得相当不错。

那么，这一切的意义何在？其实很简单，就是为了提升用户体验。我们所做的一切都是为了提高用户的效率。我们应该致力于帮助他们以优雅的方式完成他们想要做的事情。尽管我们帮助他们实现的目标在幕后可能并不总是那么简单，但对他们来说，应该始终保持这种感觉。

React 是一项入门级技术，63% 的 JavaScript 开发者都在使用它，因此团队非常重视社区等议题。他们遵守了贡献者契约，并乐于接受批评。作为一个社区，我们应该能够接受批评，而无需为自己辩护。Elbert Hubbard 曾说：“为了避免批评，就什么也不说，什么也不做，什么也不做。” React 正在做什么，以及为什么这么做，都至关重要。这自然会引发批评，并促进技术发展。这将使我们作为一个社区变得更好。

2. 可访问性和性能以及并发模式，天哪！

你在使用 React 时遇到过焦点问题吗？我遇到过。焦点非常重要，原因有很多。它可以帮助人们浏览页面。对于不使用鼠标的用户来说，这一点尤为重要。这个话题稍后会再次讨论，但很高兴看到 React 团队希望将可访问性内置到 React 中。

会议期间，性能是让我思考最多的问题之一。Facebook 必须处理我们大多数人永远都不会遇到的性能问题，但他们吸取的教训仍然可以用于提升用户体验。如果感知到的性能很慢，那么页面加载速度再快也没用。

一个例子就是郑宇志在演讲中解释的选择性水合。你可能也听说过Suspense ，它将改善整个网络的用户体验。

并发模式

想象一下，创建一个与用户输入绑定的可过滤列表。使用 React，你可能不得不对列表进行去抖动或限制更新，除非你能够接受卡顿。

并发模式将使 React 应用的响应速度更快，因为它允许 React 中断低优先级的工作块。这使得诸如用户输入之类的操作比重新渲染列表之类的操作具有更高的优先级。React 将能够同时处理多个状态更新。这将帮助我们消除不协调且过于频繁的 DOM 更新。它还允许我们优先处理诸如悬停和文本输入之类的交互。我们知道用户希望这些交互能够快速处理，否则他们会感到卡顿。

React 团队分享了许多并发模式的示例，我建议您查看一下。

3. FB 上的 CSS-in-JS

听到Frank Yan宣布 Facebook 正在构建自己的 CSS-in-JS 库，我感到很感兴趣。一开始我心想，难道我们现有的 CSS-in-JS 库还不够吗？这让我们有机会进一步了解 Facebook 在规模化运营中面临的一些问题，以及他们正在采取的创新解决方案。

维护 CSS 很快就会变得难以掌控。让我们看下面的例子：

.blue { color: blue; }

.red { color: red; }

<span class="red blue">
  Which color will I be?
</span>

在这个例子中，如果文本是blue就好了。这个类在类声明中排在第二位，所以我们应该能够预期它会优先加载。但事实并非如此。这个类在层叠.red样式表中排在第二位，所以最终结果就是这样。如果这些类位于不同的样式表中，它们在页面中的加载顺序就会受到影响。

这个问题用这么一个简单的例子来说可能看起来很简单，但很快就会失控。Facebook 的目标是通过他们的新库解决诸如特异性之争、主题性和可访问性等问题。

此次演讲中有几个有趣的细节：

开发人员可以以像素为单位进行编码，但他们的工作在 REM 中进行编译
他们通过实施类型检查（捕获并修复拼写错误、检测并删除未使用的样式、避免跨浏览器陷阱）来确保安全性
向开发人员显示可访问性错误

组件可以具有可覆盖的默认样式（包括类型安全！）
规则经过重复数据删除，从而允许更小的 CSS 文件（Facebook在最近的前端重写中从413kb到74kb

原子 CSS

每个类都会创建一个唯一的属性值对。这用于优化组件

.c0 { color: blue; }
.c1 { color: red; }
.c2 { font-size: 16px; }

// Generated Component (Pre-Optimized)
const styles = {
  blue: {color: 'c0'},
  default: {color: 'c1', fontSize: 'c2'},
};

function MyComponent(props) {
  return (
    <span className={styles(
      'default',
      props.isBlue && 'blue',
    )}>
      Hello World!
    </span>
  );
}

这个例子展示了 CSS 的原子性，也展示了如何使用 props 设置 span 的颜色。不过，这段代码还进行了进一步的优化。

// The styles block is no longer needed
function MyComponent(props) {
  return (
    <span className={styles(
      (props.isBlue ? 'c0 ' : 'c1 ') + 'c2 '
    )}>
      Hello World!
    </span>
  );
}

这些东西都非常有趣，我期待他们将来发布他们的图书馆。

4.数据驱动的JavaScript

你有没有想过如何让你的页面感觉更快？更快地实现交互？当然！Ashley Watkins也一样。她真的让我思考如何调整我的数据获取方法，从而获得更好的用户体验。我本来就对 Relay 很感兴趣，但她的分享更是火上浇油。

分阶段代码拆分

可以肯定的是，Facebook 的团队一直在努力确保他们的 FMP 尽可能快。他们实现这一目标的方法之一就是“分阶段代码拆分”。

通过这种方法，您可以采取单个阻塞下载并分阶段交付的方式。例如，如果您考虑 Facebook 帖子，您可以将其分为 3 个阶段。

加载中
展示
分析

每个阶段都可以有自己的代码获取和渲染。FMP 所需的所有数据都可以在加载阶段获取其代码的同时获取。

第一次有意义的绘画时间

为了尽可能提升用户体验，您应该考虑首次有效渲染 (FMP)。这基本上指的是主要内容在页面上显示所需的时间。有很多指标可以参考和衡量，以改善加载时间，但 FMP 尤为突出。

Relay 允许您使用 GraphQL 进行流式查询。这将允许您将某些数据标记为关键数据，将其他数据标记为不太关键。这样，您可以首先从服务器获取最重要的数据，并在获取其余数据的同时显示这些内容。通过这种方法，您可以在内容到达时进行渲染！

数据驱动的代码拆分

这有点让我吃惊。Relay 功能强大，这一点毋庸置疑。Relay 新增了一项功能，可以让你扩展查询语句，明确哪些组件代码需要渲染特定的数据类型。🤯 你可以将代码视为数据。当服务器解析你的 GraphQL 查询时，它可以让客户端知道需要下载哪些组件代码，以便更快地获取！

Ashley 的演讲非常精彩，她承诺这些只是个开始。我还没用过 Relay，但我很期待开始使用，我敢打赌你也会的（尤其是当你了解到它更多功能的时候）。

5. 解决世界饥饿问题

第一天，Facebook 员工们进行了一场精彩的演讲。从技术角度来看，这些演讲非常精彩。我们看到了生态系统中即将推出的诸多功能，这些功能将帮助我们提升用户体验。

Tania Papazafeiropoulou稍微转换了一下话题，向与会者介绍了世界饥饿问题以及她正在开发的一款名为OLIO的酷炫产品。这款产品可以帮助人们分享食物，避免浪费。你猜对了，它是由 React 驱动的。

令人沮丧的是，所有生产的食物中，有三分之一被浪费了。更糟糕的是，我们只需利用美国、英国和欧洲25%的食物浪费就能解决世界饥饿问题。这些令人警醒的数据让解决世界饥饿问题成为可能，听到一个团队正在为此努力，真是太棒了。

这次演讲并没有让我对 React 的新功能感到兴奋，但它让我更加深刻地体会到了 React 的伟大之处。React（以及 React Native）帮助 Tania 的团队快速构建了他们的产品，并开始产生积极的影响。

6. 让 REST 感觉更好（更安全）

RESTful API并非一个热门的新概念。它于 2000 年正式定义，并自那时起一直被成功运用。话虽如此，REST 也有一些挑战。

Facebook 使用 GraphQL 解决了这些挑战。GraphQL 为我们提供了易于理解的数据定义。它使客户端能够只获取其所需的数据。这是一种非常有效的加速渲染速度的方法，因为您无需下载太多数据！

Tejas Kumar很好地总结了这些差异（请参阅他的演讲以了解更多详情）：

休息

❌ 没有正式规范
❌ 猜谜游戏（不允许的请求会以400、401或来响应404？）
❌毫无意义的对话
❌ 无合同协议

GraphQL

✅ 正式规格
✅ 禁止猜谜游戏
✅ 有意义的讨论（对用户有影响的事情）
✅ 强有力的合同协议

我们很多人都喜欢 GraphQL，但有时它并不适合我们的 API。Tejas 和他的团队开发了一个工具，可以消除 REST 的一些缺陷。它包括根据 Swagger 和 OpenAPI 规范生成代码的功能。

我觉得自己对 Tejas 的评价不够公正，但他的演讲给我留下了深刻的印象。说真的，去看看他的演讲吧！

7. React 底层（构建自定义渲染器）

如果你曾经演示过自己编写的代码，你就会知道它经常出错。Sophie Alpert勇敢地承担了风险，并向我们讲解了如何构建 React 渲染器。

我并不认为自己是 React 专家（至少目前是这样😅）。我从未看过 React 代码库。我一直以为它超出了我的理解范围。随着我不断学习和掌握 React，我会继续深入研究，最终深入到代码库本身。Sophie在 React Conf 会场上实时构建了自己的自定义渲染器，让这一切看起来没那么吓人。

除了了解了 Sophie 的优秀之外，我觉得我对 React 渲染器的工作原理有了些许了解。她没有让我感到困惑。所有内容都解释得简单易懂，演示也清晰明了。对于一个现场编程演示，你还能要求什么呢？

愿 Demo 之神永远眷顾你，索菲！

8.本地化（很重要！）

作为一名英语母语人士，我不得不承认，在开发产品时，本地化并非我首先想到的事情。值得庆幸的是，我意识到了这一点，并且会在未来更加认真地对待它。

我认为本地化常常被忽视，因为我们关注的是和我们一样的用户。现实中不可能有和你一模一样的用户！这就是为什么我们需要进行用户测试，收集用户反馈，并对所有类型的人更具包容性。

去年，Nat Alison提出了一个问题：“React 翻译了吗？” 当她最初提出这个问题时，答案是否定的。

为什么这很重要？Nat 说得很好。如果 React 只对英语使用者开放，那么会有多少人无法使用这些工具来构建出色的产品？如果只让英语使用者塑造我们的数字世界，我们会损失多少？世界上只有 20% 的人口说英语。如果我们不帮助其他人使用 React，我们都会受苦！

Nat 和成千上万的人在过去一年里取得的成就令人难以置信。还有很多工作要做，如果你会双语，可以帮忙！

9. 无障碍马拉松

就像本地化一样，无障碍设计也可能很困难。在开发无障碍设计时，你必须换个角度思考。你必须考虑更广泛的受众，考虑那些可能与你不同的人。有时这很困难，但我们都能做到。

跑马拉松🏃🏻‍♂️是另一个可能很困难的例子。根据 RunRepeat 的数据， 2018 年有 1,298,725人完成了马拉松。他们并非一夜之间就具备了这样的能力。他们从小事做起，然后逐步提升。

这就是我们处理可访问性问题的方法。如果你从零开始，采用这样的方法可以消除一些不知所措的感觉。React Conf 我最喜欢的事情之一就是从新的视角学习软件开发和世界。Brittany Feenstra是帮助我拓展视野的人之一，我希望在未来更多地思考可访问性问题。

我无法一夜之间完成无障碍马拉松，但我可以每天多做一点。值得庆幸的是，一路上有很多好工具可以帮助我。

10. 你不需要 Redux（对吗？）

2019 年，有许多不同的方法来管理 React 状态（甚至还有素食友好的选择）。

面对如此众多的选择，很难知道哪个才是正确的选择。不幸的是，正确的选择取决于你。请记住，开发者的经验是服务于用户体验的。基于这一点，我喜欢以尽可能简单的方式进行状态管理，并随着最初的决定而不断调整。

我很高兴 React 现在内置了这么多选项。有了 Context 和 Hooks，你就能做很多事情，而无需引入其他依赖项。

为了快速行动并打破常规，你必须愿意抛弃之前所做的工作。你需要爱上重构，并摒弃那些在你的产品不同时对你有用的决策。我认为 React 状态的众多选项反映了这一点。有些选项需要大量的样板代码，有些则不需要。有些是内置的，有些则不是。选择现在感觉合适的，并在以后根据需要进行调整。

11. 时间旅行到1999年

当天最后一个演讲的标题就吸引了我。1999 年的编程是什么样子的？那时我才九岁。有些人九岁就开始编程了。我不是其中之一。😢

这次演讲真的值得一看。Lee Byron 的演讲堪称精彩绝伦。他带领我们回顾了 PHP 和 LAMP 技术栈成为 Web 开发首选工具的时代。对于那些 1999 年还没接触过编程的人来说，他解释了 Facebook 开发 React、GraphQL 和 Relay 等工具的演变过程。对于那些当时还在编程的人来说，这无疑是一种怀旧。

我一直很尊重 Facebook 的工程工作，但这次演讲让我看清了一切。使用 React 让我感到无比荣幸，现在我知道这份荣幸从何而来。像 Lee 这样的人为社区做出的贡献以及他们持续的努力让我深受启发。

12. 开发工具也与用户体验有关

第二天， Brian Vaughn继续阐述会议主题。如果你用 React 构建过东西，你很可能用过 React Dev Tools。它们确实帮助我摆脱了自己造成的困境。

React Dev Tools 经过全面重写，为我们提供了：

更好的性能
新的 API 支持
新的用户体验功能

瞧，即使是开发工具也注重出色的用户体验！

团队为帮助用户轻松驾驭陌生项目所做的改进给我留下了深刻的印象。虽然你可能觉得从未接触过的代码很陌生，但我们都知道，即使是我们自己的代码，随着时间的推移也会变得陌生。现在，我们可以看到 prop 如何在组件中流动、过滤组件树、深入检查组件，以及如何在开发工具中使用 hooks。另一个让我喜欢的功能是 suspense 开关。这个功能看似简单，但很快就会变得无价。

除了共享分析功能外，新的开发工具还能让您更轻松地查找渲染原因。市面上也有一些类似的工具，但现在我们可以直接在开发工具中深入了解渲染过程。

还有大量其他精彩内容，我建议您亲自去探索。

13. 悬疑数据（Relay 很棒）

我觉得我可能加入 Relay 派对有点晚了。事实上，我加入 GraphQL 派对也有点晚了。在我的业余项目中，我一直在使用 GraphQL，而且我非常喜欢它。这次会议结束后，我打算探索 Relay，并充分利用它带来的强大功能。

React Suspense希望让我们能够显示部分UI，而无需等待所有UI 准备就绪⏱。

让我们看一个组件的基本示例，该组件在获取数据时显示加载状态（使用 Suspense）：

const Composer = (props) => {
  const data = useQuery(graphql`
    query ComposerQuery {
      me {
        photo {
          uri
        }
      }
    }
  `, variables);

  return (
    <div>
      <img src={data.me.photo.uri} />
    </div>
  );
}

const Home = (props) => (
  <Suspense fallback={<Placeholder />}>
    <Composer />
  </Suspense>
);

在这个例子中，我们有一个Composer组件，它获取我的个人资料图片的 URI 并显示它。您可以看到，Home组件被我们包裹Composer在一个Suspense块中。然后，在数据加载过程中，Placeholder它会被渲染。这种模式可以理解为“渲染时获取”。

使用此模式，加载顺序如下：

如你所见，这让我们能够轻松处理数据加载。我们可以通过回退到加载组件（例如占位符或旋转按钮）来提供更好的用户体验。

上述模式已经提供了很多好处和灵活性，可以实现一些很酷的功能。然而，Facebook 团队不喜欢你必须在渲染过程中才能确定组件需要哪些数据。为了解决这个问题，他们开始使用一种名为“获取时渲染”的模式。

本质上，为了实现“即取即渲染”，Facebook 团队将其分解useQuery成了两个部分。它被分成了preloadQuery和usePreloadedQuery。这到底意味着什么？

`preloadQuery`

此 API 将获取数据并提供结果引用。它不会提供实际数据。

您可以在显示新 UI 的同一事件处理程序中调用此 API。例如，如果用户点击一个将触发导航到新页面的链接，我们处理该点击的事件处理程序将使用preloadQuery。将鼠标悬停在某个内容上以打开工具提示是另一个调用此 API 的示例。onHover事件处理程序将调用preloadQuery。

`usePreloadedQuery`

此 API 接收调用结果preloadQuery。它本身并不实际执行任何数据获取。它会检查的当前状态preloadQuery。如果已准备就绪，则显示结果。如果尚未准备就绪，则暂停。如果查询失败，我们可以抛出错误。

无论发生什么，usePreloadedQuery都不会触发新的获取。这使得它高效且可预测。

使用这两个 API 代替useQuery将提供如下所示的加载序列：

我强烈推荐你听听Joe Savona对我上面总结的概念的解释。他讲得更好，也更深入。这是我最喜欢的演讲之一，因为我对这种模式带来的可能性感到兴奋，迫不及待地想亲自尝试一下。

14. React 是虚构的

Jenn Creighton 的演讲是本次大会上我最喜欢的哲学演讲。她有创意写作的背景。我一直热爱创意写作。和 Jenn 一样，我也曾幻想成为一名作家。她在演讲中解释了一个概念，可以用一种有趣（且出乎意料）的方式转化为编程。

展示，而不是讲述

让我们看看传达相同含义的两种方式（由 Jenn 提供）。

她累了。

她的脚步比以前更重，当她拖着沉重的脚步走向床时，她的重量也随之增加，她脸朝下瘫倒在床垫上。

想法一样，对吧？她累死了。哪一个更强大？这显而易见。作为软件工程师，我们经常陷入“说教”的陷阱。我们不断抽象、抽象、再抽象，直到尽可能地做到DRY🌵 。

大多数时候，我都会尽量避免代码重复。这个原则很有道理，但就像写作规则一样，有时我们需要打破软件开发的规则。让我们比较一下两段实现相同结果的不同代码。

const Nav = ({ links }) => (
  <nav>
    {
      links.map(link => (
        <Link to={link.to}>{link.name}</Link>
      ))
    }
  </nav>
);

const Header = () => {
  const links = [
    { name: 'Home', to: '/home' },
    { name: 'Settings', to: '/settings' },
  ];

  return (
    <>
      <Nav links={links} />
    </>
  );
}

这看起来效果很好，但是如果我们想添加一个带有操作的导航项怎么办？例如登录按钮。

  const links = [
    { name: 'Home', to: '/home' },
    { name: 'Settings', to: '/settings' },
    { name: 'Login', to: '??' },
  ];

我们的Nav组件没有处理这种极端情况。我们可以轻松地实现一个方法来处理它，但这很容易失控。我们可以将Nav组件重构为如下所示：

const Nav = ({ links }) => (
  <nav>
    {
      links.map(link => {
        return link.to
          ? <Link to={link.to}>{link.name}</Link>
          : <a onClck={link.onClick}>{link.name}</Link>
      })
    }
  </nav>
);

这种方法可行，但在我们理解Nav组件之前，需要覆盖多少个边缘情况呢？我们可以用Header另一种方式重写组件。

const Header = () => {
  const links = [
    { name: 'Home', to: '/home' },
    { name: 'Settings', to: '/settings' },
    { name: 'Login', to: '??' },
  ];

  return (
    <nav>
      <Link to="/home">Home</link>
      <Link to="/settings">Settings</link>
      <a onClick={onSelectLogin}>Login</a>
    <nav/>
  );
}

我简化了 Jenn 在演讲中举的例子，但我认为它已经表达清楚了要点。第二个Header组件更容易理解。虽然我们现在可能在重复，但抽象并没有带来太多好处。如果我们想在某个Icon链接中添加一个组件，我们不必再处理组件中的所有边缘情况，只需将其添加到我们想要的位置即可。Nav

詹恩还引用了尼尔·盖曼的一句名言，我忍不住要分享一下。

请记住，迟早，在它达到完美之前，你必须放手，继续前进，开始写下一个东西。

在构建心理健康写作平台Wrabit的过程中，我一直在练习如何做到足够好。有时，这让我觉得自己不像个开发者。有时，这让我觉得自己很懒惰。最终，我会选择那些我容易理解、可以交付、并且以后随时可以重构的东西。

正如Jenn所说，重构并非失败。她的演讲将创意写作与编程巧妙地融合在一起，我一定会再看一遍。

15.用户体验驱动的流体动画

我还没来得及做太多动画。我设想未来能从 Dribbble 上找到一些很棒的 UI 设计（包括动画等等），然后把它们做成练习用的。动画绝对是设计界的一大亮点，但即使如此，我们也需要时刻关注用户体验。

和大多数演讲一样，Alex Holachek让我有了新的思考方式。我喜欢 UI 交互，它们让我内心感到温暖和温暖。但当我看到它们时，我却为自己没有考虑到所有用户而感到内疚。

对于使用诺基亚 6 的人来说，这些精美的动画效果如何？亚马逊售价 283.97 加元，在新 iPhone 上市之前，我完全可以负担得起这个价格。我猜很多人也和我一样。

Alex 提醒我，要多考虑一下平均水平。平均水平的手机，平均水平的网速。打造中端和高端产品总是没问题的。

此外，event.preventDefault()还会对您的滚动造成不良影响。

16. 重复真实体验

如果你还没注意到，今年的演讲内容丰富多彩。Luca Demasco向我们展示了他与Zach Rispoli共同开发Wick 编辑器的迭代过程，让内容保持新鲜感。

Wick 编辑器是一款免费的开源工具，可用于创建游戏、动画以及任何你能想到的内容。当 Luca 展示最新版本时，它的用户界面给我留下了深刻的印象。它看起来很直观，功能也很丰富。这在以前可不是件容易的事。

Luca 和朋友们通过不断迭代才取得了今天的成就。他们并非为了迭代而迭代。他们将 Wick 带入了许多不同的环境（学校、图书馆等），并将界面呈现给了许多不同的用户（初学者、中级用户、年轻人和老年人）。他们采取了高度集中的方法，并收集了反馈，最终成就了 Wick 的今天。

这个过程的坦诚启发了我，让我思考如何迭代自己的产品。如何快速上线产品并有目的地进行迭代？我没有这方面的经验，所以有时我会缺乏信心，但我很高兴能经历这个过程。看到像 Luca 这样的人分享他的经验，我深受鼓舞，也感谢会议期间大家的坦诚分享。

17.简单事物的复杂性

你用过react-select吗？没用过？你可能用过，只是你不知道而已。

该组件在 GitHub 上拥有超过1.8 万颗星，每周下载量高达 150万次。这可谓相当可观。

你可能认为一个简单的 React 组件不会那么复杂。当然，你错了。Jed Watson开发了一个美观且功能齐全的 React 组件。它功能丰富，开箱即用。

Jed 走过了漫长而艰辛的道路，才将React-select带到了今天的水平。他分享了开发一个广受欢迎的开源项目的深刻见解。他还展示了简单的事情往往可以变得非常复杂。

Jed 展示React-select 2.0 的演变过程时，我深受启发。他重申了重构的重要性，以及只要你不再追求完美，就能成就更多精彩。

18.美丽的透明度

政府支出是一个重要话题。我们有权了解我们的税款流向，以便监督政府的问责。

Lizzie Salita证明了政府网站也可以兼具高性能、易用性和美观性。当她演示USAspending.gov支出浏览器时，我着实感到很惊喜。将其与加拿大版本进行比较，你就能体会到 React 对用户体验的提升有多么巨大。

我对政治渐渐有了些了解。虽然我一直努力保持足够的信息以便投票，但我能做的事情还有很多。有了像USAspending.gov这样的工具，投票过程会更加轻松有趣。我认为我们应该继续开发这样的工具，让每个人都能随时了解情况，从而共同参与塑造我们的未来。

19. 奇迹驱动开发

会议的最后一个演讲真的让我大吃一惊。和Alex Anderson一样，我也是太空迷🚀。Alex 建造了一个名为Thorium的极其复杂的星际飞船模拟器。

钍模拟器使狮门航天中心等许多组织能够为各类人群提供与STEM相关的活动。这些航天中心让学生通过高度互动且具有教育意义的小组活动来成长。

React Conf 上，有不少演讲和嘉宾为公益事业做出了许多鼓舞人心的贡献。Alex 的工作之所以引人注目，是因为他的每一句话都洋溢着热情。他热爱自己的工作，是一位才华横溢的工程师。他正在利用现有的技术，为孩子和成人打造卓越的体验。

我从 Alex 的演讲中最喜欢的部分（我可能需要一段时间才能完全消化）是“奇迹驱动型发展”的概念。你有没有想过科技的可能性？你又能做什么呢？🤔

这些问题驱使我们创造有趣、愉悦、真正美好的体验。这些问题让 Facebook 以及世界各地公司的工程师能够用科技塑造我们的世界。

今年在 React Conf 上遇到的每一个人都让我受益匪浅。我很感激能够参加，心中充满了好奇和兴奋。

我迫不及待地想看看这个奇迹会促使我开发什么！

正如我之前提到的，这些只是我的一些收获。在为期两天的会议中，我们分享了许多库、技术和哲学思想。真希望我能把它们都记录下来！如果你明年去，你就会明白我的意思了。

如果您希望我进一步阐述这些想法，我非常乐意。请联系我！

最后，不提一下德文·林赛简直是罪过。她给我们带来了欢笑、糖果和一些内向的活动。没有她，这次会议就不一样了。

Le Talks（带时间戳）

为了让您观看愉快，以下是为期两天的会议的详细内容。观看所有演讲并关注演讲嘉宾！
️

第一天

第二天

文章来源：https://dev.to/amorriscode/19-takeaways-from-react-conf-2019-2m36