爱尖子移动端,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对象,前端从对
象里面拿东西获取数据。这只是一种习惯,肯定有更好的办法,