React 中的 props 不应该是 changed/mutated 的原因是因为 React 希望元素尽可能可预测吗?
Is the reason props in React shouldn't be changed/mutated is because React wants elements to be as predictable as possible?
来自 React 文档。
Conceptually, components are like JavaScript functions. They accept
arbitrary inputs (called “props”) and return React elements describing
what should appear on the screen.
正在考虑:
function Welcome(props) {
return <h1>Hello, {props.name}</h1>;
}
或
class Welcome extends React.Component {
render() {
return <h1>Hello, {this.props.name}</h1>;
}
}
将使我们能够做到这一点:
<Welcome name="Luke" />;
<Welcome name="Leia" />;
在DOM,
中随意使用
你好,卢克
你好,莱娅
现在当人们规定不应更改道具时,这是有道理的,原因是在我看来就像更改图像标签的属性值一样?
HTML:
<img id="Executor" alt="Picture of Executor" src="/somepath/vaders-star-destroyer-executor.jpg"/>
JS:
与此同时,很久以前在一个遥远的星系中的 Javascript 文件中...
var imageOfVadersStarDestroyer = document.getElementById('Executor');
imageOfVadersStarDestroyer.src = "/somepath/vaders-star-destroyer-avenger.jpg"
因为如果我们不断更改元素属性值,这会导致混乱和渲染速度变慢?
所以 React 中规定永远不要更改 props 的原因是因为库正在尝试使元素尽可能可预测吗?
never change props in React
意味着你不应该做 this.props.name = "userName"
因为 React 的 one way data binding, props
是 read only
, 要更新组件的道具, 你应该从将执行此操作的父级(在父级中),或者如果您使用的是 redux 则分派一个操作,props
中的更改将触发重新渲染
props
在这种情况下是一个常量。您将始终在您的组件中需要它。
但是有一种更简洁的方式来写它甚至可以省略它。
函数表达式的常规方法
(与您的示例相同)
function Welcome(props) {
return <h1>Hello, {props.name}</h1>;
}
ES6 对象销毁 - 显式
function Welcome(props) {
const {name} = pros
return <h1>Hello, {name}</h1>;
}
ES6 对象销毁 - 隐式、更简洁的方式
function Welcome({name}) {
return <h1>Hello, {name}</h1>;
}
当然,您可以使用 class 方式,这需要使用 this.props.yourAttr
但是,在 create-react-app 的新版本 3 中,将 class 组件更改为功能组件。您可以在 Github here.
上看到这个确切的修改
您可能需要在旧的和良好的 MDN 链接中了解更多关于销毁分配的信息 here or an in-depth approach both array and object destructuring here。
在 React 之外设置道具是危险的,应该避免。为什么?主要原因是它不会触发重新渲染。因此会出现错误和意外行为。
重新渲染
大多数时候,props 是作为状态存储在父组件中的数据,通过调用 setState()
(或 React.useState()
返回的第二个函数)来操作。一旦 setState()
被调用,React 将重新渲染并计算引擎盖下发生的变化,以及最新的道具和状态。手动为 props 赋值,因此不会通知 React 数据已更改并且必须重新渲染某些内容。
好的做法
将 props 设置为只读允许 React 组件尽可能纯净,这显然是一个很好的做法,即使在编写纯 JS 时也是如此。数据不会意外更改,只能通过调用 setState()
来完成(您可能听说过 单一事实来源 ,这正是 React 试图利用的).
想象一下,您注意到应用程序出现问题并且显示给最终用户的数据与源数据完全不同,试图找出数据在哪里被操纵会很痛苦,不是吗? :)
来自 React 文档。
Conceptually, components are like JavaScript functions. They accept arbitrary inputs (called “props”) and return React elements describing what should appear on the screen.
正在考虑:
function Welcome(props) {
return <h1>Hello, {props.name}</h1>;
}
或
class Welcome extends React.Component {
render() {
return <h1>Hello, {this.props.name}</h1>;
}
}
将使我们能够做到这一点:
<Welcome name="Luke" />;
<Welcome name="Leia" />;
在DOM,
中随意使用你好,卢克
你好,莱娅
现在当人们规定不应更改道具时,这是有道理的,原因是在我看来就像更改图像标签的属性值一样?
HTML:
<img id="Executor" alt="Picture of Executor" src="/somepath/vaders-star-destroyer-executor.jpg"/>
JS:
与此同时,很久以前在一个遥远的星系中的 Javascript 文件中...
var imageOfVadersStarDestroyer = document.getElementById('Executor');
imageOfVadersStarDestroyer.src = "/somepath/vaders-star-destroyer-avenger.jpg"
因为如果我们不断更改元素属性值,这会导致混乱和渲染速度变慢?
所以 React 中规定永远不要更改 props 的原因是因为库正在尝试使元素尽可能可预测吗?
never change props in React
意味着你不应该做 this.props.name = "userName"
因为 React 的 one way data binding, props
是 read only
, 要更新组件的道具, 你应该从将执行此操作的父级(在父级中),或者如果您使用的是 redux 则分派一个操作,props
中的更改将触发重新渲染
props
在这种情况下是一个常量。您将始终在您的组件中需要它。
但是有一种更简洁的方式来写它甚至可以省略它。
函数表达式的常规方法
(与您的示例相同)
function Welcome(props) {
return <h1>Hello, {props.name}</h1>;
}
ES6 对象销毁 - 显式
function Welcome(props) {
const {name} = pros
return <h1>Hello, {name}</h1>;
}
ES6 对象销毁 - 隐式、更简洁的方式
function Welcome({name}) {
return <h1>Hello, {name}</h1>;
}
当然,您可以使用 class 方式,这需要使用 this.props.yourAttr 但是,在 create-react-app 的新版本 3 中,将 class 组件更改为功能组件。您可以在 Github here.
上看到这个确切的修改您可能需要在旧的和良好的 MDN 链接中了解更多关于销毁分配的信息 here or an in-depth approach both array and object destructuring here。
在 React 之外设置道具是危险的,应该避免。为什么?主要原因是它不会触发重新渲染。因此会出现错误和意外行为。
重新渲染
大多数时候,props 是作为状态存储在父组件中的数据,通过调用 setState()
(或 React.useState()
返回的第二个函数)来操作。一旦 setState()
被调用,React 将重新渲染并计算引擎盖下发生的变化,以及最新的道具和状态。手动为 props 赋值,因此不会通知 React 数据已更改并且必须重新渲染某些内容。
好的做法
将 props 设置为只读允许 React 组件尽可能纯净,这显然是一个很好的做法,即使在编写纯 JS 时也是如此。数据不会意外更改,只能通过调用 setState()
来完成(您可能听说过 单一事实来源 ,这正是 React 试图利用的).
想象一下,您注意到应用程序出现问题并且显示给最终用户的数据与源数据完全不同,试图找出数据在哪里被操纵会很痛苦,不是吗? :)