gpt4 book ai didi

ReactJS 应用程序 - 弹性 VS 快速失败

转载 作者:行者123 更新时间:2023-11-28 19:43:27 26 4
gpt4 key购买 nike

我正在开发 React 应用程序,这是我用于我的组件的方法:我使用 PropTypes 验证来验证我希望收到的 Prop ,但我仍然分配默认值以便避免在接收到的数据出现问题时中断。

最近我被告知我们不应该那样做,props 是我们对父级的期望,如果不遵守契约(Contract)则让组件中断。

哪种方法是正确的,优缺点是什么?

我的一些思考值得深思......

按照我最初的方法,在测试中我明确地测试了传递给被测组件的一些无效数据的默认值,并期望仍然打印出有效的快照。测试不会因为一些错误的数据而失败,但我会打印出 PropTypes 验证警告(如果需要的话可以将其转换为错误 - 我认为 - 或者在测试中将它们静音以模拟它们)。

这些在测试和实际应用程序中的警告比仅仅看到一个错误说“无法从中读取'someProp'更简洁明了undefined"或类似的(并让 React 渲染周期中断)。propType 验证直接并清楚地告诉你你做错了什么(你将错误的类型作为 prop 传递,prop 完全丢失,等等)。

改用第二种方法测试失败,因为应用程序中断了。我认为只有当测试覆盖率真的很好 (90/100%) 时,这才是一个好方法,否则这是一种风险——它可能会上线并在边缘情况下中断,从而破坏产品声誉。重构或需求更改经常发生,一些边缘情况可能会以不需要的数据结束,这些数据会破坏应用程序并且未在自动或手动测试中捕获。

这意味着当应用程序处于事件状态时,由于某些错误数据,代码可能会在父组件中中断,并且整个应用程序将停止工作,而在第一种情况下,应用程序是有弹性的并且只是显示以受控的方式一些空白字段。

想法?

下面是一个简化的例子:

react 组件

import React from 'react';
import PropTypes from 'prop-types';
import styles from './styles.css';

export const App = ({ person : { name, surname, address, subscription } = {} }) => (
<div style={styles.person}>
<p> {person.name} </p>
<p> {person.surname} </p>
<p> {person.address} </p>
<div>
{
person.subscription &&
<Subscription details={person.subscription} />
}
</div>
</div>
);

// PS. this is incorrect in this example (as pointed out in an answer). Real code used inline initialization.
// App.defaultProps = {
// person: { subscription: undefined },
// };

App.propTypes = {
person: PropTypes.shape({
name: PropTypes.string.isRequired,
surname: PropTypes.string.isRequired,
address: PropTypes.string,
subscription: PropTypes.object,
}).isRequired,
};

测试

import React from 'react';
import { shallow } from 'enzyme';
import { mockOut } from 'testUtils/mockOut';

import { App } from '../index.js';

describe('<App>', () => {
mockout(App, 'Subscription');

it('renders correctly', () => {
const testData = {
name: 'a name',
surname: 'a surname',
address: '1232 Boulevard Street, NY',
subscription: { some: 'data' },
}
const tree = shallow(<App person={testData} />);
expect(tree.html()).toMatchSnapshot();
});

it('is resilient in case of bad data - still generates PropTypes validation logs', () => {
const tree = shallow(<App person={undefined} />);
expect(tree.html()).toMatchSnapshot();
});
});

更新:

问题的主要焦点是为标有 isRequired 的 props 分配默认值是否正确(而不是让它们的缺失破坏组件)

最佳答案

Recently I've been told that we should not do that, that the props are what we expect from the parent and if the contract is not respected to let the component break.

确切地说,如果组件中的 props 是可选的,组件(呈现实际 View 的人)应该处理它,而不是父组件。

但是,您可能会遇到这样一种情况,即如果任何子组件契约(Contract)被破坏,父组件就会被破坏。我可以想到两种可能的方法来处理这种情况-

  1. 将错误通知器传递给子组件,如果出现任何问题,子组件可以向父组件报告错误。但这不是干净的解决方案,因为如果有 N 个 child 并且如果有多个 child 会向 parent 中断(或报告错误),您将毫 headless 绪并且难以管理。[这根本无效但写在这里是因为我在学习 React 的时候经常遵循这个:P]

  2. 在父组件中使用try/catch,不盲目信任任何子组件,并在出现问题时显示错误消息。当您在 all 组件中使用 try/catch 时,您可以在任何契约(Contract)未履行时安全地从组件中抛出错误。

Which approach is correct and what are the pros and cons?

IMO,第二种方法(组件中的 try/catch 并在未满足要求时抛出错误)是有效的并且将解决所有问题。在未传递 props 时为组件编写测试时,加载组件时可能会出现错误。

更新

如果你使用的是 React > 16,here是处理错误的方式。

关于ReactJS 应用程序 - 弹性 VS 快速失败,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/46597197/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com