react

神出鬼没的this 上一篇 挖了个坑，今天给补上 你是不是也曾像我一样： 编写了个函数明明可以正常工作，但是一做为事件回调函数就报 undefind 了 在编写React组件时，看到在构造函数中还得对每个方法bind一下 ： this.funOne = this.funOne.bind(this); this.funTwo = this.funTow.bind(this); 多么奇怪的写法，为啥子还要再bind下呢? 不如删了，然后就各种 undefined 了 要理解为什么会 undefined 还得从 this 说起: var name = 'tianlang'; function getName() { console.log(this.name); } getName(); 这段代码会输出: tianlang 我们只需加一行看是不相关的代码，就能让它报 undefined : var name = 'tianlang'; function getName() { 'use strict' console.log(this.name); } getName(); VM412:4 Uncaught TypeError: Cannot read property 'name' of undefined at getName (<anonymous>:4:22) at

RN 组件的生命周期如下图： 生命周期回调函数 挂载 当组件实例被创建并插入 DOM 中时，其生命周期调用顺序如下： constructor() static getDerivedStateFromProps() render() componentDidMount() 注意: 下述生命周期方法即将过时，在新代码中应该 避免使用它们 ： UNSAFE_componentWillMount() 更新 当组件的 props 或 state 发生变化时会触发更新。组件更新的生命周期调用顺序如下： static getDerivedStateFromProps() shouldComponentUpdate() render() getSnapshotBeforeUpdate() componentDidUpdate() 注意: 下述方法即将过时，在新代码中应该 避免使用它们 ： UNSAFE_componentWillUpdate() UNSAFE_componentWillReceiveProps() 卸载 当组件从 DOM 中移除时会调用如下方法： componentWillUnmount() 错误处理 当渲染过程，生命周期，或子组件的构造函数中抛出错误时，会调用如下方法： static getDerivedStateFromError() componentDidCatch()

背景 早期，Serverless Framework 的定位是偏运维侧，通过 Yaml 文件定义规则，Serverless Framework 负责部署到对应的云厂商。Serverless Framework 提供了一种方案去适配不同的云厂商。 最近 Serverless 提供了一个 Serverless Component 方案，这个方案更面向开发侧。在同一时间，Malagu Framework 也想到了 Component 类似的方案。 Malagu Framework 一开始定位就是偏开发侧的。Malagu Component 与 Serverless Component 解决的问题是一样的：适配不同平台的服务（阿里云函数计算、阿里云 oss、腾讯云函数、aws lambda 等等）和封装通用的业务代码。 Malagu Component 与 Serverless Component 设计上也存在不同的地方，后面可以单独写一篇文章介绍一下。 Malagu 由 CLI + Framework 组成，其中 Framework 本身就是基于 Malagu Component 实现。 简介 Malagu 是基于 TypeScript 的 Serverless First、可扩展和组件化的应用框架。 在 Malagu 的世界里 一切皆组件 ，应用也是组件：根组件

说到状态管理器，轮子满天飞。在 Class 时代，redux 与 mobx 几乎占据了全部市场，几乎没有没用过 redux 的同学。随着 Hooks 的诞生，新的一批轮子应运而生，其中有代表性的有 unstated-next、constate 等等。 当然无论什么轮子，要解决的问题都是一样的：**跨组件状态共享。**在解决这个核心问题的同时，需要尽可能的满足以下几个特性： TypeScript 支持 友好的异步支持 支持状态互相依赖 同时支持 Class 与 Hooks 组件 使用简单 Recoil 体验 最近，facebook 官方出了一个状态管理器解决方案 Recoil ，我们来体验一下。 准备工作 使用 Recoil，我们需要在项目最外层包一个 RecoilRoot ，这个和大部分状态管理器一致，通过 context 来跨组件传递数据。 import React from 'react'; import { RecoilRoot } from 'recoil'; function App() { return ( <RecoilRoot> ... </RecoilRoot> ); } 复制代码 跨组件状态共享 状态最简单的就是定义和使用。在 Recoil 中，通过 atom 来定义一个状态。 const inputValueState = atom({ key:

前端测试工具一览 前端测试工具也和前端的框架一样纷繁复杂，其中常见的测试工具，大致可分为测试框架、断言库、测试覆盖率工具等几类。在正式开始本文之前，我们先来大致了解下它们： 测试框架 测试框架的作用是提供一些方便的语法来描述测试用例，以及对用例进行分组。 测试框架可分为两种： TDD （测试驱动开发）和 BDD （行为驱动开发） 常见的测试框架有 Jasmine, Mocha以及本文要介绍的 Jest。 断言库 断言库主要提供语义化方法，用于对参与测试的值做各种各样的判断。这些语义化方法会返回测试的结果，要么成功、要么失败。常见的断言库有 Should.js, Chai.js等。 测试覆盖率工具 用于统计测试用例对代码的测试情况，生成相应的报表，比如istanbul。 Jest 为什么选择 Jest Jest 是 Facebook 出品的一个测试框架，相对其他测试框架，其一大特点就是就是内置了常用的测试工具，比如自带断言、测试覆盖率工具，实现了开箱即用。 而作为一个面向前端的测试框架， Jest 可以利用其特有的快照测试功能，通过比对 UI 代码生成的快照文件，实现对 React 等常见框架的自动测试。 此外， Jest 的测试用例是并行执行的，而且只执行发生改变的文件所对应的测试，提升了测试速度。目前在 Github 上其 star 数已经破万；而除了 Facebook 外

前端学不动的根本原因是目标感不强或者根本就没有目标。在学习前端之前，我们需要先思考我们要成为一个什么样前端工程师。接下来我们以时间线的方式，来告诉我们什么时间该做什么事儿。本文以普通人为例，也是想给普通人一些思路，结合自己的情况走出自己的路，超人请自行退出。 一、 1-3年（p5-p6） 这个时候大多数是应届生学习知识的积累期，对于前端三剑客：HTML/Javascript/CSS基础的夯实阶段。必看的书有《Javascript权威指南》/《Head First HTML and CSS, XHTML》/HTML方面多看看官方文档或者w3c的标准就成。另外这时候一般的前端工程师，会掌握一门应用级别框架（比如：React/Vue/Angular等等）。虽然使用传统三剑客我们也可以把任务完成，但是使用应用级别的框架还是会提高我们的效率，而且公司在人才招聘的时候应用级别的框架是必问的。不做赘述这个阶段感觉推不动的前端朋友建议推出，做自己更喜欢的事儿去吧。 本阶段关键词：（前端基础、原始积累、HTML/CSS/Javascript、Vue/React/Angular） 二、3-6年（p6-p7） 熬过艰难的初期阶段，接下来2-3年是一个差异化的体验期，在这个时间段通常情况下，前端工程师已经能够胜任所有的业务需求。可能大项目的拆解能力有所欠缺，但是这种能力会通过经验的积累不断积累有所上升

感谢阅读，感谢这几个月来的陪伴，这是今年架构系列的最后一篇。 李熠：【译文】【前端架构鉴赏 01】：Angular 架构模式与最佳实践 ​ zhuanlan.zhihu.com 李熠：【译文】【前端架构鉴赏 02】：可拓展 Angular 2 架构 ​ zhuanlan.zhihu.com 原文： https:// indepth.dev/model-view- presenter-with-angular/ 随着应用程序的日趋庞大，它变得越来越难以维护。随着可复用模块的重要性逐渐递增应用的复杂性也随之增长。我们都意识到我们应该在它面临难以维护的风险之前做些什么 设计模式能够拯救它！ 复杂应用 一个复杂应该至少拥有以下某些特征 组件树中的多个组件展示同一份应用状态 拥有多个更新应用状态的来源： 多个用户同时交互 后端实时推送状态更新给浏览器 后台定时任务 近距离传感器或者其它设备传感器 频繁的更新应用状态 大量的组件 代码量大的组件，回想一下之前的 大泥球 般的 AngularJS controller 组件内部的高度复杂循环——高度集中的逻辑分支和异步控制流 但与此同时，我们希望应用是具有可维护的，可测试的，可拓展的和具有良好性能的 复杂的应用很少拥有所有这些宝贵特征。我们也不能在完成高级功能需求的情况下避免这些所有的特征，但是我们可以通过设计应用来最大化利用它的宝贵特征 译者注

这是一个拥有九年开发经验的程序员进行的分享，讲述了他这么多年从零基础到成为专业工程师的一些经验与心得，希望对各位成长之路会有帮助，共勉！ 1、与程序打交道的人生，是简单的人生 一次规划局的项目，规划局的职员很是钦佩地说：“你们真了不起，在电脑上敲敲键盘就能做出软件来。” 规划局领导说： “跟电脑打交道是最简单的，难的是跟人打交道。” 领导的话很有深意，一语道破了本质，做程序的人，是比较简单的。 2、不懂什么叫编程 大学本科，读“计算机科学与技术专业”（相信大部分小伙伴都是这个专业吧），课程 重理论而轻实践 。 最初学习C语言，对于编程没有任何概念。 一次在课堂上问老师： “计算机输入法，可视化操作界面已经很完善了，为什么要用C语言中 Print() 函数输出一段字符呢？ 而且我们学习使用Console控制台的黑白屏输入输出，也不像是平时使用的软件啊？” 老师听后也是一脸的懵逼，说：“你好好学，慢慢就明白了。” 你不懂的，老师也没法回答你，只有靠自己慢慢地摸索，慢慢去领悟。 3、Java还是C#，平台选择的爱恨情仇 初学Java，这是接触的第一个最具有实用意义的编程语言。 可以做网站，做软件，虽然C语言、C++也可以开发应用软件。 当时的学习，基本是自学，上网下载视频教程，一集一集地看。 不懂的概念上网查，去图书馆借阅相关书籍资料，什么JSP标签、Servlet、JDBC

浏览器渲染机制 Html解析成DOM树，Css解析成CSS树，将DOM树与CSSDOM规则树合并在一起生成Render树，遍历渲染树开始布局，计算每个节点的位置大小信息，将渲染树每个节点绘制到屏幕 阻塞渲染 当浏览器遇到一个script标记时，DOM构建将暂停，直至脚本完成执行，然后继续构建DOM。每次去执行JavaScript脚本都会严重的阻塞DOM树的构建，如果JavaScript脚本还操作了CSSOM，而正好这个CSSOM还没下载和构建，浏览器甚至会延迟脚本执行和构建DOM，直至完成其CSSOM的下载和构建 1.link，script放置位置 浏览器下载脚本时，会阻塞其他资源并行下载，即使是来自不同域名的资源。因此，最好将脚本放在底部，以提高页面加载速度。link的css样式放在head中，引入的包放在自己的js之前。 <!DOCTYPE html> < html lang = " en " > < head > < meta charset = " UTF-8 " /> < meta name = " viewport " content = " width=device-width, initial-scale=1.0 " /> < meta http-equiv = " X-UA-Compatible " content = " ie=edge " /> < title

李熠：前端架构 101（一）：在谈论它们之前我们需要达成的共识 ​ zhuanlan.zhihu.com 李熠：前端架构 101（二）： MVC 初探 ​ zhuanlan.zhihu.com 李熠：前端架构 101（三）：MVC 启示录：模块的职责，作用域和通信 ​ zhuanlan.zhihu.com 李熠：前端架构 101（四）：MVC 的不足与 Flux 的崛起 ​ zhuanlan.zhihu.com 李熠：前端架构 101（五）：从 Flux 进化到 Model-View-Presenter ​ zhuanlan.zhihu.com 整洁架构 如果你对整洁架构（Clean Architecture）有所了解的话，回想一下我们前几篇中描述的内容，你会发现整洁架构对前端，对 MVP 来说也是同样适用的。 关于什么是整洁架构完全可以通过阅读 Uncle Bob 原版图书中文版《整洁架构之道》来了解，或者可以通过阅读他的一个简短版本博客 The Clean Architecture 一探端倪。但我还是推荐阅读图书，图书全面而且浅显易懂，没有和某一门编程语言强行绑定，即使你没有后端背景也能流畅的通读下来。出于篇幅的考虑，在这里我只取一瓢，摘取一个契合于我们前端架构的知识点以做说明，就是 模块间的依赖关系 这篇文章里更多的是告诉你 what（结论），而不是 why（为什么需要这么做