在你崩溃之前，这8种做法会让React应用程序先崩溃
|
在过去有条件地渲染组件的黄金时期，有人曾做过一件事，那就是检查数据是否使用Object.keys填充到对象中。如果有数据，那么如果条件通过，组件将继续渲染。
假设调用了某个API，并在响应的某个地方接收了作为对象的项。话虽如此，乍一看似乎完全没有问题。项目的预期类型是对象，所以用Object.keys完全没问题。毕竟，如果出现错误并转化为falsey值，的确可以通过把项初始化为空对象来进行防御。 但服务器不总是返回相同的结构。如果将来项变成数组会怎样?Object.keys(items)不会崩溃，但会返回一个奇怪的输出，比如[“0”、“1”、“2”]。被该数据渲染的组件该如何反应呢? 但这还不是最糟的部分。代码片段中最糟的是，如果属性里收到的项是空值，那么项甚至不会初始化为默认值。 那么在开始使用应用程序前，就崩溃了：
再说一遍，请小心点! 4. 在渲染前粗心地检查数组是否存在 这可能和第3条的情况非常相似，但是数组和对象经常可以互换使用，所以应该单列出来。 如果你有这样做的习惯：
那么至少确保有单元测试，始终密切关注这段代码，或者在传递给渲染函数前及早正确地处理arr,否则如果arr变成对象文字，应用程序就会崩溃。当然， &&操作符会认为它是真实的，并尝试.map对象文字，这最终导致整个应用程序的崩溃。 所以请牢记于心。节省你的精力以及挫败感，把它留给更值得你特别关注的大问题吧! 5. 没有使用Linter 如果在开发应用程序时，没有使用任何类型的linter，或者根本不知道它们是什么，你必须知道为什么它们在开发中很有用。 用来辅助开发流程的linter是ESLint(https://eslint.org/?source=post_page---------------------------)，这是一个著名的JavaScript的linting工具，它允许开发人员在不执行代码的情况下发现问题。 这个工具非常有用，它就像半个导师一样，及时纠正错误——就好像有人在指导你一样。它甚至描述了为什么你的代码可能是错误的，并建议你应该做什么。 这里有一个例子：
关于ESLint最酷的是，如果不喜欢某些规则或是不同意其中的一些规则，可以禁用这些规则，这样它们就不会在开发时显示为 linting警告/错误了。 6. 在渲染列表时进行解构 过去有些人出现过这种情况，而且很难检测到漏洞。基本上，如果有一个项目列表，并且准备渲染每个项目的一堆组件，如果列表中有一个项目不是期待值，那么应用程序会出现漏洞。如果应用程序不知道如何处理值类型，就有可能会崩溃。 这里有一个例子：
代码可以成功地运行。来看看API调用，而不是返回这个——
——如果在API客户端出现了意外情况并且返回这个数组时，如何解决这个问题呢?
那么应用程序就会崩溃，因为它不知道如何处理：
（编辑：威海站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
