我已经为可变(或不可变)状态创建了一个框架不可知的开源(MIT)库，它可以取代所有那些不可变的存储，如库(redux, vuex等…)

对我来说，不可变状态是丑陋的，因为有太多的工作要做(很多简单的读/写操作)，代码可读性较差，大数据集的性能不能接受(整个组件重新渲染:/)。

对于深度状态观察者，我只能用点表示法更新一个节点并使用通配符。我还可以创建状态的历史记录(撤销/重做/时间旅行)，只保留那些已经改变的具体值{path:value} =较少的内存使用。

使用深度状态观测器，我可以对事情进行微调，并对组件行为进行粒度控制，因此性能可以大幅提高。代码可读性更强，重构也更容易——只需要搜索和替换路径字符串(不需要更改代码/逻辑)。

从前，线程之间的数据同步出现了一个问题。这个问题非常麻烦，有10多个解决方案。有些人试图从根本上解决这个问题。它是函数式编程诞生的地方。这就像马克思主义。我不明白Dan Abramov是怎么把这个想法卖给JS的，因为它是单线程的。他是个天才。

我可以举个小例子。在gcc中有一个属性__attribute__((pure))。编译器试图解决你的函数是否是纯的，如果你不特别声明它。你的函数可以是纯的，即使你的状态是可变的。不可变性只是保证你的函数是纯粹的100多种方法中的一种。实际上95%的函数都是纯函数。

如果你真的没有明确的理由，你就不应该使用任何限制(比如不可变性)。如果你想“撤销”某些状态，你可以创建事务。如果你想简化通信，你可以发送带有不可变数据的事件。这取决于你。

我写这条信息来自后马克思主义共和国。我相信任何思想的激进化都是错误的。

Javascript中不可变的另一个好处是减少了时间耦合，这对设计有很大的好处。考虑一个具有两个方法的对象的接口:

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是安全的，因为类的内部状态不能改变。

我认为支持不可变对象的主要原因是保持对象的状态有效。

假设我们有一个叫arr的物体。当所有项都是相同的字母时，该节点有效。

// this function will change the letter in all the array
function fillWithZ(arr) {
    for (var i = 0; i < arr.length; ++i) {
        if (i === 4) // rare condition
            return arr; // some error here

        arr[i] = "Z";
    }

    return arr;
}

console.log(fillWithZ(["A","A","A"])) // ok, valid state
console.log(fillWithZ(["A","A","A","A","A","A"])) // bad, invalid state

如果arr成为一个不可变对象，那么我们将确保arr始终处于有效状态。

为什么不可变性在JavaScript中如此重要(或需要)?

不可变性可以在不同的上下文中跟踪，但最重要的是根据应用程序状态和应用程序UI跟踪它。

我认为JavaScript Redux模式是非常流行和现代的方法，因为你提到了。

对于UI，我们需要让它具有可预测性。 如果UI = f(应用程序状态)，这将是可预测的。

应用程序(在JavaScript中)通过使用reducer函数实现的操作来改变状态。

reducer函数只是接受动作和旧状态，并返回新状态，保持旧状态不变。

new state  = r(current state, action)

好处是:你可以穿越状态，因为所有的状态对象都被保存了，你可以在任何状态下呈现应用程序，因为UI = f(state)

所以你可以很容易地撤销/重做。

碰巧创建所有这些状态仍然可以是内存高效的，与Git类似是很好的，我们在Linux操作系统中有类似的符号链接(基于索引节点)。

问题是，为什么不变性如此重要?改变对象有什么错?这不是让事情变得简单了吗?

关于可变性

从技术角度来看，可变性并没有错。它是快速的，它是重复使用内存。开发人员从一开始就习惯了它(我记得)。可变性的使用存在问题，也会带来一些麻烦。

如果object不与任何东西共享，例如存在于函数的作用域中并且不对外公开，那么就很难看到不变性的好处。在这种情况下，不可变是没有意义的。一成不变的感觉始于某些东西被分享。

可变性头痛

可变的共享结构很容易产生许多陷阱。对访问引用的代码的任何部分的任何更改都会影响到具有此引用可见性的其他部分。这种影响将所有部分连接在一起，即使它们不应该意识到不同的模块。一个函数的突变可能会导致应用程序的完全不同部分崩溃。这样的事情是一个糟糕的副作用。

其次经常与突变的问题是损坏的状态。当突变过程中途失败，一些字段被修改，一些字段没有被修改时，就会发生损坏状态。

更重要的是，通过突变很难追踪变化。简单的参考检查不会显示出差异，要知道发生了什么变化需要做一些深入的检查。此外，为了监测变化，还需要引入一些可观察的模式。

最后，突变是信任缺失的原因。如果某个结构可以变异，你怎么能确定它有你想要的价值。

const car = { brand: 'Ferrari' };
doSomething(car);
console.log(car); // { brand: 'Fiat' }

如上例所示，传递可变结构总是可以通过具有不同的结构来完成。函数doSomething正在改变外部给定的属性。没有对代码的信任，你真的不知道你拥有什么，你将拥有什么。所有这些问题的发生是因为:可变结构表示指向内存的指针。

不可变性与价值有关

不可变性意味着改变不是在相同的对象、结构上完成的，而是在新的对象、结构中表示的。这是因为引用不仅表示内存指针的值。每一次改变都会创造新的价值，而不会改变旧的价值。这样清晰的规则给予了信任和代码的可预测性。函数使用起来是安全的，因为它们处理的不是突变，而是具有自己值的自己的版本。

使用值而不是内存容器可以确定每个对象都表示特定的不可更改的值，并且使用它是安全的。

不可变结构表示值。

我将在一篇中型文章(https://medium.com/@macsikora/the-state-of- immutabil-169d2cd11310)中更深入地探讨这个主题