卢泰安 10:07 Dan 画的modern react生命周期图
司徒正美 18:56 不是dan画的
司徒正美 18:56 是昨天他fork的那个人画的
司徒正美 18:57 https://github.com/wojtekmaj/react-lifecycle-methods-diagram ————— 2018-04-07 —————
chenyong 09:35 https://discordapp.com/channels/102860784329052160/193117606629081089 Discord 上的日常 QA
工业聚 10:04 https://twitter.com/ryanflorence/status/982416654280736768
隔夜果酱 11:57 诚心请教各位大佬一个问题,问题如下: js中在函数执行上下文的创建阶段,形参赋值,变量赋值,函数声明, 它们三个的顺序是按照 形参赋值->函数声明->变量赋值这个顺序执行的么? 如果是按照这个步骤,那么变量和函数名重复的情况下,为什么js会保留了函数而放弃了变量? 是所谓的"函数声明比变量优先级要高，并且定义过程不会被变量覆盖，除非是函数字面量形式或被同名函数复写"? 还是说执行顺序为"形参赋值->变量赋值->函数声明",所以函数声明得以保留? 还是说这两种说法都是不对的,因为其他原因? 求大佬们指点迷津,[抱拳]
隔夜果酱 12:03 英文不太好,规范啃起来太吃力了.求指点.
bailnl 12:06 http://yanhaijing.com/es5/ 有中文的 哈哈哈哈哈哈
工业聚 12:13 这类问题，有好几个解释层次
工业聚 12:14 第一个：JS 引擎为什么要这样执行？ 答案是，JS 引擎通常是按照 ECMAScript 规范实现的，如果规范里写着这种情况就那样处理，那就是这样
工业聚 12:14 第二个是：规范为什么要这样设计？
zwhu 12:35 个人觉得只有第一册第一章比较经典
隔夜果酱 12:35 好的,多谢二位大佬指点,我去翻翻看,
Jason²⁰¹⁸ 12:35 第一章是其他js 书没有的
Jeff 12:37 真正项目代码里面完全不可能去利用这些js特有的特性（hoisting之类的） 都是一板一眼的正常代码
隔夜果酱 12:38 我觉得我就是掉坑里了, 这种东西除了面试用用,其他时候基本没啥用.[流泪]
dyf 12:39 这些是内功[呲牙]
Jeff 12:39 而且随着js新特性的出现，这些“旧有”特性应该被划分为糟粕一类的（例如let代替var）
Jeff 12:39 等真正上手了 对全貌有把握了 再根据兴趣去看想看的
Jeff 12:40 内功也分轻重 早几年ie6兼容也是内功
但是刚入门就去学这个 显然是性价比极低的
dyf 12:42 [强]
隔夜果酱 12:44 再次拜谢各位大佬的指导, 从坑外拉了菜鸟一把,把我拉出了这个坑[抱拳]
连杰 12:47 从语法层面去学和记，没多大意义
连杰 12:48 这只会不断陷入新语法的特性的陷阱
连杰 12:48 多看看程序语言设计和实现原理
隔夜果酱 12:50 js这语言太另类了,和主流后端语言的很多思想都不太一致.
连杰 12:51 如果这么认为，注定走不远
隔夜果酱 12:51 我是感觉自己的js基础还是太散,所以在翻这些js精粹,想以此为准来梳理一下所学.
连杰 12:52 你大学应该没学过编译原理
隔夜果酱 12:53 都还给老师了 DuckDuckGo Translator
[bot] 13:06 这娃掉坑里了，js是门高级语言，越高级语言越接近人类语言的越不需要你钻研它的原理。就像学英语，有的地方c就读k，i就读一，h有的发音有的不发音，学的时候还要研究一下吗？都是习惯或者错误用法最后随大流都这么用了。甚至那些古怪的写法不会并从来不写都没关系，因为古怪的写法别人也不写，真的有，放Chrome里跑下记录结果就行
工业聚 13:09 黑格尔：人类不需要知道消化学才能消化食物
工业聚 13:09 费曼：科学哲学之于科学的作用，就像鸟类学之于鸟
工业聚 13:11 js 就是那只鸟，写 js 则是消化食物[偷笑]
隔夜果酱 13:11 看来我的学习方法是有很大问题, 舍本逐末,太在意js这些乱七八糟的细节了, [流泪]
Janry 13:21 现在很多面试风气不好，总想着出一些极端刁钻的问题来考面试者，其实根本没啥用
工业聚 19:31 Haskell 真是丧心病狂，概念接二连三，好不容易熬到 Manod，以为学了之后可以一展拳脚，可以开始写出能干什么活儿的代码。结果继续 State、Alternative、MonadPlus、Monad transformers、Monoids……连绵不绝，相似而又不同，零实战讲解[捂脸]
zwhu 19:32 [捂脸]
chenyong 20:15 @旷奇艺 不好说, 委员会制定的规范, 然后人实现的
chenyong 20:15 https://en.wikipedia.org/wiki/Paul_Hudak 这个有点接近吧
chenyong 20:16 编译器实现主要是 SPJ 搞的 https://en.wikipedia.org/wiki/Simon_Peyton_Jones
Vico 22:52 大家在前端 render 权限是怎么做的？目前有两种想法，一种是构造一个基础的 Auth Component，所有组件都继承自它，一种是采用高阶组件包一下所有的业务组件，想求证一下大家的做法
还呗丶理斯特 22:54 不包高阶组件，所有开发正常进行，用约定的 css 来隐藏那些没权限的部分
还呗丶理斯特 22:55 因为我们发现组件有侵入性，包来包去很容易搞出问题，而 css 很少会去碰，所以很少会改坏
Vico 22:56 那鉴权的部分在哪里做？
Vico 22:56 每个组件里面直接判断权限点？自顶向下传递权限资源？
还呗丶理斯特 22:57 权限是由后端判的，前端只是个显示的友好性问题
Vico 23:00 那就是在开发过程中就把埋点和权限对应的表现都写了,然后把权限点收集起来，后端鉴权，前端查询到后把权限根据一定规则传递到每个组件
Vico 23:02 @
还呗丶理斯特 是吗
还呗丶理斯特 23:03 我们是直接用 classname 去约定这个资源的名字，然后约定在一个页面上不允许重名
Vico 23:03 业务组件之上只要有一个规则去传递资源就行了
还呗丶理斯特 23:03 因为如果真的权限差异很大，基本上会做两个页面
还呗丶理斯特 23:04 一半这种情况就是大多数的功能相同，但是个别人看得见删除按钮，这种情况
zwhu 23:27 把页面上需要鉴权的组件都放到 Child 中 Child 更纯粹些
Alihanniba 23:28 鉴权在后端，前端页面鉴权 我理解用高阶组件更加统一些
Vico 23:29 高阶组件的话类型会很多，一层套一层挺蛋疼的…
zwhu 23:29 这样你的组件其实不太复用了 除非提供两个版本，一个基础的，你一个 hoc wrapper 的
Vico 23:31 我们现在每个组件就提供了三个东西，base component, hoc, decorate，用起来细节太多了
Vico 23:31 想把这个结构干掉
zwhu 23:32 鉴权业务性比较强，作为组件提供方，我不想给每个业务都考虑一次鉴权的事情。 鉴权应该由具体业务方去考虑的
Vico 23:33 那组件粒度就是个大问题了
zwhu 23:33 其实就是怎么划分责任了，责任拎清之后，不管是 hoc 还是其他方式，我个人觉得都没什么问题
Vico 23:43 划分责任最后还是要让业务写的爽，写的干净，侵入性低，可维护，层次清晰就可以，不然链路很深，侵入很高，代码很难继续发展，这么一分析，还是要底层多做些事情业务可能还是应该避免 hoc
zwhu 23:43 不过继承还是hoc我还是都不太喜欢…看情况用renderprops或者直接作为children
zwhu 23:47 我的想法是组件提供方提供基础鉴权组件和普通业务组件。业务方自己去决定页面上哪些地方使用鉴权组件和普通组件的组合。这样即使现在的鉴权满足不了，他完全可以自己替换。基本可以做到解耦