我目前正在使用 React JS 和 React Native 框架进行开发。在半路上，我遇到了不可变性或者Immutable-JS库，当我在阅读Facebook的Flux和Redux实现时。
问题是，为什么不可变性那么重要？改变对象有什么不对吗？这难道不会使事情更加简单吗？
举个例子，我们考虑一个简单的新闻阅读器应用程序，打开屏幕是新闻标题的列表视图。
如果我设置一个对象数组初始值，我就不能对它进行操作。这就是不可变性原则所说的，对吗？（请纠正我如果我错了）。 但是，如果我有一个需要更新的新闻对象呢？通常情况下，我可以把这个对象添加到数组中。 在这种情况下，我该怎么办？删除存储并重新创建它吗？ 把一个对象添加到数组中不是一个更少消耗资源的操作吗？
shouldComponentUpdate通过比较状态对象来检查状态是否相同，并防止不必要的渲染。如果我最初设置一个对象值的数组，我就不能操纵它。这就是不变性原则所说的，对吗？（如果我错了，请纠正我）。但是，如果我有一个新的News对象需要更新怎么办？通常情况下，我只需将对象添加到数组中即可。在这种情况下，我该如何实现？删除存储并重新创建它吗？将对象添加到数组中不是一项更少的操作吗？
是的，这是正确的。如果您不清楚如何在应用程序中实现此功能，我建议您查看redux如何实现此功能，以熟悉核心概念，这对我很有帮助。
我喜欢使用Redux作为示例，因为它支持不可变性。它有一个单一的不可变状态树（称为store），所有状态更改都通过分派操作显式进行，这些操作由接受先前状态和操作的减速器处理（一次一个），并返回应用程序的下一个状态。您可以在此处阅读更多关于其核心原则。
Egghead.io上有一门出色的Redux课程，作者Dan Abramov解释了以下原则（我稍微修改了代码以更好地适应情景）：
import React from 'react';
import ReactDOM from 'react-dom';
// Reducer.
const news = (state=[], action) => {
switch(action.type) {
case 'ADD_NEWS_ITEM': {
return [ ...state, action.newsItem ];
}
default: {
return state;
}
}
};
// Store.
const createStore = (reducer) => {
let state;
let listeners = [];
const subscribe = (listener) => {
listeners.push(listener);
return () => {
listeners = listeners.filter(cb => cb !== listener);
};
};
const getState = () => state;
const dispatch = (action) => {
state = reducer(state, action);
listeners.forEach( cb => cb() );
};
dispatch({});
return { subscribe, getState, dispatch };
};
// Initialize store with reducer.
const store = createStore(news);
// Component.
const News = React.createClass({
onAddNewsItem() {
const { newsTitle } = this.refs;
store.dispatch({
type: 'ADD_NEWS_ITEM',
newsItem: { title: newsTitle.value }
});
},
render() {
const { news } = this.props;
return (
<div>
<input ref="newsTitle" />
<button onClick={ this.onAddNewsItem }>add</button>
<ul>
{ news.map( ({ title }) => <li>{ title }</li>) }
</ul>
</div>
);
}
});
// Handler that will execute when the store dispatches.
const render = () => {
ReactDOM.render(
<News news={ store.getState() } />,
document.getElementById('news')
);
};
// Entry point.
store.subscribe(render);
render();
简而言之：在JavaScript中，不可变性更多地是一种时尚潮流，而非必需品。如果你正在使用React，它确实为一些令人困惑的设计选择提供了一个巧妙的解决方案来管理状态。然而，在大多数其他情况下，它并不能带来足够的价值，而只会引入复杂性，更多地用于填充简历，而不是满足实际客户需求。
长篇回答请见下文。
为什么在JavaScript中不可变性如此重要（或需要）？
好吧，我很高兴你问到了这个问题！
不久前，一个非常有才华的家伙叫做Dan Abramov写了一个名为Redux的JavaScript状态管理库，它使用纯函数和不可变性。他还制作了一些非常酷的视频，使这个想法变得非常容易理解（并且销售）。
时机恰到好处。Angular的新奇感正在消退，而JavaScript世界正准备专注于最新的、具有适度酷炫程度的东西，而这个库不仅创新，而且与另一个硅谷巨头推销的React完美契合。
尽管令人沮丧，但在JavaScript世界中，时尚统治着。现在，Abramov被称为半神，并且我们这些凡人必须屈服于不可变性之道……无论它是否有意义。
改变对象有何不妥之处？
没有！
实际上，程序员一直以来都在改变对象，嗯... 自从存在对象以来已经有了50多年的应用开发。
而为什么要把事情弄复杂呢？当你有一个对象cat并且它死去时，你真的需要第二个cat来跟踪这个变化吗？大多数人只会说cat.isDead = true就行了。
（改变对象）难道不让事情变得简单吗？
是的！..当然会！
在JavaScript中，特别是在实践中，最常用于呈现某些在其他地方维护的状态的视图（比如数据库）。(话虽如此，在 Web Workers 中使用纯函数也有优势，就是你不需要对主线程上的对象进行调整的期望。)
2) 不可变性（Immutability）可以（在某种程度上）避免应用程序状态的竞态条件。
这才是关键，大多数（React）开发者会告诉你，不可变性和函数式编程可以以某种方式实现让应用程序状态变得可预测的魔法。
当然，这并不意味着你可以避免数据库中的 竞态条件，要做到这一点，你需要协调所有浏览器中的所有用户，为此，你需要像WebSockets这样的后端推送技术（下面将详细介绍），它将向运行该应用程序的每个人广播更改。
这也不意味着 JavaScript 存在某种固有问题，需要通过不可变性来使应用程序状态变得可预测，任何在 React 之前编写过前端应用程序的开发者都会告诉你这一点。
这个相当令人困惑的说法简单地意味着，如果你使用React，你的应用程序容易出现竞态条件，但是不可变性可以帮助你摆脱这种痛苦。为什么？因为React很特殊...它首先被设计为一个高度优化的渲染库，而状态管理则被削弱到这个目标，因此组件状态通过异步事件链（也称为"单向数据绑定"）进行管理，以优化渲染，但你无法控制它，并且依赖于你记住不直接改变状态...3) 竞态条件绝对是不好的。
嗯，如果您使用React可能会出现这种情况。但是，如果选择其他框架，它们就很少见。
此外，您通常还有更大的问题要处理...像依赖地狱这样的问题。像臃肿的代码库。像CSS加载不成功。像缓慢的构建过程或者被困在导致迭代几乎不可能的单块式后端。像经验不足的开发人员不明白发生了什么，并把事情搞得一团糟。
你知道的。现实。但嘿，谁在乎呢？
4) 不可变性利用引用类型来减少跟踪每个状态变化的性能影响。一旦这个概念（状态是事件的流动，而不是粗糙的记录集合代表最新视图）被理解，不可变的世界就变成了一个令人惊叹的居住之地。一个超越时间本身的奇迹和可能性之地，一个event-sourced的乐土。当正确实施时，这可以使实时应用程序更容易实现，只需将事件的流动广播给所有感兴趣的人，他们可以建立自己的表示并将自己的变化写回到共同的流中。
但在某个时候，你会醒悟到所有那些奇妙和魔力并非免费获取。与你热情的同事不同，你的利益相关者（是的，就是支付你工资的人）对哲学或时尚不太关心，他们更在意为产品付费建设所花费的金钱。底线是，编写不可变代码更加困难，而破坏它则更容易，此外，如果没有后端支持，拥有不可变前端也毫无意义。当（如果！）你最终说服你的利益相关者通过推送技术如WebSockets发布和消费事件时，你会发现在生产环境中扩展的困难之处。
现在，如果你有幸能在工作中作出选择，那么请尽量运用你的智慧（或者不运用），为支付你工资的人做正确的事情。你可以基于自己的经验、直觉，或者周围发生的事情来决策（不可否认的是，如果每个人都在使用React/Redux，那么有一个合理的论点是更容易找到资源继续你的工作）。另外，你也可以尝试以简历为驱动的开发或以炒作为驱动的开发方法。它们可能更适合你。
简而言之，关于不变性的好处就是，至少会让你在同行中时尚一段时间，直到下一个狂热出现，到那时你会庆幸继续前进。
var originalItems = Immutable.List.of(1, 2, 3);
var newItems = originalItems.push(4, 5, 6);
const car = { brand: 'Ferrari' };
doSomething(car);
console.log(car); // { brand: 'Fiat' }
如上例所示，传递可变结构总是可以通过具有不同结构来完成。函数doSomething正在改变从外部给出的属性。对于代码没有信任，你真的不知道自己拥有什么和将要拥有什么。所有这些问题之所以发生，是因为：可变结构表示指向内存的指针。
不可变性意味着更改不是在同一个对象、结构上进行的，而是在新的对象、结构上进行的。这是因为引用不仅表示内存指针，还表示值。每次更改都会创建一个新值，而不会触及旧值。这些明确的规则让代码具有可预测性和信任度。函数是安全使用的，因为它们处理自己版本的自己值，而不是突变。
使用值而不是内存容器可以确保每个对象表示特定的不可更改的值，并且可以安全地使用它。
不可变结构体代表值。
我在媒体文章中更深入地探讨了这个主题 - https://medium.com/@macsikora/the-state-of-immutability-169d2cd11310
为什么在JavaScript中不变性如此重要（或必需）？
不变性可以在不同的上下文中进行跟踪，但最重要的是对应用程序状态和应用程序UI进行跟踪。
我认为JavaScript Redux模式是非常流行和现代的方法，因为你提到了它。
对于UI，我们需要使其可预测。如果 UI = f(application state)，那么它将是可预测的。
应用程序（在JavaScript中）通过使用reducer函数实现的操作来改变状态。
reducer函数只需获取操作和旧状态并返回新状态，保持旧状态不变即可。
new state = r(current state, action)
UI = f(state)。因此，您可以轻松地撤销/重做。
class Foo {
baz() {
// ....
}
bar() {
// ....
}
}
const f = new Foo();
可能需要调用baz()来使对象处于有效状态，以便正确调用bar()。但是如何知道这一点呢？
f.baz();
f.bar(); // this is ok
f.bar();
f.baz(); // this blows up
Foo是不可变的，那么这个问题就不存在了。可以安全地假设我们可以按任何顺序调用baz或bar，因为类的内部状态不会改变。我的另一个回答从非常实际的角度回答了问题，我仍然喜欢它。我决定添加这个作为另一个答案，而不是那个答案的补充，因为这是一篇乏味的哲学漫谈，希望也回答了问题，但不太适合我的现有答案。
即使在小型项目中，不变性也可能会有用，但不要假设它适用于您，因为它存在。
注意：为了本回答的目的，我使用“纪律”一词来表示出于某种好处而进行的自我否定。
这类似于另一个问题：“我应该使用TypeScript吗？JavaScript中类型很重要吗？”答案也类似。考虑以下情况:
你是一个JavaScript/CSS/HTML代码库的唯一作者和维护者，代码约5000行。你的半技术老板读到关于Typescript作为新热门技术的文章，并建议我们可能需要转移到Typescript，但决定权在你手中。所以你阅读相关文献并试用它等等。
现在你需要做出选择，你要转移到Typescript吗？
TypeScript具有一些引人注目的优点：智能感知、早期发现错误、预先指定API、易于在重构中修复问题、更少的测试等。但TypeScript也有一些成本：某些非常自然和正确的JavaScript语言习惯在它不是特别强大的类型系统中可能很棘手，注释增加了代码行数，重写现有代码库的时间和精力，构建流程中的额外步骤等等。更根本的是，它为实现正确的JavaScript程序划定了一个子集，以换取您的代码更可能是正确的承诺。它是任意地有限制性的，这正是重点所在：你施加一些纪律来限制自己（希望不会打自己的脚）。
回到问题本身，在上述段落的背景下重新表述问题：这值得吗？
在所描述的情况下，我认为如果您非常熟悉小型到中型JS代码库，则使用TypeScript的选择更多是美学上的考虑而不是实际上的考虑。这没关系，美学并没有错，只是并不一定令人信服。
情景B:
你换了工作，现在是Foo Corp的业务线程序员。你在一个10人团队中工作，负责一个约90000行（还在不断增加）的JavaScript/HTML/CSS代码库，涉及babel、webpack、一套polyfills、各种插件的react、一个状态管理系统、约20个第三方库、约10个内部库、类似于linter的编辑器插件，其中包括内部样式指南的规则等等。
回到你只写了5,000行代码时，这并不重要。甚至文档也不是那么重要，即使你在6个月后重新回到代码的某个部分，你也可以很容易地找到答案。但现在，遵循规范不仅仅是好习惯，而是必要的。这种规范可能不包括Typescript，但很可能会涉及到某种形式的静态分析，以及所有其他形式的编码规范（文档、样式指南、构建脚本、回归测试、CI）。遵循规范已经不再是一种奢侈，而是一种必需。
这一切都适用于1978年的GOTO：当你使用C语言开发一个小型的二十一点游戏时，你可以使用GOTO和意大利面条般的逻辑，但是随着程序变得越来越庞大和雄心勃勃，过度使用GOTO就无法持续下去了。今天所有这些都适用于不可变性。
就像静态类型一样，如果你不在一个由工程师维护/扩展的大型代码库上工作，使用不可变性基本上只是出于审美考虑：它的好处仍然存在，但可能还没有超过成本。
但就像所有有用的规范一样，总会到达一个不可避免的点。如果我想保持健康的体重，那么对冰淇淋的纪律可能是可选的。但如果我想成为一名竞技运动员，吃不吃冰淇淋的选择就要根据我的目标而定了。如果你想用软件改变世界，不可变性也许是你需要遵循的规范之一，以避免它在自己的重量下崩溃。
以一个例子来说明：
const userMessage = {
user: "userId",
topic: "topicId"
content: {}
}
validateMessage(userMessage)
saveMessage(userMessage)
sendMessageViaEmail(userMessage)
**sendMessageViaMobilePush(userMessage)**
console.log(userMessage) // => ?
现在回答一些问题：
{
id: "xxx-xxx-xxx-xxx", //set by ..(Answer for question 3)
user:"John Tribe", //set by sendMessageViaEmail
topic: "Email title", //set by sendMessageViaEmail
status: FINAL, //set by saveMessage or could be set by sendMessageViaEmail
from: "..", //set by sendMessageViaEmail
to:"...", //set by sendMessageViaEmail
valid:true, //set by validateMessage
state: SENT //set by sendMessageViaEmail
}
Surprised?? Me too :d. But this is normal with mutability in javascript.
(in Java too but a bit in different way. When You expect null but get some object). What is under userMessage on same line in immutable code?
const userMessage = {
user: "userId",
topic: "topicId",
content: {}
}
Easy right ?Can You guess by which method "id" is updated in mutable code in Snippet 1 ??
By sendMessageViaEmail.
Why?
Why not?
Well it was at first updated by saveMessage,
but then overridden by sendMessageViaEmail.In mutable code people didn't received push messages (sendMessageViaMobilePush). Can You guess why ??
because I am amazing developer :D and I put safety check in method sendMessageViaMobilePush(userMessage)
function sendMessageViaMobilePush(userMessage) {
if (userMessage.state != SENT) { //was set to SENT by sendMessageViaEmail
send(userMessage)
}
}
Even if You saw this method before,
was this possible for You to predict this behavior in mutable code ?
For me it wasn't.