用 react 写了个 v 站首页，我感觉能用来钓鱼

[kisnows]

为了练手，用 react 写了个 V2EX 的首页：
页面地址可以看一下能不能用来钓鱼
项目地址

整个项目基础 react 搭建，样式本来打算用 inlineStyle 来写的，但是发现写起来太累，于是还是用回到 sass，最后用 webpack来编译。
本来想着看能不能直接调用 V 站的 API 来做一个纯前端的首页，所有的数据都用 ajax 来调，但是发现因为跨域的问题，前端无法拿到数据，也就放弃了，最终也只能是一个静态页面。

说一下写代码中遇到的一些问题吧，项目结构可以参考 Github

优点

先说说用 react 写的优点，它火起来不是没有道理的，确实是有很多优点的，我这里只说实际码代码中的优点，不涉及 virtualDom 带来的性能提升之类的。

结构清晰

因为 react 本身就是组件化的，所以整个页面按结构被分为几个组件，每个组件自己管理自己的展示和行为，最后通过容器组合起来，结构非常清晰。
组件的状态都是通过 state 或者 props 来控制，而我认为大多数组件只需要 props 就行了，只在顶层组件上控制 state ，这样可以更加清晰的管理 state 。

易于维护

因为结构清晰，所以可以预想到，这样是易于维护的。比如头部要改结构和样式，那就只改 Hearker.js 和对应 _Header.scss 就行了，或者要改逻辑，那只要修改 Hearker.js 中和 props 或者 state 相关的代码就行了，不用像以前那样在整个页面的逻辑里面去找这块的代码。
这根我目前维护的一些老项目来比，维护性上简直是天壤之别，再也不用愁找不到代码在哪改了，也不用吐槽那一串串的不知道干什么的 jquery 代码了。

省去了模版引擎

因为 react 可以说是自带了模版引擎，类似的 jade 或者 ejs 之类的模版引擎也就不需要了，类似这样拿到数据直接渲染就行了。
javascript
<div>
{Hot.map((topic, index) =>
<TopicsHotItem {...topic}
key={index}
/>
)}
</div>


缺点

组件划分大小的疑惑

一个页面到底要划分成几个部分？根据逻辑分还是根据页面布局分？组件分到那个层级？像 V 站的这个头部，是划分成一个组件还是三个？

当然这个可能不能算是缺点，可能是因为我经验不足以至于无法确定该如何化分。

报错不友好

比如我 className 习惯性的写成了 class ，然而 console 里面只是报了个 Did you mean className 的错，但是报不出来错在哪个文件，更不用指望报错在哪行了？只能自己去找，当项目大起来的时候，这个肯定很坑爹。

总结

整体来说， react 写起来还是很爽的，而且优点也很明确，组件化、单向数据流、函数式编程，虽然有一些不成熟的问题，但是优点还是突出，如果可以的话，在一些小型项目里实际试水一下应该还是不错的。

这篇感受同时发表在我的博客上 http://kisnows.com/。

这篇感受同时发表在我的博客上 http://kisnows.com/。

[code4life]

LZ 牛！
继续把 react 发扬光大吧

[shuding]

赞！
组件应该是功能分离的情况下，尽可能划分得细。
className 在这儿有一个比较详细解释： https://www.quora.com/Why-do-I-have-to-use-className-instead-of-class-in-ReactJs-components-done-in-JSX ，大致意思就是 class 、 for 是 JavaScript 保留字，可能出问题。

[zzxa]

lz 有什么好的教程分享吗

[yangtze]

！我准备放假写这个的，让你先了

[angkec]

大赞

[Tankpt]

我给 8.5 分。。还有一点五分。。不能让你傲娇

[kisnows]

@zzxa 就是看文档，然后自己试着写就行

[kisnows]

@yangtze 我写的很简陋，你可以写个完整的嘛

[kisnows]

@shuding 是保留词这个我知道，我说的问题是，我手写错了，但是报错报的太模糊，无法报出具体的错误出在哪里。
组件尽可能划分的太细这个我有点疑问，因为那样的话分的太开了，一个模块得分为几个小文件，这样感觉太散了，不易于管理。

[kisnows]

@code4life 并没有发扬广大的想法

[yisiper]

组件分类就有没有 props 关系啊
我记得 class 是有提示的...

还有
props 依赖 state 怎么设计？
如果有多层
1
2
3
4
props 下来， 又依赖 state 那会有点难搞。

我写过相同与 limesurvey （仿前端）, react 代码清晰， 但就为了配合原本 lime 逻辑就折腾了下。
但没有用 webpack 等...

[kisnows]

@yisiper 第一句没太看懂。
class 那个确实有报错提示，就像文章最后那张图里面一样，只是报了错，但是报不出具体的错误位置。
props 依赖 state 的设计：
我觉得大多数组件是不需要 state 的，只有接受用户输入的组件需要 state ，展示类用 props 就行了，这样在每一个组件的顶层定义 state 然后子级组件的 props 传下去。
多层 props 下来，依赖 state 应该没有关系吧。比如第四层想要修改第二层的状态，我直接修改顶层 state 就行了。
至于 webpack ，只是一个包管理工具，可替代的很多，不一定非要用。

[jinwyp]

其实很多时候 做成组件就是累赘, 因为你依赖上层的 props, 其实和单独的页面差别不大, 无法复用.

[kisnows]

@jinwyp 我的看法是，大多组件并不是为了复用才写成组件形式的，只是为了便于维护而已。

[dong3580]

@jinwyp
@kisnows
发现明明可以需要几句话的地方， reactjs 却要搞一坨封成组件。反而 angularjs1 更方便适合表单的页面。
不过 2 却在走 reactjs 的路。不知道这是不是趋势。

[kisnows]

@dong3580 angularjs1 我只维护过一个项目，接触的不多，不过感觉确实是比较适合表单。
而我这里只是写了个首页的 DEMO ，感觉有点为了用 react 而用 react 的感觉，而且开发效率确实没有传统方式效率高。
但是却明显的可以感觉到，代码组织上非常清晰，而且维护起来绝对比以前那种方式要好维护很多。
前几天我也看了 Angular2 ，确实也有点像 react ，可能这就是趋势吧。

[yisiper]

@kisnows
那你因该去试试写类似 limesurvey 为例
加了逻辑层， 不是只有 props 传下, 显示出来而已
当然我也只有用 state ， props 。

@dong3580
如果就 几句话，可以直接写在 render 里 , 为什么要搞成组件。

[wbsdty331]

移动版呢？

[kisnows]

@wbsdty331 你的移动版是指 RN 版？暂时是没有的

[kisnows]

@yisiper 因为我目前也是刚接触，经验不多。我觉得如果项目逻辑比较复杂的话，可以引入数据框架，比如 redux ，按照它的方式来开发可能会好一点。

[plantain]

class 报错位置不明确的问题，我可以用 tsx 解决， VSCode 或 Atom 上写代码时，就会错误的位置有提示；
组件划分粒度的问题，和一般的函数粒度的划分策略一样，先一个页面对应一个组件，方便路由，然后页面间可复用的部分，抽出来做成组件。

[kisnows]

@plantain 我现在用的是 webstorm ，是没有报错的。回头我试试 vscode 。
组件划分这个，按页面来感觉是不是有点太粗了。

[plantain]

我说的是一种策略，页面和可复用的部分肯定是个组件，先做，剩下的部分看时间、个人习惯了，时间多就分细一点，时间少就分粗一点。
就和函数的粒度策略一样，先写在一个函数里，有重复的话，就把重复部分抽出来，剩下的部分就看时间、个人习惯了。

[oubushixb]

还是喜欢 angular 的 ngIf 、 ngFor 之类的 html 模板..不太喜欢 react 这种 js 代码和模板弄在一起..就像当年部分 php 极客号称 php 是最好得模板语言一样....(phper 别激动,自己人,当年也是用 php 和 yii 框架入的互联网坑

[kisnows]

@oubushixb 这个其实看个人喜好了， angular 和 react 我用的都不多， angular 只是维护过一个项目。相比较而言，我还是觉得 react 这种 jsx 的写法感觉好一点。
不过，没在实际项目中使用过，也不太好说。

[oubushixb]

@kisnows 恩..说到底技术只是一种达成产品得手段..用什么其实都无所谓.顺手就好

[kisnows]

@oubushixb 我也是这样觉得。
看这几天前端大神们微博掐架，觉得好没必要。

[irainsoft]

咱能先把移动端做好吗［(－－)］

[kisnows]

@irainsoft 工作忙，还没空写移动端，⊙﹏⊙