xin-tan.com
晦涩的残局
获得徽章 0
- 今天看到掘金有签约作者计划，我觉得特别好。相较于其他类型的文章，技术类的创作是件非常消磨精力的事情，平台能够出面鼓励创作者继续创作，最终受益的将是整个中文技术社区，真是功德无量。可以感受到掘金一直在进步，背后的团队功不可没。评论4
JavaScript版·剑指Offer | 查找 && 数组专题 
查找专题：
① 旋转数组最小的数字：
xin-tan.com
② 数字在排序数组中出现次数：xin-tan.com数组专题：
① 二维数组中的查找：xin-tan.com
② 数组顺序调整：xin-tan.com
③ 把数组排成最小的数：xin-tan.com
④ 数组中逆序对：xin-tan.com
其他专题请移步：github.com 展开225- 996那个项目已经触及到了某些浏览器利息，直接说是非法，我笑而不语，我用了12个浏览器做测试可见某些大厂的阴谋诡计！！看看chrome多正直，程序员就应该用chrome！126103
- 关于编写复杂前端业务代码的一些见解。
首先，尽可能的进行分层，将其分成service、formatter、model、controller等等。
容器组件里面的逻辑可以剥离出来放到controller中（react-imvc就是这种做法），也可以将redux和mobx等状态管理看做model。
react只负责渲染view，有了hooks之后，react也可以变得更加纯粹（实际上有状态组件也可以看做一个mvc的结构，state是model，render是view，各种handler方法是controller）。
单个format函数也不应该格式化过多数据，函数应该根据功能进行适当拆分，也有利于复用。
如果涉及到埋点之类的逻辑，甚至可以再独立出来一个tracelog层，对埋点方法进行收口。
之所以分这么多层，一部分原因是随着业务逻辑增加，mvc中的controller会变得更加臃肿，这个时候就需要对controller再进行一次分层，在此之上独立出上面的service、formatter和tracelog等等。
不过也不代表着这样写就够了，毕竟大部分的前端应用都还是以展示数据为主，最重要的还是在写之前思考一下业务场景、交互逻辑、数据的流动等等。展开39
