1272729223 (dlo021) · 回帖

[杭州] 让技术改变生活，就靠你们了！👍 at 2016年07月17日

不错，加油。

(番外篇) 同构化的 React + Redux 服务端渲染 at 2016年07月15日

@nightire 最后帮我验证一下吧，貌似跑通了，https://github.com/8itcoin/isomorphic-react-sample 真是要人命的了！对了，你觉得 horizon.js, rethinkdb这种东西来构建应用稳定吗？

(番外篇) 同构化的 React + Redux 服务端渲染 at 2016年07月15日

@nightire 细细想了一下，这样所谓的isomorphic application跟完全后端 MVC 应用又有何区别呢？不觉得多此一举吗？

当然，也许isomorphic和后端 MVC 的不同之处仅仅在于：前者是把 V 这一层用 (redux,react) 整个包装起来当做 V(这个 V 其实涵盖了 SPA 的 M 和 C)。因为纯后端 V 的话仅仅包含数据和模板，但是对于客户端的业务则需要另外再写一套。

(番外篇) 同构化的 React + Redux 服务端渲染 at 2016年07月15日

@nightire 再问一下，所谓 SSR 仅仅是在 root route 的时候，把模板渲染完先给客户端, 然后再由客户端发起资源请求 (比如是bundle.js) 来启动应用，然后接下去就是传统的SPA应用（bundle.js 托管一切，包括路由），其他都是通过ajax 或 fetch来请求。是这样的吧？

然而，我现在的需求是 (我所理解的 isomorphic application)：

第一步：同 SSR 类似，不同之处仅仅 (可能) 在root route响应客户端之前，先去api那边拿到初始化的data。但第二步可能跟 SSR 不同。
第二步：我的bundle.js(可能) 并不是一个完整的 SPA 应用。或者说路由这一层是应该由服务器端来掌管的 (我目前的理解)，因为每一个路由对应的页面，我都希望是在服务器端渲染完了之后给客户端的。而如果路由还是bundle.js来控制的话，后续的渲染都是在SPA内完成的，服务器端也根本不会接收到第二个路由。

(番外篇) 同构化的 React + Redux 服务端渲染 at 2016年07月13日

#14 楼 @nightire 太感谢了，昨晚睡觉前已经看到，只是太困了就没回。有很多概念我还没理清楚，不过也确实是没静下心来整理下思路。谢谢，我再继续研究下这几个概念怎么回事。

(番外篇) 同构化的 React + Redux 服务端渲染 at 2016年07月12日

@nightire 求救。

在universal react app中，其中一个主要的问题：在服务器渲染html模板之前，先要去数据接口拿到data。 google 搜索出来的好多 tutorail, samples 都是满嘴说着这个问题，但是整篇文章看完，整个代码翻过来就压根不给个🌰的，我擦！ 当然我也看到了几个例子，基本最关键的地方就是以下的代码块内

server/index.js

...
else if  (renderProps) {  // 找到匹配的 `component`

   //  ↓  
   doSomethingAsync().then(() => {
   //  可是这仅仅是一个`async`动作。
   //  正常的业务，每个`路由`都可能有一个`async`和他对应，类似：
   //   {
   //       "/foobar": getBothFooAndBarAsync, 
   //       "/foo": getFooAsync,
   //       "/bar": getBarAsync 
   //   } 
   // 
   //   问： 这种情况怎么才是优雅的解决办法？

       const markup = renderToString(
             <Provider store={store}>
                    <RouterContext {...renderProps} />
             </Provider>
       )
       re.status(200).send(renderHTMLPage(markup, store.getState()))
   })
}
...

option 1

当然，我也看到了有些都在component里面加一个fetchData的方法 (包括你的 univera)，然后在else if (renderProps)代码块内检查该component是否有fetchData方法。

option 2

不过我也找到universal app 概念最原始的例子isomorphic-tutorial，它是直接把 获取数据的接口 写在服务器端的每个路由内部。

option 3

以及还有一种办法，是第三方库Rezonans/redux-async-connect，不过我个人不太喜欢使用这类库。

现在，我比较倾向 option 1 和 option 2。@nightire 有什么经验可以分享的？

八十二十付费阅读继续成长, 发布了 1.0 正式版 at 2016年06月27日

楼主现在多大了？看你工作也不少年了，感觉还是热情澎拜。很羡慕。

Terminal + Screen + ... at 2016年06月16日

#20 楼 @boyishwei 赞叹。我现在也是就用Terminal加Tab，偶尔会用一下nohup。对于 screen，有些可能高效的方式我没有掌握，比如attach等。我写的一点东西也是那天下午某个场景下又用了下 screen，也是一点缘分。

其实对于我个人而言，就我个人而言，不管是工具，还是语言等，只是希望往精和专的方向去沉淀，不再想往广和博的方向去折腾了。

前端开发的技术选型？ at 2016年06月16日

#8 楼 @hxh1246996371 又是引人入坑的货。在我看来，除非真正做项目架构的工程师才需要去搞那么复杂的工程学，如果是写业务为主的工程师，完全没必要去瞎折腾那些玩意儿（当然除非你真的已经对于写前端业务都非常熟练了，可以去折腾下新玩意），什么gulp，grunt，npm scripts， webpack对于个人或一般小团队而言，手动管理，手动发布 绝对比那学习和维护那玩意和一堆链上的 (可靠不可靠的插件) 要方便和快很多很多。

前端开发的技术选型？ at 2016年06月14日

如果是我自己有决定权 (只要是可控的小团队内)，我会选requirejs(仅仅为了模块化编程)，bower都不用，更不要用yeoman等，也不用grunt，gulp，browserify, webpack, npm, 不搞自动化部署，不搞一切对于当前业务没有帮助的技术。

我只想从第一行命令开始，所有的一切都在自己的掌控当中：

$ mkdir myApp && cd $_
$ mkdir src
$ cat > src/index.html
<!doctype html>
<html>
...
</html>
$ mkdir src/assets
$ cd src/assets
$ mkdir ./{stylesheets, javascripts}
$ curl -o javascripts/require.js https://cdn.somecdn.com/require.js
$ .....
$ touch javascripts/main.js
$ ...

Terminal + Screen + ... at 2016年06月03日

#17 楼 @bigpig85 或许你说的这种场景才真是screen的用武之地，然而本地，Tab真的足以。

Terminal + Screen + ... at 2016年06月03日

#17 楼 @bigpig85 是的，工具用来用去，还是感觉默认有的好，连配置都是默认的好。

Terminal + Screen + ... at 2016年06月01日

#13 楼 @sinxccc 嗯，说是教程确实是有点为过。我也只是当作一个小工具用用而已，算是之前的一点使用经验。

Terminal + Screen + ... at 2016年06月01日

#9 楼 @msg7086 嗯，没有用过 byobu, tmuxinator. 但是对于我个人 (也许还有某些人) 而言 screen(因为 Mac OS 内置) 就足够了，我不用 iTerm2 的原因也是我不知道它的优势在哪里？或者说它的优势我用不着。所以就不喜欢再装一个 APP。

#10 楼 @sinxccc 原创，只是那天心血来潮，写了一下使用的感受。至于 attach, detach/reattach我不太用，而我现在更多使用的是fg/bg。（几乎不用tmux或screen了）

现在更多的是 Tab，因为我发现 screen 或者 tmux 在某些情况下还是有些问题，比如翻滚历史记录时不能滚动屏幕等。

Terminal + Screen + ... at 2016年05月30日

#5 楼 @msg7086 哪个更好？

Terminal + Screen + ... at 2016年05月30日

#4 楼 @nty 这个不太清楚，也许。你搜索一下fg,bg的命令，也许在 zsh 下面有适配的。

Terminal + Screen + ... at 2016年05月29日

#1 楼 @nty 是control + z你试试。

[上海] 巧思科技诚聘后端服务工程师／架构师 at 2016年05月27日

#25 楼 @nightire 嗯，谢谢！仅仅算是自己的吐槽，希望莫见怪！谢谢。我看过你的几个文章，以及对有些技术问题的回答，还是蛮信任你的。

[上海] 巧思科技诚聘后端服务工程师／架构师 at 2016年05月27日

#19 楼 @nightire 非常感谢！其实我所怀疑，或者说是在实际用了 react 之后 (3 个月左右)，然而并不能发现，它的价值是等于或大于在业内所获得的 (口碑) 地位的。当然了我真正的前端生涯也只有 2 年多，不过对于 JavaScript 语言的研究 (或者说学习吧) 应该至少有 3-4 年，自认为对于语言的特性还是有些基础（不包括 ES6 的一些最新特性主要是 generator 等，这是因为还没去看过，但是现在也在写 ES6）。而我对于前端的这几年的经历来看，从 jQuery 的$.Deferred，到标准 q, Promise, requirejs, commonjs，也包括从 grunt，到 gulp 到 browserify 再到现在 webpack 的转换，从 jQuery 事件对原生事件的包装，至 angular 事件处理的差异，在之前 amd/cjs 火热的时候也曾认真研究过他们的实现。所有这些，让我只是感觉自己的工作从来都是在跟随着别人的脚步在改变，每当我对于某一套方法或思路有所可以沉淀的时候，又要被迫着去学新知识，并且尝试用这幼稚的经验实现业务时，我总感觉自己是在煎熬，为什么不能是用已经得心应手的方案来把业务写好，而是用很生疏的东西拼凑着代码写业务。我自己是比较在乎代码质量的人，而我的工作开心与否，大部分也在于我自己对自己的代码质量是否满意。

当然我知道 react 只是一个 UI 库，它只有少量的几个接口，事实上只用 react 和自己封装一个原生的 XMLHTTPRequest 对象的 ajax 接口，也许再加一个 promise 标准的库就足够了。也不必学 flux，reflux，还是 redux。但是既然写 react，又不会安心能接受别人都在用 flux，而自己只用 react，因为 flux 确实帮我们探索了一个更有效的架构思路，当然你也看到，后来又出来了个 reflux，至于现在被 flux 本身推崇的 redux 思路。所以，既然选择了 react，所谓上了贼船，也只能继续学下去了。我的理解是，当别人在使用 react 或者 redux 的时候，遇到的其他问题，又不得不再继续造补丁 (其他的插件)，所以对于后来者，永远被他们吊着学他们的补丁 (他们会认为那是进一步的抽象代码)。当然了，对于那些人，他们一定很开心，因为在创造东西啊，又有 fans 粉他们。可我们苦逼的码农真的是要被他们玩死了。

我现在写 react，redux 也算入门了，除了一些疑难 (自己还未遇到过的问题)，大部分业务也能快速的实现。我也不可能再继续倒回去写 angular 了。只是真心怀疑 (更贴切的说也许是担心)react 还能被追捧多久？到时候不会又要革自己的命了吧？

[上海] 巧思科技诚聘后端服务工程师／架构师 at 2016年05月27日

#16 楼 @nightire 嗯，如果有时间，期待你能再分享一下，react 和 ng 而言，有哪些优势？因为我写到现在，感觉其他框架遇到的问题，react，redux 里面也无法完全解决。反而感觉只是徒增了一些学习的成本（几乎整个生态的知识全部换掉）。我想，如果不是换到 react，也许对于些写 ng 已经会很开心很熟练了，然而 react 还是这半生不熟的写得揪心。

[上海] 巧思科技诚聘后端服务工程师／架构师 at 2016年05月27日

@nightire 我看到 react 某个组织里面有你，为什么你们还是用的 ng？

[上海] 巧思科技诚聘后端服务工程师／架构师 at 2016年05月27日

微信登录：

HTTP 错误 404.0 - Not Found
您要找的资源已被删除、已更名或暂时不可用。

[上海] 巧思科技诚聘后端服务工程师／架构师 at 2016年05月27日

极致！当然设计好，技术好，老板的眼光也好吧。说到底团队融和能力很好。

请教关于同一个 domain 下面部署 2 个应用 (静态和动态) at 2016年05月11日

#3 楼 @linyunjiang 对了，还用了子域名。

http://domain.com 管理 jekyll 应用（如：首页、文档页面等）
http://app.domain.com 管理 JS 应用 (业务方面)

请教关于同一个 domain 下面部署 2 个应用 (静态和动态) at 2016年05月11日

#3 楼 @linyunjiang 已经配好，不过后续还要稍微深入些了解下 nginx。我是把应用跑在 node 上，然后 nginx 代理的。

2016 年后 Web 开发趋势是什么 at 2016年05月11日

#33 楼 @tonyisid 维护怎么个好？

谁有一份 CODE 和 NAME 对应的 json 格式的国家列表 at 2016年05月11日

@huacnlee 感谢。

谁有一份 CODE 和 NAME 对应的 json 格式的国家列表 at 2016年05月11日

没有和 ISO 3166-1-alpha-2 codes 校对过的一份列表

原来 babel 自带尾递归优化 at 2016年05月09日

能注释一下输出的代码吗？看不懂。

各位能否把 JavaScript 这个板块搞活跃起来？ at 2016年05月05日

复兴JavaScript，争取在这乱世之中，提炼出比较稳定的最佳实践。从 ES 各个版本的语法开始，以及各种开源库和框架。以较公正的态度最大可能引导众人使用成熟稳重的方案，切莫由于个人偏好引诱新人入坑。