回想起来 Discourse 这套系统是支持 API 的, 前后端分离,
比如说 http://react-china.org/categories.json
然后详细的文档可以看这里:
我之前用基于 CNode API 用 React 写过一个 React 的界面, 感觉可以炮制一下:
不过登录部分的我还没看明白, API 访问权限也需要考虑下,
这样我们的论坛前端就能用 React 实现了, 后端不用重新写一个了~
回想起来 Discourse 这套系统是支持 API 的, 前后端分离,
比如说 http://react-china.org/categories.json
然后详细的文档可以看这里:
我之前用基于 CNode API 用 React 写过一个 React 的界面, 感觉可以炮制一下:
不过登录部分的我还没看明白, API 访问权限也需要考虑下,
这样我们的论坛前端就能用 React 实现了, 后端不用重新写一个了~
考虑到每个开发者的口味,估计对库的选择都很难达成一致
es6 还是 CoffeeScript
flux 还是 reflux, alt
webpack 还是 gulp, grunt …
react-router 还是 …
当然. Webpack, react-router 两个是定死的.
Flux 由主要的开发者定.
前端代码 Webpack 的话 ES6 和 CoffeeScript 同时存在
Gulp 搭配 Webpack, 能用 Webpack 的地方就不用 Gulp.
一直有疑问,为什么要用 npm scripts?
我目前觉得是 npm scripts 最大的好处是不用理会 gulp 的语法,更简单了。但是 npm scripts 也有问题,本质上是 shell 脚本(是不是又要转到 Makefile 了)。用 node_modules/.bin 里还好,如果是原生的命令,就会平台不兼容。比如 sed。
LeftNav之前卡爆了,后面提了pr优化了,现在不卡。List自己写的无限滚动,没用它的,其他的控件没有太多体验。封装的有点不合胃口,很多子组件都是通过props传进去的,不是用组合(composable)的方式,会明显感觉到束手束脚,控件内部是增加了可控制性,但是对于使用者来说不是很友好,曾一度想自己写一套,发现没那本事。
总之个人还是偏向composable components,然后对可组合的组件进行约定。
可以试试