两篇文章今天看了两篇，觉得对自己影响很大。当然，它们都与React有关：一个是MartinKleppmann在Strangeloop2014会议上的演讲，有视频和文本版本，关于数据库：Turningthedatabaseinside-outwithApacheSamzahttp://www.confluent.io/blog/turning-the-database-inside-out-with-apac...另一篇ChristianAlfoni关于Flux的文章，来自Twitter网上看到的，关于MVC架构：WhywearedoingMVCandFLUXwronghttp://www.christianalfoni.com/articles/2015_08_02_Why-we-are-doing-MV...https://www.youtube.com/watch?v=xCIv4-Q2dtAhttp://www.christianalfoni.com/todomvc/#/The上一篇文章的来源是在Redux文档中看到的。本文档中有许多我关心的技术：http://gaearon.github.io/redux/index.htmlTheElmArchitecture是对使用reducer建模状态更新的一个很好的介绍；把数据库从里到外翻过来让我大吃一惊；用Figwheel开发ClojureScript让我相信重新评估应该“正常工作”Webpack用于热模块替换；Flummox教我在没有样板文件或单例的情况下使用Flux；disto的概念证明可热加载的商店；用于证明此架构的NuclearJS是高性能的；Om用于普及单态原子的思想；用于显示函数成为最佳工具的频率的周期；务实创新。活跃，经常发布各种Redux相关的新闻。我的感觉是，Redux一出来，React社区和函数式编程的距离，以及未来的距离，都被进一步拉近了。一大步包括Clojure、Elm、PureScript在Twitter上也很活跃……当然，因为我比较关注这些人，所以我经常想，函数式编程真的复兴了，对吧？它无处不在？数据库的第一篇文章比较难懂，幸好图多。大意是重新思考数据库。常用的数据库都是根据上个世纪的硬件条件设计的，受到各种限制。如果我们重新思考数据库的应用，我们应该如何考虑设计一个新的解决方案？那么笔者梳理了数据库应用中的几个要点：Replication数据库同步二级索引辅助索引Cache缓存物化视图物化视图我们首先讨论了复制，即在多台机器上保留相同数据的副本。它通常效果很好，所以我们会给它一个绿色的笑脸。一些数据库在操作上有一些怪癖，一些工具有点奇怪，但总的来说它是成熟的、易于理解的并且得到了很好的支持。同样，二级索引工作得很好。您可以在处理写入查询的同时构建二级索引，并且数据库以某种方式设法以事务一致的方式执行此操作。另一方面，应用程序级缓存是一团糟。红着脸皱着眉头。物化视图一般般：想法很好，但它们的实现方式并不是您希望从现代应用程序开发平台获得的方式。维护物化视图会给数据库带来额外的负载，而实际上缓存的全部意义在于减少数据库的负载！就实际开发而言，前两者在数据库方面效率很高，Cache不用太担心。相对来说实现起来比较杂乱，很难管理物化视图还不错，但是不适合编程，灵活性低，不能做太多的事情。那么笔者就想，如果反过来，以数据库同步机制作为数据库设计的核心，是不是可以改进一下呢？内部数据库采用逻辑日志的形式，整合所有的数据保存。作为一种同步方式，我们这里说的是ApacheKafka。好像记得MongoDB、Redux、Docker、Nix都有类似的方法。这里的Log有点像Flux中的Action。随着时间的推移，一个Stream就形成了。使用同步数据的作者后来更进一步，认为从数据库到屏幕像素，整体都是数据同步的一部分过程，比如数据库的一些查询结果，相当于Tables的Materializedviews。这样一层抽象，缓存、HTMLDOM、界面像素，其实就是下一层抽象来写应用。如果整体是Reactive，后面跟着前台自动更新，效率会很高。假设HTML是由后端呈现的。如果数据库更新了，HTML的自动局部更新有多好？这就需要引入Stream机制。但是，前端实现通常是发布/订阅模型。当前的Meteor是一个特别著名的例子。如果Meteor使用MongoDB的同步机制，可能更像这篇文章，指出很多人已经贡献了类似的解决方案，他们正在开发新的工具来实现它。我关心的是整套想法至少验证了我用Cumulo探索的解决方案。至少起点是非常好的。其实我关注的Datomic、Redux这些技术也在朝着类似的方向发展。有不小的可能，我们以后开发应用的方式，整个就是按照这个方式。另一篇关于MVC的文章是关于MVC和Flux的。***扔掉自己基于React写的Cerebral。从文章的章节标题就可以看出具体的来龙去脉。MVC在前端遇到什么问题，Flux如何改进，如何改进：TraditionalMVCApplicationstateStateintraditionalMVC当我们搬到前端时router不是controllerview层绕过了controller层没有单一状态存储的概念视图层中的状态FLUX改进了什么解决问题单一状态存储带有中间件的控制器视图与控件对话er只做路由那么我真正得到什么好处呢？总结就后端而言，各个Part之间的隔离性非常明显。MVC有自己的程序和语言来抽象前端，万物突然聚在一起，生出特别是有很多以前没有的做法，也面临着各种各样的问题。多个视图状态也在视图内部多个模型我们绕过视图控制器模型流路由器不再是状态更改的唯一入口点。Flux对问题做了一些修正，避免了statedispersionView中的情况更接近MVC，但是在一些部分的使用上仍然存在问题：FLUX架构使用了多个模型（store）。使用传统的MVC，你只有一个模型，你的数据库。当调度需要到达多个商店时，尤其是如果一个商店需要了解另一个商店的状态时，多个商店很快就会出现问题。没有像传统控制器那样的中间件概念。这很快引入了动作创建者的概念。负责做与来自视图层的请求相关的所有事情,经常对store做多次调度当view层想要获取一些state的时候他们还是直接从model层做，在views中做不必要的复杂依赖作者也提出了具体的解决方案，最重要的是data和state来统一进入模型：我们的模型层应该有一个模型所有的状态都应该包含在模型层中我们的控制器层应该有一个控制器视图层只能与控制器层通信使用不控制路由器的路由器view层其实笔者最后得到的是一个类似Elm的解决方案，State全部集中。同时，也可以收集所有的操作。和Elm一样，可以用来回放和调试这里的Action。和上面文章提到的Logicallog一样，思路上也很相似，就不多说了。我总体上认为这是整个React社区未来的发展方向。BigPicture梳理了TimeTravelingDebugger的开发过程，早在函数式编程的时候就已经相当让人印象深刻了。理论研究我并不熟悉，但实际上，函数式编程和不可变数据几乎是这套方案实现的基础。因为有一个统一的状态，所以可以使用调试工具来重现整个状态。这些工具我对这段时间的进步印象比较深刻：2012年2月，BretVictor发表了关于InventingonPrinciple的演讲，被反复引用https://www.youtube.com/watch?v=PUv66718DIIis还有2个月risGranger开始连载一些关于LightTable调试功能的文档http://www.chris-granger.com/2012/02/26/connecting-to-your-creation/2014年5月或者更早，Elm发布了关于TimeTravelingDebugger的文章http://wadler.blogspot.sg/2014/05/elms-time-travelling-debugger.htmlWWDC5月，Swift语言发布了Playground，集成了LightTable中的部分调试功能https://www.youtube.com/watch?v=oY6nQS3MiF87月初，社区开始流行基于Webpack的代码热替换，他也是后来Redux的作者https://gaearon.github.io/react-hot-loader/2014/07/23/integrating-jsx-...BruceHauman于2015年4月底在ClojureEroupe上发布了Figwheel。类似时间调试功能https://www.youtube.com/watch?v=j-kj2qwJa_E发布ReduxonReactEroupe六月初开始做React'sTimeTravelingDebuggerhttps://www.youtube.com/watch?v=xsSnOQynTHsTheCerebral刚刚，大约上个月，也是基于React的类似功能http://www.christianalfoni.com/todomvc/#/BretVictor展示的方法已经使用了很多年。我们在日常开发中并没有使用到main函数。随着这两年React社区的各种事情，似乎只差一步之遥了……
