?CoderPad-基于React百口桶写作/消息一体综合运用的实践总结
人人伙儿们，又晤面了?。 自上次Byemess Todo以后，以为自身不足照样挺多的，时期又萌生了一些将它重构加上更多新特征的主意，以后手艺锻炼一阵再来好好革新它。关于Learn by doing这类事变，一次就会上瘾啊有木有❤️，因而乎本着继承精进演习React手艺栈，以及实践更多相干手艺的初志，besides that，自身还想再预备一个小项目来为找工作打底气，因而乎就有了CoderPad。
? WHY IS THIS
在最最先的时候，是想做一个催稿app，又是一个集成的idea:供应分类书单，能够纪录浏览状况，然后依据这个状况设定或许背景盘算智能引荐：什么时候去写一篇相干的博客(手艺博客)，固然写作也是在这个app里完成，然后自动布置至github page。 名字我都想好了，就叫催乎…（知乎er们懂的)，怎样这是个大工程啊… 我就造出了这么个只要编辑，浏览的阉割版。 别的关于写完markdown直接布置天生静态博客的app我引荐好基友的Page.qy => ? 无代码建站，基于Node.js，React和Electron，很专心的app，向他进修之，他立时又会写出一个UI逆天美的音乐播放器了，你们能够关注他。
? WHAT IT IS
Markdown： 支撑当地缓存，保留/删除/检察/下载，寻求极简。
NewsFeed： 集成v2ex，HackerNews-Top Stories， Github-Trending
Music: 暂未施工
?Techniques
老朋友React百口桶： 关于这块，值得一提的是react router v4，相干于v3的庞大修改，extremely make sense. 让route与组件化头脑更贴切，有种幻觉：定义子route越发为所欲为了。至于为何… 请君上手觉得。
Immutable: 有一些纤细的坑，重要体如今数据范例转化上，immutable会将原生JS数据范例举行包装，如Map，List，在对它们举行提取的时候须要注重是不是已转化为原生JS，不然轻易失足。 我的发起就是时候注重提取的数据是什么范例，连系PropTypes举行参数检测，失足时先console看看，平常很快能够处置惩罚。 关于多层对象嵌套的时候，为了保险，手动将被嵌套的对象举行指定范例转化，比方
{ list: [] } => { list:Immutable.List([]) }，假如要偷懒的话能够直接运用fromJS，然则这个要领渗透性强，会将一切内嵌构造举行转化，在本项目标后期重构里就碰到了子数组遍历出来满是immutable object的状况，须要手动再次转化，异常恶心。 这些缺点在redux文档里也有表述，在详细实践后才有更直观的邃晓。 参照: What are the issues with using Immutable.JS?.但不可否认Immutable.js异常相符react的头脑，都在处置惩罚大规模数据时彰显上风。Reselect：它用来替换我们手写的state selector， 它的重要头脑： state1 + state2 => state3， 缓存先决state，它们假如盘算结果是雷同的，就运用缓存结果不去转变终究state，一样也是immutable头脑。 在连系immutable.js的时候，也是坑啊，照样谁人老题目，数据范例，state嵌套越深，越贫苦。 所以，如今邃晓为何强调Redux State扁平化了吧？
Redux Saga: Oh my.. 非常亲热，至于缘由： 我写过这么一篇文章:From Iterator To Async. Saga致力于处置惩罚庞杂场景下的异步流程控制，用它来治理action触发，酸爽非常。 毕竟控制异步流程这类成就在JS话题下自身就是爽的不要不要的。 实质是运用generator，关于邃晓CO库的同学们，控制saga不在话下。在操纵极为频仍的场景下(比方游戏），你会觉得到他的威力。 引荐一篇文章： Async operations using redux-saga， 在本项目里我重要用它来控制news数据的拉取，采纳axios.
Styled Components: 老朋友，更新了2.0版本，一样合营styled-props，结果拔群。 至于一些宏观上的款式设置，确实不如直接写CSS那末直观。 我采纳的要领是，特征按组件写，通性和一些触及多层级款式都放在wrapper里。 或许零丁运用styled-components并不能发挥精彩，合营传统CSS写法，应当能够相得益彰。
?Problem and Solution
ref: 关于ref的觉得一直是又爱又恨，毕竟在react之前，dom操纵被我们玩的飞起，而react官方的立场一直是不发起运用。 在这次的项目中，markdown editor处的textarea我便采纳了Uncontrolled的情势，运用ref保留dom援用。 初志是为了对频仍的内容更改举行debounce处置惩罚，当编辑停息时才触发一次内容state更新。 跟着组件的增添，在一个嵌套到达3层的modal组件里，须要对textarea的value举行重置操纵，好了，这下我得从父组件一层层的把这个ref传进去。 那觉得几乎不能再糟…. 一刹那觉得官方文档就像平和的老司机，句句肺腑之言啊！ 不过在你真的碰到这个坑前，是不会有多深的觉得的。 要处置惩罚这个恶心的通报，只要采纳controlled情势，onChange监听，value直接链接state.
Perf: 作为机能丈量的利器，测试结果让我发明styled-components的斲丧是可观的，尤其是更新到v2.0版本后。在其他方面，由于本项目里的newsFeed能够会触及频仍点击切换途径的状况，为了防备无谓的反复衬着，给一切presentational components都设置为PureComponent， 接着在一些只须要更新一次的组件里手写
shouldComponentUpdate， 照样强调一点： 必需非常清晰传入的参数，以及其构造，并斟酌这个构造是不是在临盆环境中有变化的能够致使推断失效。 另有个值得注重的题目是react-router-v4里的NavLink检测location衬着当前激活地点的link(activeClassName属性)时，注重组件是不是是PureComponent， 假如是，必需在父组件传入location，不然PureComponent的shouldComponentUpdate将会剖断参数无变化，从而block掉link的动态衬着。参照: Dealing with Update BlockingServer Side: 由于是运用leancloud布置，用node环境，为了处置惩罚v2ex api的跨域题目，自身写了一套要求转发，然则题目来了： 单页APP里为保证革新后不涌现cannot get等题目，必需写上一条
app.get('*', (req, res) => {res.sendFile('index.html的途径')} )， 这就很贫苦了，厥后经由讨教，用正则过滤了要求转发触及的途径，就避免了途径全局阻拦。然则！ 如许革新后，又会碰到cannot get的题目了。 由于再次革新时url已变化，浏览器会去要求这个地点，而背景并没有供应此途径的相应。 最好的方法是运用nginx布置环境。(express岂非就没方法？ 照样我服务端学问短浅啊…要恶补） 别的一个题目： 临盆环境和布置环境下由于运用了差别的要求地点，返回的数据的构造存在细小差别，以本项目为例，要求v2ex topic在临盆环境下数据是res.data，而到了布置环境下由于运用了自身设置的要求地点，返回的数据成了res.data[0]，找了良久才发明题目，值得注重。Cancellation: 在newsfeed里频仍切换页面时另有一个题目： 或许下一个页面呈现时，上一个页面中触发的fetch操纵还没实行终了。举个例子： 我进入了v2ex的页面，此时组件拉作废息信息，接着我几乎不守候便切换至github，此时关于v2ex的拉取还在举行。这就是一种浪费了。 为了处置惩罚它，早先我尝试用saga连系react-router-redux里供应的
LOCATION_CHANGEaction来作为剖断作废之前未完成fetch的标志。 测试发明就算我点击的是同一个link，依旧会触发LOCATION_CHANGE，（真坑啊，完整不相符直觉好么！？）那末有这么一个场景： 当你进入hackerNews守候数据返回，由于时候较久，你不耐烦的再次点击了hackerNews的Link，Boom~~！LOCATION_CHANGEdispatched. 因而乎你的fetch被作废了…，所以用LOCATION_CHANGE作为剖断标志在初次拉取这个场景下是不可行的(论corner case重要性..)， 厥后想出来的处置惩罚方法是在三块消息组件的componentDidMount的顶部dispatch一个STOP_FETCHaction，然后将剖断作废的标志改成:STOP_FETCH，算是处置惩罚了，可总觉得有点暴力，由于一旦组件变多，将要手动。接下来将继承思索更文雅的处置惩罚方案，假如大神们有答案，请示知。
?Gain
最大的收成： 主动找上题目，而不是题目找上你。 不折腾，不踩坑，提高颇微。
当container变多时，直接将container component作为单元，零丁设立目次，然后安排对应的components/styled-components/reducer/action. 这就是按feature构造目次的要领。 仔细的拆分，解耦性更好，以container component为单元举行修改时，大大下降误伤率的同时，断绝无关的信息。
也许总结出一个Learn by doing的心路历程：
被未尝试的手艺吸收，而且有了下一个project的idea
尝试拆分所需妙技，分红组块(裂墙引荐知乎金旭亮先生组块进修论)
冗长的进修历程： 读文档，找样例，写小demo捣腾API。由于组块积聚未完整，所以没法对project周全动手，自然会很焦躁，而且踏出了温馨区，吸收更多的信息。
组块学问积聚终了，project最先施工： 从最简功用需求最先，不停增添新feature: problem -> google -> resolve.
Project成型，评价，修改，革新，more problem come in.
项目总结。然后享用一下自力完成project的成就感。同时也会深刻邃晓自身的不足，为自身的手艺精进之路指清楚明了方向。
以project为单元，轮回以上步骤。
末了的意会： 我早几年干什么去了… 捶胸泪目ing。
⛳️More Feature?
将来能够会补上的：
白噪音组合播放
番茄钟
音乐部份（哈哈哈偷懒了时候不多了，赶忙找工作。）
作为一位新人，还请人人多多指教。一样无耻的求star，2333。
