题叶
Is this correct? This is a multi-task.. I failed to run config like this: https://github.com/jmreidy/grunt-browserify#transform ``` js browserify: { files: { 'build/module.js': ['client/scripts/**/*.js', 'client/scripts/**/*.coffee'], }, options: { transform: ['coffeeify'] }...
I also ran into this when I repeated calling `read-line` and `aprint` to build my own REPL.
Not anymore for me after I figured out the emitted code in CommonJS is too large. Running two compilers in watch mode is heavy cost of memory on my laptops.
断线重连跟应用重新打开的过程, 简聊做过尝试, app 关闭时把内存 store 完整状态存储下来, 然后网络连上的一刻, 其实就是一样的抓取全部依赖的数据然后更新界面, 就是一致的代码了, 感觉已经到比较好了. 热部署的问题感觉比较难, 不管怎样, 加载两份代码, 有些内存总是没法回收掉的, 参考开发过程热替换代码的样子, 很可能代码本身占用的内存不断增加. 我觉得如果只是想优化对于用户而言的体验, 也许模仿 App 更新倒是跟好办法, 比如说用户从当前页面离开, visibility 变成 hidden, 这个时候自动刷新页面, 然后打开同样的路由.
@Hanruis 确实. 不过这样的话就要求升级页面的代码要和各种逻辑耦合, 挺有风险的事情. 可能还是想想别的办法比较好.
@Galen-Yip 是的. 在代码层面做 GC 很难控制好, 不如刷新来得明确. 而且刷新过程其实可以考虑把路由, 草稿, 等等的信息存储在 localStorage, 以便做到对用户而言尽可能使无痕的.
期待 Angular 2 和 TypeScript 方面的进展. 关于 React 的对比, 最近注意到一个点, 就是当我们后端工程师跟我讨论组件的时候, 他熟悉 Rails 和 Node 方面的做法, 对组件的理解应该说是更接近面向对象, 比如说一个 field 内容封装组件, 就暴露方法获取和改变 field 具体数据.. 跟他讨论过程中我意识到 React 完全不同, 不赞成从外界获取和操作组件内部数据了 而是传给组件属性, 传给组件修改属性的方法.. 这个思路跟以往的大不相同...
最近的感觉，如果是按照 React理想化的单向数据流的方方式来设计图形化档案，实际上会更像 Canvas 绘图，所有的 View 的细节就应该在每一帧重新生成出来，那样的话也不用强调 Virtual DOM 了，直接把 DOM 生成出来，甚至 DOMA 上的状态也记录在 Model 或者 ViewModel 重新生成出来得了。所以 DOM 被重复那么多遍，完全是因为对了 React 来说 DOM 这种面向对象的抽象对他来说太碍眼太重要了。
我关于 React 跟 Web Compoennts 的对比主要基于 Pete Hunt 的说明 https://t.co/mY04yPZABR Web Components 的做法问题在于依然用 DOM 操作为维护状态, React 的方式更好, 而数据绑定只是让操作的流程更方便, 并不是让调试变得轻松了. 虽然我们通常思考组件化都认为界面拆成一个个 Module, Module 之间通过事件相互通信 但是在 React 当中, 做法其实是写一个 state 的值, 通信在界面重绘过程中直接完成了...
很启发人啊. 十年后编程肯定是完全不同的样子, 从现在的 Wolframe 语言, LightTable 和 Eve, Google 的 Polymer 图形制作工具, 还有 Bret Victor 设计的那些交互软件, 可以看出来已经有一部分新方法正在成为现实. "DSL和二次开发平台"这个真是啊, 编程语言之所以能够大行其道, 很大的原因就是能抽象出函数或者模块, 这些函数或者模块只需要知道外部传递的条件, 而不需要了解外部其他的所有细节的条件, 而能实现重用. 这种提升效率的方案也将出现在人们的分工当中, 把一份工作拆分成两层, 经常就给分工协作提升效率创造了空间. "高楼造一半改需求"这个例子太好笑了, 我也多少次觉得被这种问题郁闷到. 不过也许软件现在因为太小吧, 我觉得这样比更合适,...