大家对 immutable-js 的接受程度如何? - 提问 - React 中文
03:49:44 UTC
ES7 或者 TypeScript 的类型系统, 看得人有点头疼. 能明白大义但是写不惯.不过习惯静态类型的同学是不是很轻松啊?
05:17:20 UTC
文不对题啊。静态类型，可读性会更高点。
05:54:46 UTC
问的就是这嘛...
09:40:19 UTC
静态类型和immutable是两码事啊。不是一个概念。
11:57:39 UTC
是的. 不过它的文档是用 TypeScript 生成的, 对于没有深入写静态类型的人来说去难了.
04:21:15 UTC
组里有几个人开始用immutable了 但是我还没敢用主要是那那个react插件 不能用了啊 看不到state和prop了～
07:02:39 UTC
晕, 还有这样的事情... 只能给官方提 bug 了...
14:31:05 UTC
我没用flux，用immutable还蛮爽的
06:38:38 UTC
我们在使用 immutable 和 flow
immutable 还是比较成熟稳定了。
flow 有不少坑，不过用了一段时间后还是觉得挺方便，对于重构代码，及避免一些低级错误很有用。
06:46:21 UTC
可以看到 就是隐藏的深，另外，用了数据整个应用的数据都沉淀在Store中，更新的时候可以在cursor onChange统一的监控数据的变化，也很方便。
06:51:13 UTC
我们的做法和
说的类似。
我们所有 store 的数据都是存在一个全局的 State （一个 immutable.Map） 中的，store 通过 cursor 操作自己关注的数据。
这样调用的时候， 很多时候只要把这个全局的 State 数据拿出来看一下 就知道出什么问题了。
13:26:26 UTC
到时候能不能写点关于 cursor 的教程什么的, 虽然我觉得可能方案我已经用到过了, 可还是不明确是什么概念.
13:28:42 UTC
是的，确实我们也是这样做的。这也是Immutable和React搭配起来很自然的一个结果。我们做了些约定，React组件是相当于函数式变成中的纯函数的概念，只是通过prop去渲染组件。所有的ajax或者和server端交互的数据都放在webapi处理，所有的ajax都promise化。这样在Store中可以链式的写我们的业务。然后通过cursor去更新全局Store中的数据，这样会触发Cursor的onchange，这时候我们的app就会re-render。view不处理任何的业务的东西。就是简单的发一个自定义事件出来给Store去处理。我们之前犯过一个错误也是堆cursor理解的不够，我们把cursor作为属性透传给组件，这样的问题在与每次数据更新的时候cursor必然变化，这样导致我们的PureRenderMix不能通过简单的==来判断数据有没有发生变化。这和使用Immutable初衷相悖。
02:23:42 UTC
静态类型比较安全，似乎也利于编译器优化。比如多线程的时候，就很安全，不用担心数据突变。
02:37:05 UTC
开发当中的类型检查当然是好, 编译到 JS 在浏览器运行的话这个效果还在吗
23:43:31 UTC
我觉得这货很有价值，我们的项目引入Flux之后，发现store中的数据会被直接拿来作为component的props和state使用，如果这份数据是一个object对象的话，那就给自己挖了个坑，如果在component中调用setstate那就相当于直接修改了store中的数据，这是很容易导致bug的，同时也不符合store设计的初衷，store的引入是希望所有数据的修改都通过action的形式发给store后由store自行处理。所以要么你在使用直接从store中拿来的数据时clone一份，要么就采用immutable.js由库本身帮你确保store中的数据不会被修改，从而保证开发时的复杂度降低，bug减少。
01:27:45 UTC
这个实现感觉更好一点，结合了Ember的getter/setter设计和React的MV解耦
JS／Coffee毕竟不是纯FP，用FP的概念可能不自然，为了不可变数据跑去用FP又有点小题大做了
04:54:14 UTC
immutable 配合 React.addons.PureRenderMixin 是相当好用。但前提是你是否仔细设计了一堆 Pure 的 Component。
11:31:34 UTC
这个库和typescript无关 只不过提供ts代码和元信息 让typescript使用者很舒心。
前些天开小差看了阵clojure 发现哇还能这么玩于是立刻对号入座正好发现immutable.js现在没有这个库觉得生活不能自理了。facebook immutable.js 意义何在，使用场景？
有人用facebook的immutablejs吗？能不能解释一下为什么使用，意义何在？使用场景？
按时间排序
写了一篇关于immutable的文章，从以下几点进行了介绍- Immutable产生的背景- Immutable的好处- 在React中引入带来的利弊文章:
除了带来几种操作方便的数据结构和API，我再详细说一下可维护性和性能上的提升：在按引用来传递数据的场景中，存在因修改数据而带来影响范围不可控的副作用，因为你不知道谁还引用着这份数据，不知道你的修改会影响到谁，而Immutable.js能解决这个问题，能控制修改带来的影响范围，因为它每次修改都会创建一个新的对象，原对象不变。比如，调用函数func(objData)，如果objData是Immutable.js包装过的，func内部在修改objData时不必担心会影响func调用者所拥有的数据，同样，func调用者也可以在调用func之后随意修改objData，不必担心会影响func内部所拥有的数据。举个反例，Backbone.js中的不少方法的最后一个参数都是options对象，用来支持对方法内部操作进行一些配置，但Backbone.js会在方法内部修改这个options对象，甚至作为事件回调函数的参数传递出去，一个对象在Backbone.js框架内部外部传进传出，修改这个对象时由于影响范围不可控，很可能会惊呼“我cao~谁改了我的数据？”。类似地，Flux架构中数据也会经过多层的传递，component=&actions（其中可能有多层middleware）=&store，而多个component组成的树状结构也需要将数据一层层往子component传递。这种按引用传递数据，数据流经多层的场景，如果没有将引用类型的数据Immutable化，拿到一份引用类型的数据，修改起来心里总是不踏实。这是Immutable.js在代码可维护性上带来的提升。避免这个副作用的一种实现是按值传递，也就是拷贝一份再传递过去，有深层结构就深拷贝。深拷贝在只做局部修改的时候做了很多无用功，于是Immutable.js做了性能优化。网上找了个图，假如我们要修改左图中黄色节点的子节点4，那么Immutable.js只需要更新右图中的绿色节点，其余节点不需拷贝，继续复用。也就是说，Immutable.js会更新从根节点到所修改节点路径上的所有节点，由于修改了根节点，所以返回一个新对象，这也解释了为什么能控制副作用。跟React.js的配合使用中提高性能：1. 假如你在组件state中保存了一份有深层结构的引用类型的数据，如果没有Immutable.js，你需要深拷贝一份再做修改。而用Immutable.js将state中的数据包装一下，不需深拷贝就可以直接修改。2. 由于修改后返回的是新对象，React.js只需要在oldState.obj === newState.obj这一层就能判断出obj产生了变化，不需要深入obj的深层结构。------------------P.S. 也不能光说好的，吐槽一下，Immutable.js设计的API很细很多，带来几种数据结构概念有差别但差别不是很大，库的体积很大，导致基本跟移动端无缘，要是能够将几种数据结构模块化一下，按需打包就好了，类似这样let ImmutableList from 'immutable/list'
可以看下这个：immutable.js 诞生是借鉴了Clojure语言的immutable data structures思想。Clojure语言的作者讲述了PLace-Oriented Programming和value-oriented programming 的思想上的区别，感兴趣的可以看看，很有意思。
用最近我翻译的 Lee Byron 写的 Why Invest in Tools 来回答这个问题太合适了：「为什么要造轮子？」-------- 以下是正文 -------前几天在 React-Europe 大会上，我分享了一个我花了三年多时间的项目 - GraphQL.会议结束后，不少参会者问我：Facebook 是怎么做到一直保持产出这些“反思当前最佳实践”的新技术的？既然这是 React 大会，那么就让我们从 React 开始讲起吧。Photo: Rasmus Andersson两年前两年前我们开源 React 的时候，这一直是被 JavaScript 社区取笑的对象；甚至 Facebook 内部（包括我自己）都不认为这是一个好想法。Jordan Walke 的执着和理想主义最终还是对大家产生了影响。最早我们以为他疯了，不过他的确是个疯子，但他也确实发现了一些什么。现在，我们看到 React 已经改变了我们在各种平台上「造」东西的方式。Adam Ernst 借鉴了 Jordan 的一些想法，然后「造」了 ComponentKit for iOS. 当然，我们自己的 iOS 组刚接触她的时候也是充满了猜疑；但再一次，ComponentKit 很大程度地改变了我们「造」iOS 程序的方式。React 和 ComponentKit 都是 Facebook 内部个人自主发起的项目。事实上当时这些项目的方向和工程师团队原有的开发方式都是相反的。React 直接挑战我们当时非常看好的一些 JS 框架。其实刚开始开发 ComponentKit 的时候我们内部就已经「造」并且在使用了的一些 iOS UI 框架。其他的工具并没有问题，也不差（话说回来他们其实很赞）但他们也不是完美的。他们各自都有着利弊权衡，都有自己的优势和劣势。只有在一个自由开发环境的情况下，工程师才能去「造」一些他们认为更高效帮助他们完成工作的工具。工程师的冒险文化在 Facebook，我们不仅仅让，更是鼓励，工程师做这些好玩的“实验”。其实这些项目还是存在一定风险的，而且也不是很吸引人，也常常失败（需要改）。然后你会发现像 React, ComponentKit, HHVM, GraphQL, Immutable.js, Flow, Pop, 和 AsyncDisplayKit 这样的“实验”。这些都是值得去冒的险。对于像 Facebook 这样拥有强大的工程团队的公司来说，其中一个优势是可以充分地让工程师们去尝试这些实验，而不是盯着 scrum 或者为了公司的短期业绩来工作。上面提到的每一个项目都遇到过非常强烈的反对。有些人（有时候甚至是我）会想让一些项目早些承认失败。然而他们并没有停止。Facebook 不仅有很好的工程师管理哲学，而且有非常棒的管理层 - 他们知道相信工程师们的重要性。就算项目遇到了同事的反对，就算也未知项目的价值所在，就算还有更重要的事情可以去做，Facebook 的管理层信任他们的工程师去冒一些值得冒的险，同时专注在他们相信能够产生影响的领域。我的小组 - Product Infrastructure，和大多数的 Facebook 小组一样都有相同的哲学：工程师对世界的影响不止于公司的产品。上面提到的开源项目都有着很强的社区，每个开源都对整个互联网/软件行业有着深刻的影响。开源不仅仅是一个公益理想化的东西，她还是我们如何学习和展示我们的工作启发的影响的重要组成部分。健康的开源环境在招聘环节也是非常有利的。一些我面试过的求职者对我说，他们对 Facebook 的关注是因为看到了 React, AsyncDisplayKit, Pop, 这些项目；并且想参与到这些项目中去。这些项目吸引了非常聪明的人才进来，从而自然地产生一个良性循环。Success is not found in isolation随着项目变得越来越有意思，她的潜力被更多的人看到，团队组建 - 然后一个雪球效应自然地推进了一整个项目。在 Facebook，工程师做着与自己职份外的项目并不罕见；或者从一个小组调到其他小组都非常常见；而这样的文化让这个雪球可以滚起来。这也意味着每个项目后面有许多无名功臣。在这里我想点名一些（远远少于全部成员）早期为 GraphQL 做出贡献的人：Nick Schlock, Daniel Schafer, 和我自己。Beau Hartshorne 是 GraphQL 不可缺少的催化剂。他准确定位并指明了问题所在，找到了对的人，而且激发了我们去找解决问题的方案。Sometimes it’s hard to see the forest through the trees, and Beau’s a rare person who is always looking at the forest.Jonathan Dann 和 David Renie 是两位推动第一版 GraphQL 的 iOS 工程师。是他们做了非常大量的工作把 GraphQL 整合进 News Feed. 他们也协助建立了一些我们一直沿用到今天的非常重要的基础设施。Rasmus Andersson 用全新视角想象到一种不一样的方式在移动应用中传输数据；而这种方式成为了我们 Android SDK 的基础。他的一些想法还激发了 Relay - 用 GraphQL「造」web 端应用的工具。另外两位 GraphQL 组早期成员，Nathaniel Roman and Charles Ma, 帮助开发了 GraphQL 客户端工具。Scott Wolchok 一手组织和改善了 GraphQL 的 iOS 和其他跨平台的客户端工具的数据模型。他的严谨的思路启发了我们去研究最新 cross-cutting 的进展。到今天，已经有一个成熟的小组专门支持和投入到 GraphQL, 服务器，客户端工具，和 Facebook 的类型系统。我们的使命正是因为我们对持续产出长期价值的专注，让 Facebook 能够一直「造」出一些“反思当前最佳实践”的技术，且在业内引起不小的影响。我们敢去试错；我们相信工程师能去做正确的事。当一些“实验”看起来有点儿意思的时候，充满想法和聪明的人会自发地聚到一起来实现这个“实验”。在 Facebook, 我们的职责不仅仅是「造」Facebook，还是让世界变得更加的开放和连接。而我们这个 Product Infrastructure 小组通过开源这些工具来帮助我们完成这个使命。本文已获得作者翻译以及传播许可转载请注明来源
最近在移动端使用 React，在复杂的页面里发现 vdom re-render 有性能优化的空间，于是了解到了 immutable.js。所以也来回答一下这个问题。如
所说：它是一个完全独立的库，无论基于什么框架都可以用它。意义在于它弥补了Javascript 没有不可变数据结构的问题。在React开发中，频繁操作 state 对象或是 store，配合 immutableJS 快、安全克军说的第一点：函数式编程中的不可变数据结构问题，可参考
的文章《》中 Immutable Data 章节。我就第二点来展开说说 immutableJS 的使用场景：在 React 中使用 immutableJS （）。从问题说起：熟悉 React 组件生命周期的话都知道：调用
方法总是会触发
方法从而进行 vdom re-render 相关逻辑，哪怕实际上你没有更改到 Component.state 。```javascriptthis.state = {count: 0}this.setState({count: 0});// 组件 state 并未被改变，但仍会触发 render 方法 ```为了避免这种性能上的浪费，React 提供了一个
来控制触发 vdom re-render 逻辑的条件。于是
作为一种优化技巧被使用。这样就完美了？并不是。去趴一趴 PureRenderMixin 的源码（
）就会发现它仅仅是浅比较对象，深层次的数据结构根本不管用。这里有一个示例：，点击 SetToSameCount ，会发现 render times 没有变化，再点 SetToSameSchool ，render times 增加了。这时候 immutableJS 就派得上用场了：```javascriptvar map1 = Immutable.fromJS({a:1, b:1, c:{b:{c:{d:{e:7}}}}});var map2 = Immutable.fromJS({a:1, b:1, c:{b:{c:{d:{e:7}}}}});Immutable.is(map1, map2);
// true```当然上述功能通过 deep-diff 也可以做到（e.g. ），性能差别上我暂时没有去进行测试。但是，如果仅仅是为了一个比较而引入 Immutable 的话，就太大材小用了。Immutable 的功能远不止如此。例如，前面的
示例中的场景：（在 Hight school name 的 input 内中输入触发 handleChangeSchool 就会发现 middle 属性被删除了）这样调用 setState 会将 middle 属性给覆盖掉（setState 内部是浅 merge）。在实际项目中，我们将会频繁地操作 state 或 store ，这时候配合 Immutable 就快且安全多了：这样调用 setState 会将 middle 属性给覆盖掉（setState 内部是浅 merge）。在实际项目中，我们将会频繁地操作 state 或 store ，这时候配合 Immutable 就快且安全多了：看一个上面的示例怎样用 Immutable 重写一遍：快：便捷的API：```d.updateIn(['user','school', 'high'], ()=&v)``` 更多参考：更好的性能： (They are highly efficient on modern JavaScript VMs by using structural sharing via
as popularized by Clojure and Scala, minimizing the need to copy or cache data.) （暂时未给出性能测试）安全：是指使用上的安全，所有删改操作都是增量的。如
示例中更新 school high name 所示，并没有影响到 middle 。这就是 Immutable 在我们项目中的使用场景了。
是的啊，都是facebook自家的东西在玩
写了篇文章介绍这个事情，欢迎大家去看，什么是Immutable DataImmutable Data是指一旦被创造后，就不可以被改变的数据。通过使用Immutable Data，可以让我们更容易的去处理缓存、回退、数据变化检测等问题，简化我们的开发。js中的Immutable Data在javascript中我们可以通过deep clone来模拟Immutable Data，就是每次对数据进行操作，新对数据进行deep clone出一个新数据。deep clone/**
* learning-immutable - clone-deep.js
* Created by mds on 15/6/6.
'use strict';
var cloneDeep = require('lodash.clonedeep');
var data = {
id: 'data',
name: 'mdemo',
github: '/demohi'
var data1 = cloneDeep(data);
console.log('equal:', data1===data); //false
data1.id = 'data1';
data1.author.name = 'demohi';
console.log(data.id);// data
console.log(data1.id);// data1
console.log(data.author.name);//mdemo
console.log(data1.author.name);//demohi
当然你或许意识到了，这样非常的慢。如下图，确实很慢主角immutable.js登场是由facebook开源的一个项目，主要是为了解决javascript Immutable Data的问题，通过参考 和 提供了一种更有效的方式。简单的来讲，immutable.js通过structural sharing来解决的性能问题。我们先看一段视频，看看immutable.js是如何做的当我们发生一个set操作的时候，immutable.js会只clone它的父级别以上的部分，其他保持不变，这样大家可以共享同样的部分，可以大大提高性能。为什么你要在React.js中使用Immutable Data熟悉React.js的都应该知道，React.js是一个UI = f(states)的框架，为了解决更新的问题，React.js使用了virtual dom，virtual dom通过diff修改dom，来实现高效的dom更新。听起来很完美吧，但是有一个问题。当state更新时，如果数据没变，你也会去做virtual dom的diff，这就产生了浪费。这种情况其实很常见，可以参考当然你可能会说，你可以使用来解决呀，PureRenderMixin是个好东西，我们可以用它来解决一部分的上述问题，但是如果你留心的话，你可以在文档中看到下面这段提示。This only shallowly compares the objects. If these contain complex data structures, it may produce false-negatives for deeper differences. Only mix into components which have simple props and state, or use forceUpdate() when you know deep data structures have changed. Or, consider using immutable objects to facilitate fast comparisons of nested data.PureRenderMixin只是简单的浅比较，不使用于多层比较。那怎么办？？自己去做复杂比较的话，性能又会非常差。方案就是使用immutable.js可以解决这个问题。因为每一次state更新只要有数据改变，那么PureRenderMixin可以立刻判断出数据改变，可以大大提升性能。这部分还可以参考官方文档总结就是：使用PureRenderMixin + immutable.js参考
最近项目中频繁用到所以回答一下。首先，它虽然和React同期出现且跟React配合很爽，但它可不是React工具集里的（它的光芒被掩盖了），它是一个完全独立的库，无论基于什么框架都可以用它。意义在于它弥补了Javascript没有不可变数据结构的问题。不可变数据结构是函数式编程中必备的。前端工程师被OOP洗脑太久了，组件根本上就是函数用法，FP的特点更适用于前端开发。Javascript中对象都是参考类型，也就是a={a:1}; b=a; b.a=10;你发现a.a也变成10了。可变的好处是节省内存或是利用可变性做一些事情，但是，在复杂的开发中它的副作用远比好处大的多。于是才有了浅copy和深copy，就是为了解决这个问题。举个常见例子：var
defaultConfig = { /* 默认值 */};var config = $.extend({}, defaultConfig, initConfig); // jQuery用法。initConfig是自定义值var config = $.extend(true, {}, defaultConfig, initConfig); // 如果对象是多层的，就用到deep-copy了ES6出现原生的assign方法，但它相当于是浅copy。如果有了不可变的数据结构就省心了，ES5.1中对象有了freeze方法，也是浅copy，a=Object.freeze({a:1}); b=a; b.a=10; a.a还是1。在实际开发中浅copy通常不够。如果用immutableJS:var
defaultConfig = Immutable.fromJS({ /* 默认值 */}); var config = defaultConfig.merge(initConfig); // defaultConfig不会改变，返回新值给configvar config = defaultConfig.mergeDeep(initConfig); // 深层merge上述用deep-copy也可以做到，差别在于性能。每次deep-copy都要把整个对象递归的复制一份。而Immutable的实现有些像链表，添加一个新结点把旧结点的父子关系转移到新结点上，性能提升很多，想深挖原理请看这里：。ImmutableJS给的远不止这些，它提供了7种不可变的数据结构：List, Stack, Map, OrderedMap, Set, OrderedSet, Record （详见文档，文档很geek，打开console试吧）。immutableJS ＋ 原生Javascript等于真正的函数式编程。遍历对象不再用for-in，可以这样:Immutable.fromJS({a:1, b:2, c:3}).map(function(value, key) { /* do some thing */});实现一个map-reduce:var o = Immutable.fromJS({a:{a:1}, b:{a:2}, c:{a:3}});o.map(function(e){ return e.get('a'); }).reduce(function(e1, e2){ return e1 + e2; }, 0);修改藏在深处的值，可以这样：var o = Immutable.fromJS({a:[{a1:1}, {b:[{t:1}]}, {c1:2}], b:2, c:3});o = o.setIn(['a', 1, 'b', 0, 't'], 100);
// t赋值o = o.updateIn(['a', 1, 'b', 0, 't'], function(e){ return e * 100; }); // t * 100比较两个对象是否完全相等: o1.equals(o2)远不止这些，immutableJS提供了强大的api自己去看吧。由于是不可变的，可以放心的对对象进行任意操作。在React开发中，频繁操作state对象或是store，配合immutableJS快、安全、方便。
一般来说监测数据变化时可以用 ，或者自己去遍历数据结构进行对比。这样计算差异时可能做很多不必要的检查。Immutable 把事情提前做了，在修改数据的时候就检查差异，不变返回原引用，有变化则直接返回一个新的引用。这样检查任何数据都只要简单地用 `===` 对比就行了。这东西应该也是配合 Facebook 自家的 React 框架和 Flux 架构来用的。
mutable data structure做diff需要遍历 immutable只要对比一下reference是不是一个就行了react做virtual dom的diff会快
已有帐号？
社交帐号登录
无法登录？
社交帐号登录笔记 immutable-js 基本操作(未完成) - 推酷
笔记 immutable-js 基本操作(未完成)
这篇文章是
immutable-js
一些操作的整理, 目前只有基本的操作:
文档请查看:
使用过程中遇到的写法我会不会增加在后边.
JavaScript 当中不可变数据有点不适应, 需要借鉴一些 Haskell 中的内容:
生成不可变对象
jsarr = [1,2]
obj = {a: 1}
iarr = Immutable.fromJS(arr)
iobj = Immutable.fromJS(obj)
jsiarr.toJS()
jsImmutable.List()
获取数组元素
负数也是能运行的
jsiarr.get(0)
iarr.get(-1)
jsiarr.sort(function(a, b){
if (a & b) return -1;
if (a & b) return 1;
会终止遍历
iarr.forEach(function(a, b) {
console.log(a, b)
return true
或者 map 属性
jsiobj.get('a')
jsoc = oa.merge(ob)
jsoc = Immutable.fromJS({key: null})
oc.has('key')
jsod = Immutable.fromJS({a: 1, b: 2})
od.filter(function(value, key) {
return value === 1
已发表评论数()
已收藏到推刊！
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
排版有问题
没有分页内容
视频无法显示
图片无法显示