Open helios741 opened 6 years ago
因为现在在项目中使用的是axios，通过axios的displayNotification会把所有的请求失败的接口统一处理，现在的统一错误处理是只要是错误就出现个弹窗把后端返回的错误显示给前端。但是也是会有特殊情况，在登陆的时候当用户名和密码出现错误的时候，一般在输入框的周围出现红色文字提示，但是如果使用统一的错误处理话还是会出现弹窗，这样对于交互或者体验来说是很不好的，现在的做法：因为这种情况比较特殊，所以就通过判断后端返回回来的错误信息，这个场景就不进行出现弹窗
axios
displayNotification
但是项目中难免会出现一些奇葩或者历史遗留性问题，有的接口默认返回的都是200，那个开发者觉得只要这个请求请求到服务器了就是成功就应该返回200，但是把具体的错误有进一步的包了一下，但是这个请求除了404意外都是200，所有就不会走到上面所说的displayNotification里面，所以这种情况的做法：就要使用axios的interceptors对每个请求的响应进行特殊的判断。
interceptors
在当前的业务中，不同的业务线是分为不同的repo的，这样做是有很多好处的：
还是有坏处的：
normalize.css
* {box-sizing: border-box}
现在的场景是这样的：
rc-component
rc-select
rc-tooltip
rc-
lamma-ui
apollo-weights
并且内部的lamma-ui和apollo-weights已经稳定使用了很长时间了，突然有一天发现了rc-component中的某一个组件的bug（比如说： rc-select），并且这个bug是block的会影响产品展示形态。
在工程中做了统一的接口错误处理，但是遇到特殊情况怎么办？
因为现在在项目中使用的是
axios，通过axios的displayNotification会把所有的请求失败的接口统一处理，现在的统一错误处理是只要是错误就出现个弹窗把后端返回的错误显示给前端。但是也是会有特殊情况，在登陆的时候当用户名和密码出现错误的时候，一般在输入框的周围出现红色文字提示，但是如果使用统一的错误处理话还是会出现弹窗，这样对于交互或者体验来说是很不好的，现在的做法：因为这种情况比较特殊，所以就通过判断后端返回回来的错误信息，这个场景就不进行出现弹窗但是项目中难免会出现一些奇葩或者历史遗留性问题，有的接口默认返回的都是200，那个开发者觉得只要这个请求请求到服务器了就是成功就应该返回200，但是把具体的错误有进一步的包了一下，但是这个请求除了404意外都是200，所有就不会走到上面所说的
displayNotification里面，所以这种情况的做法：就要使用axios的interceptors对每个请求的响应进行特殊的判断。公用模块频繁升级版本
在当前的业务中，不同的业务线是分为不同的repo的，这样做是有很多好处的：
还是有坏处的：
normalize.css等有全局的东西话就可能会遇到问题。比如现在遇到的问题是：公用模块的样式中有一个* {box-sizing: border-box}但是有的模块是不依赖这个的，就会出现问题：底层依赖的component有bug
现在的场景是这样的：
rc-component是一套开源的组件库，里面封装了常用的基础组件如：rc-select,rc-tooltip,rc-lamma-ui是基于rc-component的；apollo-weights是基于lamma-ui的；并且内部的
lamma-ui和apollo-weights已经稳定使用了很长时间了，突然有一天发现了rc-component中的某一个组件的bug（比如说：rc-select），并且这个bug是block的会影响产品展示形态。apollo-weights中的代码copy一下到本地，然后升级一下里面有bug的组件，升级到最新的没有bug的版本。rc-component的组件定期升级到最新的版本，然后使用组件的业务进行测试。