我是工业聚，可以来问我任何问题！
您好！我想请问一下，非计算机相关专业自学的前端，现在大四在实习，想工作几年有机会跳槽去大厂，需要系统的学习一些后端的知识吗，比如数据库，算法等等，还有在工作项目中要多积累哪些方面，可以在简历上有亮点
你好, 我挺好奇有没有什么功能是在 Angular, Ember, Svelt, Vue 或者其他某框架当中你喜欢的, 但是在 React 当中并没有支持的?
你好，昨天开发react项目遇到一个问题，a、b两个路由，从a跳转到b，在b路由中进行了一些操作，改变了b路由相关的state的状态，再从b路由跳转到a路由再跳回b路由，这个时候b路由的相关state是之前改变之后的，如何能回到初始化时候的状态呢？
然后想请教一下，一年左右工作经验的前端应该如何去有更好的技术发展呢，感觉工作上的很多内容都是在反复的造轮子，没有足够的深度和广度，可复制粘贴性太高。
感谢您的回答！
你好，
其实我一开始还想了几个问题去问你，不过转念一想都是 Google 能解决的，就不强问技术或者学习能力方面的了。
就是闲聊一下，有没有什么技术或者知识对你来说只是 Just for fun 所以才去掌握的。
请教个工程问题。
团队运用webpack打包前端代码，转译后的文件每次都需要push到代码库远端；从开发角度而言，是不希望这部分代码在代码库的；两个原因：1是不方便代码review，2是代码仓库不纯净；还有就是公司目前的发布系统，只支持从远端仓库某个分支拉取静态资源推送到服务器端。如何不上传打包后的文件到代码仓库又能顺利发布？
您好，请问一下react-imvc是为了解决什么痛点而出现的呢？或者说，传统的React配合redux有哪些弊端是需要靠react-imvc去解决的？这个框架适用于什么样的项目呢？
您好，我也希望能像您一样去造一些类似于react-lite和react-imvc这些轮子，我想知道在那之前需要准备哪些呢？比如理论方面，需要先深入阅读现有的主流的一些库的源码？可能很多时候花点时间能读懂某些库的源码，也知道它的主要实现的一些原理，但是真的说想像他们一样也去写一个开源的库又无从下手，没有任何思路。想知道您在写react-imvc之前，做了哪些准备和考虑？可能问得有点杂，但是总结一下就是，对于没有轮子经验的小白，如何造出高水平的轮子？
不好意思，问题有点多，最后一个问题
，目前公司比较大，大公司的通病就是可能每个人都是螺丝钉，只在自己的岗位上去做事情，但是带来的问题就是自己可能会很长时间只钻一个地方，比如我是前端，可能就一直写页面，用RN，就一直用RN，我希望强化自己的后端或者其它框架，但是却没有办法，时间久了担心自己其它方面会越来越弱，也许某一块会比较熟练，但是毕竟范围有限，请问如何解决这一现状呢？或者说从自身角度出发，如何去改变它呢？
你好，请问对于其他的框架，如Vue, Angular, Ember, Backbone等等了解多不多？为何当初选择深入钻研React？你认为对于常用React的程序员来说，学习其他前端框架的时候有什么需要特别注意的吗？
工业聚你好。
我是一个什么都接触的二傻搬砖，有以下问题想请教一下：
-
我主要想应用一下机器学习，这样学习伊始是否需要一些大学数学基础（全忘了，如果需要还要复习一下），下手建议从传统机器学习算法还是直接上深度学习的框架
-
React / Vue / Angular 这类框架已经极大的方便了前端工程师的开发，您觉得未来的前端框架演化会接着朝一个怎么样的方向发展，是否还会有 jQuery -> MVVM 的跳跃式改变。
-
想看看您对未来前端职责和后端职责的看法，因为目前有许多项目的后端其实也是由我们「前端」来执行完成的，前后端的界限似乎越来越模糊。
-
对于目前业界「知识付费」你有什么看法吗？或者对于现在前端圈造网红的现象有什么看法。您接触过这样经常「知识付费」的人吗？是否会影响正常的工作和知识积累。
-
对于「前端门槛低」的说法您有什么看法，前端门槛低到底是一种好现象还是一种泥石流？
-
在社招招聘开发时，您更看重学习能力还是之前所做的项目的匹配度。
这个问题我在几个地方回答过。比如survivejs里的访谈。
在微信群「ReactJS中文」里提到过：
react 13 年底左右开源，react-like 的库在 15 年底开始涌现，恰好是 react 进入 v14.0 并且 api 保持兼容和稳定的状态。13年底到15年底之间，虽然有 virtual-dom.js ，但没有没看严肃的 react-like 尝试。这期间 react api 也频繁变化，正如现在 react v16。从这个角度解读，可以认为现在处于时候未到，react-fiber 的特性还没稳定，价值还没被充分证明，并非一个跟进的好时机。
另一个层面是，react-fiber 架构的复杂性和实现难度。比如，即便是最小化 react-fiber 可能也不小。比如，react-fiber 让 react 体积已经足够小（react 体积确实变小了），react 自身就更轻量，其他轻量版也失去市场竞争力了。如果 gzip 之后，相比原版 react 体积优势不显著，那就没有太大意义。
对于 react-like 库来说，也有一个乐观方向。react-fiber 是 react-fiber，基于 react-fiber 的 react public api，未必需要完整的 react-fiber 实现。就像 react 里的 virtual-dom 可能是最庞杂的一个实现一样，fb 里用 react-fiber 实现异步渲染，不代表这是一条唯一的路。
不管是悲观方向，还是乐观方向，现在都包含巨大的不确定因素。等 React V16/17 新特性稳定下来，才能准确评估，跟进的难度、意义和价值。
另外一点，js 的体积问题，可以有其它解决之道。比如 SSR, 骨架屏、service-worker 等。
现在可能不是跟进的好时机，可以把精力放到其他性价比更高的事情上。可以玩新东西，也有很多，reasonml, wasm, pwa, ssr, isomorphic 等等。
不管是技术深度还是广度，都依赖于一个扎实的技术基础。如果还没有通读过《JavaScript权威指南》、《JavaScript 高级程序设计》、《JavaScript DOM编程艺术》等经典书籍，可以开始啃起来了。
然后，可以开始实现常见的 UI 和交互效果，比如轮播图，移动端的 swiper，Tab 切换，下拉刷新等等。每一种效果，都有从低到高的完成度。比如。轮播图里，有无小圆点切换，有无左右箭头，是否支持定时轮播，是否可以无限循环地轮播，是否支持移动端 touch 事件等等，都反映了你写的效果的完备性和完成度。不断地提高它们，同时也就打磨了 JS 编程能力。
其他还有模板引擎（templte engine），lodash/underscore，jquery/zepto，react/vue 等不同类型的库或框架，先不看它们的源码，按照你对其 API 的理解，仿写一个最小可运行版本。再去看它们源码，印证你的实现跟原版实现的差异。
技术的深度和广度，都是积累而来的，无法一蹴而就。如果没有相对严酷的历练，难以沉淀下来深刻的知识和领悟。
你的问题跟二楼的有点类似，可以参考对二楼的回答。
这里可以再总结一下，我们可以回顾自己现在掌握的知识和技能，可以发现，绝大多数都来自于曾经的严酷训练（如高中彻夜复习、暑假集中培训等）。那是一段当时并不轻松，但回想起来很充实的状态。有人称之为「学习区」，在「学习区」我们不轻松但成长最快。在「舒适区」我们很轻松，但成长较慢；在「恐慌区」，我们无所适从，只想逃离。
现在让你直接看 react/vue 的源码，可能直接进入了你的「恐慌区」，觉得自己水平很差、人很蠢。我们需要找到自己的「学习区」，每个阶段我们的学习区都是不同的。如果没有打好基础，那么「学习区」会一直停留在基础知识的层面，一进入更高领域，就会感到不适和恐慌。基础知识是每个学习者无法逃避的一个学习阶段，一定要通过某种方式突破它，并且这个方式一定不是轻松的（不是舒适区）。
「拖延现象」是逃避有难度的事情，沉迷自己舒适区的一种行为表现。在现在信息碎片化和信息娱乐化的时代，让人立刻得到短暂愉悦（如看抖音、刷微博、微信等）的事物太多了。需要鼓起很大的意志，刻意让自己去做有难度的事情，并坚持去做。最后会有显著成长。
先明确自己有要去改变的意愿，再强迫自己有尝试去改变的行为，并开始对自己的不作为，感到愤怒。从内心形成自趋力，最后形成习惯。初期必定痛苦，习惯之后可以体会到乐趣。
我学习「机器学习」的方式是「边学边做」，尽可能把自己学习到的知识，体现在代码上。
一开始，并不使用 keras，tensorflow 等库或者框架，而是自己根据机器学习里的算法介绍，裸写一个最小可运行实现。
我没有去刻意啃数学以补充所谓基础知识。图片加载有两种方式，一种是从上到下加载，图片虽然只展示半截，但是清晰的；另一种是从模糊到清晰加载，图片虽然展示了全部尺寸，但一开始是模糊的。我认为学习应该走后者路线。先有 big picture 一个纲领和大概，然后不断细化知识，对这个领域有更清晰的理解。如果从所谓的数学基础补起，恐怕连什么学到什么程度才算有基础，都难以确定。
另外，边做边学，也可以让数学知识学起来更灵动和真切，它不仅仅是公式，还是代码，也是代码运行后的现象；理解的维度得到了拓展。
当然，我目前的「机器学习」水平还很低，在这个领域的投入还不够多（毕竟还有本职工作要做）。上面只是介绍一下我个人的学习策略，未必适合其他人。权当参考。
是的，主要跟 suspend 特性有关。
react suspend 特性的实现机制是，重复执行 render 流程。第一次执行 render 时，fetcher.read 方法里的 promise 如果还没有 resolve，就 throw promise，终止此次渲染。然后进入 componentDidCatch 的阶段，catch 到 promise 后，在 promise.then 时，再次触发渲染流程。
这个机制要求async-safe，类似于 restful api 里两次 get 请求预期拿到一样的结果，虽然第一次 get 被 abort 了，但不应该影响第二次 get 到的结果。
上面说的是「重复执行 render 流程」，而非「重复执行 render 方法」，「render 流程」里包含 componentWillMount、componentWillReceiveProps 和 componentWillUpdate 等生命周期，如果在这些生命周期里操作了 component 实例的属性或调用了有副作用的方法，那么两次渲染流程就无法满足「幂等」要求。
所以，干掉 will*，把 willReceiveProps 挪出到静态方法 getDerivedStateFromProps，可以防止开发者操作 component 实例，增加 async-safe 的安全性。