爱尖子移动端，spa项目。入口唯一，目前只用于做单页面应用，后期可以更改react-router改为多页面应用，看具体需求，但如果只是用来做移动端项目的话，完全可以做单页面应用，体验比较流畅。当然首屏幕加载要优化这个加载时长。
####项目相关
首先从这个项目开始，使用yarn，从npm迁移到yarn。
yarn可以保证所有的项目开发者得到完全相同的配置，但npm却未必。
1、yarn // 安装项目的package.json里面的依赖
2、yarn add package //安装对应的模块。yarn.lock请记得将其提交到代码管理系统。
3、yarn安装依赖时采用的确定性算法就会导致依赖冲突。一般出现在npm install执行，
node_modules文件夹被多次删除，并重新安装的大型项目里。项目的其他开发者可以继续使
用npm，所以无需让每个人同时迁移。
项目开始
从git上克隆的项目。
yarn 安装所有依赖，可以保证一个确定的package.json文件。
yarn start 启动服务
yarn build 上线编译
关于项目实现移动端响应。适配多种机型。
手机端web项目是基于vw视区单位实现viewport配合rem实现的响应式排版和布局。
最大的特点是响应布局。用css就可以根据屏幕大小动态改变html根元素的基础字号大小，
从而使得页面中使用rem布局的元素实现尺寸的动态变化。所以单位选择用的rem。
此次我将架构抽离，爱尖子业务逻辑实现集成redux，redux-saga，redux-logger和react-route
yarn add react-router --save-dev
yarn add react-redux --save-dev
yarn add redux --save-dev
yarn add redux-saga --save-dev
yarn add redux-logger --save-dev
关于redux相关。拆合action、reducer
对应的action都放在一个文件中，reducer都放在一个reducer文件中，reducer的合并可以
用combineReducers。在redux创建store的时候就applyMiddleware加载sagaMiddleware
和createLogger中间件。
本来其实也想采用redux-thunk和redux-saga相结合的，但是通过爱尖子管理后台项目发现，其
实每台必要拆分的特别细化，处理同步之外的异步就只用一个就可以了。
redux-thunk和redux-saga的区别我也是在搭建react-native的时候搞明白的，我发现
redux-thunk 的任务执行方式是从 UI 组件直接触发任务，他的主要思想是扩展 action，使得
action 从一个对象变成一个函数。redux-saga将所有的异步流程控制都移入到了 sagas，UI
组件不用执行业务逻辑，只需 dispatch action 就行，增强组件复用性。而且，后台管理系统
采用的就是dva封装的redux-saga，所以我选择一种处理异步流的方式就可以了。
react-router的使用
react-loadable // 以组件为中心的代码分割和懒加载
####项目的部署发布
yarn build以后会构建一个build静态资源文件，就和普通项目一样发布咯
1、jenkins构建部署工具拉取git代码，把build文件上传到nginx服务器，配置server文件，指定端口号、server——name和root根目录，就可以访问了，这种没有中间层的前后端分离模式，我是不不喜欢的，在这里顺便贴上我对是否采用中间层做代理服务器的一些感悟
####前言：
由于地处北京，作为技术前言大都市，技术的更新迭代也比较快，前后端分离的思想现在已经深入人性，目前大型的pc端网站都是采用的mvc的架构模式，前后端项目实现很大程度的解耦。前后端分离一般分为两种：
#####没有中间层的前后端分离
没有web中间层的前后端分离属于比较简单的类型，我们将html、css、js等静态资源放置到
cdn上，每次访问页面的时候，直接将html返回给用户，然后里面所有的dom节点和其他数据都
是由js来执行生成的。我所在的公司目前采用的就是这种比较简单的前后端分离，将所有的静态
资源全部放在nginx上。这样做起来所有的js，css都被打包成一个或者多个文件，加载的过程
特别长，造成首屏的渲染时间太长了，并且html只有一个入口，seo的特别不友好。
#####有中间层的前后端分离
有中间层的前后端分离是一般大型项目采用的前后端分离方式，node由于自身健壮性的限制，
又不适合作为大型项目的后端服务器，所以node热过一阵之后，逐渐成为了连接传统前端和后
端的中间层，我们也称这种前端+node的架构为“大前端”。
在node层中，我们可以做的事情就有很多了
1、返回不同的前端模板。
2、数据拼接,资源整合
（因为服务器访问接口的速度要比浏览器快很多个数量级，因此在node中访问多
个接口并且拼接起来是非常高效的，拼接后的数据我们就可以直接传入模板中，供js使用，
这个只是一个列子，前两天后台同事告诉我，数据的整合是他们来做的。我们只调一个api就
可以，其实在node层做拼接，其实也是不安全，维护性也特别差，但总的来说，其实也是一
个优点）
3、node层对app实例的监控，可以捕捉异常的请求和事件。可以做数据统计，包括对内接口
4、服务器端渲染，我们解决之前提到的首屏渲染时间过长和对seo支持较低的问题。之前很
早以前在饿了莫面试的时候，被问到服务器端渲染，其实自己已经在用了，不过一直不知道这
个名次，不过现在懂了，之前使用的时候也是在node层，将数据传入windos对象，前端从对
象里面拿东西获取数据。这只是一种习惯，肯定有更好的办法，