如果我有一个包含大量属性的类，那么将我修改的属性（例如）this.state.myProp1而不是this.myProp1放在一起似乎很麻烦。然后我需要在将它发送到setState之前复制它的任何属性（因为我不能直接改变它）。就像一个对象数组一样。
在某些时候，我会显示其中一些属性，这意味着我需要将所有类属性保存在此状态中，然后跟踪我需要刷新的内容，而不是刷新整个内容。
我更喜欢使用this.forceUpdate（）而让我的render（）直接引用类属性。为什么做出反应＆＃34; make＆＃34;人们使用this.state和setState。这是出于性能原因吗？
答案 0 :(得分：2)
setState（）将对组件状态的更改排入队列，并告诉React需要使用更新后的状态重新呈现此组件及其子组件。这是用于更新用户界面以响应事件处理程序和服务器响应的主要方法。
所以基本上setState可以告诉您何时重新渲染。 setState也是异步行为，仅在必要时更新状态。因此，如果您立即多次调用setState，它将仅在最后一次更新，以便最大限度地减少重新渲染次数，减少对浏览器的负担。如果没有setState并且每次数据更改时都会重新呈现，那么浏览器体验将非常糟糕。
如果您不想，则不必使用React this.state和setState。您始终可以使用redux或mobx来管理州。
永远不要直接改变this.state，因为之后调用setState（）可能会替换你所做的突变。
是的，这就是为什么你要把它发送到setState之前制作任何属性的副本
答案 1 :(得分：0)
答案 2 :(得分：0)
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent">
<android.support.v7.widget.Toolbar
android:id="@+id/toolbar"
android:layout_width="match_parent"
android:layout_height="?attr/actionBarSize"
android:background="@color/colorPrimary"></android.support.v7.widget.Toolbar>
<android.support.v4.widget.DrawerLayout
android:id="@+id/dl"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:gravity="start"
android:orientation="vertical"
tools:context="com.example.loveb.demo_viewpager.MainActivity">
<RelativeLayout
android:layout_width="match_parent"
android:layout_height="match_parent">
<android.support.design.widget.TabLayout
android:id="@+id/tablayout"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:background="@color/colorPrimary"
android:minHeight="?attr/actionBarSize"
android:theme="@style/Theme.AppCompat.Light.DarkActionBar">
</android.support.design.widget.TabLayout>
<android.support.v4.view.ViewPager
android:id="@+id/pager"
android:layout_width="match_parent"
android:layout_height="fill_parent"
android:layout_below="@+id/tablayout">
</android.support.v4.view.ViewPager>
</RelativeLayout>
<android.support.design.widget.NavigationView
android:id="@+id/navview"
android:layout_width="wrap_content"
android:layout_height="match_parent"
android:layout_gravity="start"
app:headerLayout="@layout/drawer_layout"
app:menu="@menu/menu">
</android.support.design.widget.NavigationView>
</android.support.v4.widget.DrawerLayout>
</RelativeLayout>
必须使用setState的主要原因是它的异步执行，来自反应文档：
React故意“等待”，直到所有组件在开始重新渲染之前在其事件处理程序中调用setState（）。这可以通过避免不必要的重新渲染来提高性能。
如果状态对象是同步更新的，则会导致一致性问题，因为在重新呈现父组件之前不会更新setState，因此，直接改变props会导致道具和状态。
如需进一步参考，您可以查看此this Github主题。
this.state this.state对象的主要优点是其不可变性，这是组件属性无法实现的，state和props之间的责任分离也是如此更容易处理和单独更新。
答案 3 :(得分：0)
为什么反应“make”的人会使用this.state和setState。这是出于性能原因吗？
这是一个很好的问题 - 来自J. Pichardo的现有答案是完全正确的，但我想更深入地解决原因 - 而不是什么或如何。
真的是一个更好的问题 - 为什么React存在？根据{{3}}
React的单向数据流使事情变得更简单，更可预测，并且更不容易出错。数据流的一种方式极大地简化了您对状态的思考，因为没有视图可以直接改变状态。视图只能将动作发送到全局状态存储区。
React有很多原因可以说它是一个有用的UI库。但是关于你的问题 - 单向数据流 - 这是主要原因。
关系用户界面变得复杂。当应用程序必须使用，显示和更新即使只是适量的关系数据并且在多个元素中显示该信息时，事情可能会变得混乱。
使用状态和道具React的方式可以区分并保证UI的一部分是否只接收要显示的数据，或者是否也可以更改它。
如果您只是将这些数据存储在一个随机密钥中，那么您就无法知道该值是否已更改以及更改了哪些值。通过以这种方式将您的状态与组件分离，它将数据与元素分离，使得在元素之间共享数据变得更加容易，并且还以不同的方式更改数据。
根据耦合对象接口上的this article，紧耦合的实体是坏的，因为：紧密耦合对象是一个需要了解其他对象的对象，通常高度依赖于彼此的接口。当我们在紧密耦合的应用程序中更改一个对象时，通常需要更改许多其他对象。在小型应用程序中没有问题我们可以轻松识别变化。但是在大型应用程序的情况下，每个消费者或其他开发人员并不总是知道这些相互依赖性，或者未来有很多机会发生变化。
这非常适用于UI开发。在我看来，这就是为什么不设置状态会在以后引起你的痛苦。