为了练手，用 react 写了个 v2ex 的首页：
页面地址
项目地址
整个项目基础 react 搭建，样式本来打算用 inlineStyle 来写的，但是发现写起来太累，于是还是用回到 sass，最后用 webpack来编译。本来想着看能不能直接调用 V 站的 API 来做一个纯前端的首页，所有的数据都用 ajax 来调，但是发现因为跨域的问题，前端无法拿到数据，也就放弃了，最终也只能是一个静态页面。
说一下写代码中遇到的一些问题吧，首先整个项目的文件结构如下：│ .babelrc
│ .editorconfig
│ .eslintrc
│ .gitignore
│ index.html
│ index.js
│ package.json
│ readme.md
│ server.js
│ tree.txt
│ webpack.config.js
│
├─api
│ hot.json
│ latest.json
│
├─build
│ bundle.js
│ index.html
│
├─components
│ CommunityStatus.js
│ Footer.js
│ Header.js
│ Main.js
│ SearchInput.js
│ TopicsHot.js
│ UserLink.js
│ UserPanel.js
│
├─containers
│ App.js
│
├─sass
│ │ main.scss
│ │ _config.scss
│ │ _global.scss
│ │ _normalize.scss
│ │ _page.scss
│ │
│ └─components
│ _CommunityStatus.scss
│ _Footer.scss
│ _Header.scss
│ _Main.scss
│ _TopicHot.scss
│ _UserPanel.scss
│
├─static
│ └─images
│ [email protected]
│
└─utils
getData.js
优点
先说说用 react 写的优点，它火起来不是没有道理的，确实是有很多优点的，我这里只说实际码代码中的优点，不涉及 virtualDom 带来的性能提升之类的。
结构清晰
因为 react 本身就是组件化的，所以整个页面按结构被分为几个组件，每个组件自己管理自己的展示和行为，最后通过容器组合起来，结构非常清晰。
组件的状态都是通过 state 或者 props 来控制，而我认为大多数组件只需要 props 就行了，只在顶层组件上控制 state，这样可以更加清晰的管理 state。
易于维护
因为结构清晰，所以可以预想到，这样是易于维护的。比如头部要改结构和样式，那就只改 Hearker.js 和对应 _Header.scss 就行了，或者要改逻辑，那只要修改 Hearker.js 中和 props 或者 state 相关的代码就行了，不用像以前那样在整个页面的逻辑里面去找这块的代码。
这根我目前维护的一些老项目来比，维护性上简直是天壤之别，再也不用愁找不到代码在哪改了，也不用吐槽那一串串的不知道干什么的 jquery 代码了。
省去了模版引擎
因为 react 可以说是自带了模版引擎，类似的 jade 或者 ejs 之类的模版引擎也就不需要了，类似这样拿到数据直接渲染就行了。<div>
{Hot.map((topic, index) =>
<TopicsHotItem {...topic}
key={index}
/>
)}
</div>
缺点
组件划分大小的疑惑
一个页面到底要划分成几个部分？根据逻辑分还是根据页面布局分？组件分到那个层级？像V站的这个头部，是划分成一个组件还是三个？
当然这个可能不能算是缺点，可能是因为我经验不足以至于无法确定该如何化分。
报错不友好
比如我 className 习惯性的写成了 class，然而console里面只是报了个 Did you mean className 的错，但是报不出来错在哪个文件，更不用指望报错在哪行了？只能自己去找，当项目大起来的时候，这个肯定很坑爹。
总结
整体来说， react 写起来还是很爽的，而且有点也很明确，组件化·单向数据流·函数式编程，虽然有一些不成熟的问题，但是优点还是突出，如果可以的话，在一些小型项目里实际试水一下应该还是不错的。
