总结
前端资料汇总
开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】
-
框架原理真的深入某一部分具体的代码和实现方式时，要多注意到细节，不要只能写出一个框架。
-
算法方面很薄弱的，最好多刷一刷，不然影响你的工资和成功率😯
-
在投递简历之前，最好通过各种渠道找到公司内部的人，先提前了解业务，也可以帮助后期优秀 offer 的决策。
-
要勇于说不，对于某些 offer 待遇不满意、业务不喜欢，应该相信自己，不要因为当下没有更好的 offer 而投降，一份工作短则一年长则 N 年，为了幸福生活要慎重选择！！！
喜欢这篇文章文章的小伙伴们点赞+转发支持，你们的支持是我最大的动力！ -
在 HMR Runtime 中
-
模块热替换 API(HMR API)
-
- accept
-
decline
-
dispose（或 addDisposeHandler）
-
removeDisposeHandler
-
status
-
check
-
addStatusHandler
-
removeStatusHandler
-
HMR 用例
-
- 启用 HMR
-
HMR 修改样式
-
HMR 修改 js
-
Webpack 多环境多配置文件
-
- 安装webpack-merge
-
示例
-
Tree Shaking
-
- optimization.usedExports
-
代码分离
-
Webpack 构建缓存机制-hash
-
- hash
-
chunkhash
-
contenthash
-
构建目标(Target)
-
外部扩展(Externals)
-
- externals
=================================================================
本质上，webpack 是一个现代 JavaScript 应用程序的静态模块打包器(module bundler)。当 webpack 处理应用程序时，它会递归地构建一个依赖关系图(dependency graph)，其中包含应用程序需要的每个模块，然后将所有这些模块打包成一个或多个 bundle。
在 webpack 配置中有多种方式定义 entry 属性
单个入口（简写）语法
用法：entry: string|Array<string>
// webpack.config.js
const config = {
entry: ‘./src/index.js’,
};
module.exports = config;
entry 属性的单个入口语法，是下面的简写：
const config = {
entry: {
main: ‘./src/index.js’,
},
};
对象语法
用法：entry: {[entryChunkName: string]: string|Array<string>}
const config = {
entry: {
app: ‘./src/app.js’,
vendors: ‘./src/vendors.js’,
},
};
“可扩展的 webpack 配置”是指，可重用并且可以与其他配置组合使用。这是一种流行的技术，用于将关注点(concern)从环境(environment)、构建目标(build target)、运行时(runtime)中分离。然后使用专门的工具（如 webpack-merge）将它们合并。
常见场景
分离 应用程序(app) 和 第三方库(vendor) 入口
const config = {
entry: {
app: ‘./src/app.js’,
vendors: ‘./src/vendors.js’,
},
};
多页面应用程序
const config = {
entry: {
pageOne: ‘./src/pageOne/index.js’,
pageTwo: ‘./src/pageTwo/index.js’,
pageThree: ‘./src/pageThree/index.js’,
},
};
配置 output 选项可以控制 webpack 如何向硬盘写入编译文件。注意，虽然可以存在多个入口起点，但只指定一个输出配置。
用法(Usage)
在 webpack 中配置 output 属性的最低要求是，将它的值设置为一个对象，包括以下两点：
-
filename 用于输出文件的文件名。 -目标输出目
-
path 的绝对路径。
webpack.config.js
const config = {
output: {
path: path.join(__dirname, ‘dist’),
filename: ‘bundle.js’,
},
};
module.exports = config;
多个入口起点
如果配置创建了多个单独的 “chunk”（例如，使用多个入口起点或使用像 splitChuckPlugin —> webpack 4.0 后提供 这样的插件），则应该使用占位符(substitutions)来确保每个文件具有唯一的名称。
const config = {
entry: {
app: ‘./src/app.js’,
search: ‘./src/search.js’,
},
output: {
filename: ‘[name].js’,
path: __dirname + ‘/dist’,
},
};
// 写入到硬盘：./dist/app.js, ./dist/search.js
提供mode配置选项，告知 webpack 使用相应模式的内置优化。
string
用法
只在配置中提供 mode 选项
module.exports = {
mode: ‘production’,
};
或者从 CLI 参数中传递：
webpack --mode=production
| 选项 | 描述 |
| — | — |
| development | 会将 process.env.NODE_ENV 的值设为 development。启用 NamedChunksPlugin 和 NamedModulesPlugin。 |
| production | 将 process.env.NODE_ENV 的值设为 production。启用 FlagDependencyUsagePlugin, FlagIncludedChunksPlugin, ModuleConcatenationPlugin, NoEmitOnErrorsPlugin, OccurrenceOrderPlugin, SideEffectsFlagPlugin 和 UglifyJsPlugin. |
| none | 会将 process.env.NODE_ENV 的值设为 none，不做任何处理 |
记住，只设置 NODE_ENV，则不会自动设置 mode。
loader 用于对模块的源代码进行转换。loader 可以使你在 import 或"加载"模块时预处理文件。因此，loader 类似于其他构建工具中“任务(task)”，并提供了处理前端构建步骤的强大方法。loader 可以将文件从不同的语言（如 TypeScript）转换为 JavaScript，或将内联图像转换为 data URL。loader 甚至允许你直接在 JavaScript 模块中 import CSS 文件！
使用 loader
在你的应用程序中，有三种使用 loader 的方式：
-
配置（推荐）：在 webpack.config.js 文件中指定 loader。
-
内联：在每个 import 语句中显式指定 loader。
-
CLI：在 shell 命令中指定它们。
配置[Configuration]
module.rules 允许你在 webpack 配置中指定多个 loader。 这是展示 loader 的一种简明方式，并且有助于使代码变得简洁。同时让你对各个 loader 有个全局概览：
const config = {
module: {
rules: [
{
test: /.css$/,
use: [
{ loader: ‘style-loader’ },
{
loader: ‘css-loader’,
options: {
modules: true,
},
},
],
},
],
},
};
内联
可以在 import 语句或任何等效于 “import” 的方式中指定 loader。使用 ! 将资源中的 loader 分开。分开的每个部分都相对于当前目录解析。
import Styles from ‘style-loader!css-loader?modules!./styles.css’;
通过前置所有规则及使用 !，可以对应覆盖到配置中的任意 loader。
选项可以传递查询参数，例如 ?key=value&foo=bar，或者一个 JSON 对象，例如 ?{“key”:“value”,“foo”:“bar”}。
尽可能使用 module.rules，因为这样可以减少源码中的代码量，并且可以在出错时，更快地调试和定位 loader 中的问题。
CLI
webpack --module-bind jade-loader --module-bind ‘css=style-loader!css-loader’
这会对 .jade 文件使用 jade-loader，对 .css 文件使用 style-loader 和 css-loader。
loader 特性
-
loader 支持链式传递。能够对资源使用流水线(pipeline)。一组链式的 loader 将按照相反的顺序执行。
-
loader 链中的第一个 loader 返回值给下一个 loader。在最后一个 loader，返回 webpack 所预期的 JavaScript。
-
loader 可以是同步的，也可以是异步的。
-
loader 运行在 Node.js 中，并且能够执行任何可能的操作。
-
loader 接收查询参数。用于对 loader 传递配置。
-
loader 也能够使用 options 对象进行配置。
-
除了使用 package.json 常见的 main 属性，还可以将普通的 npm 模块导出为 loader，做法是在 package.json 里定义一个 loader 字段。
-
插件(plugin)可以为 loader 带来更多特性。
-
loader 能够产生额外的任意文件。
插件是 webpack 的支柱功能。webpack 自身也是构建于，你在 webpack 配置中用到的相同的插件系统之上！
插件目的在于解决 loader 无法实现的其他事。
剖析
webpack 插件是一个具有 apply 属性的 JavaScript 对象。apply 属性会被 webpack compiler 调用，并且 compiler 对象可在整个编译生命周期访问。
用法
由于插件可以携带参数/选项，你必须在 webpack 配置中，向 plugins 属性传入 new 实例。
根据你的 webpack 用法，这里有多种方式使用插件。
配置
const HtmlWebpackPlugin = require(‘html-webpack-plugin’); //通过 yarn或者npm 安装
const webpack = require(‘webpack’); //访问内置的插件
const path = require(‘path’);
const config = {
entry: ‘./src/index.js’,
output: {
filename: ‘bundle.js’,
path: path.resolve(__dirname, ‘dist’),
},
module: {
rules: [
{
test: /.(js|jsx)$/,
use: ‘babel-loader’,
},
],
},
plugins: [
new webpack.optimize.UglifyJsPlugin(),
new HtmlWebpackPlugin({ template: ‘./src/index.html’ }),
],
};
module.exports = config;
Node API
即便使用 Node API，用户也应该在配置中传入 plugins 属性。compiler.apply 并不是推荐的使用方式。
// some-node-script.js
const webpack = require(‘webpack’); //访问 webpack 运行时(runtime)
const configuration = require(‘./webpack.config.js’);
let compiler = webpack(configuration);
compiler.apply(new webpack.ProgressPlugin());
compiler.run(function (err, stats) {
// …
});
以上看到的示例和webpack 自身运行时(runtime) 极其类似。webpack 源码 中隐藏有大量使用示例，你可以用在自己的配置和脚本中。
在每次编译代码时，手动运行 npm run build 会显得很麻烦。
webpack 提供几种可选方式，帮助你在代码发生变化后自动编译代码：
-
webpack watch mode(webpack 观察模式)
-
webpack-dev-server
-
webpack-dev-middleware
大多数场景下我们会使用 webpack-dev-server
使用 watch mode(观察模式)
你可以指示 webpack “watch” 依赖图中所有文件的更改。如果其中一个文件被更新，代码将被重新编译，所以你不必再去手动运行整个构建。
启动 webpack watch mode
webpack --watch
如果能够自动刷新浏览器就更好了，因此可以通过 browser-sync 实现此功能。
缺点: 每次编译都要读写磁盘
使用 webpack-dev-server
webpack-dev-server 为你提供了一个简单的 web server，并且具有 live reloading(实时重新加载) 功能。
安装
npm i webpack-dev-server -D
// webpack.config.js
module.exports = {
devServer: {
// 当使用内联模式(inline mode)时，控制台(console)将显示消息，可能的值有 none, error, warning 或者 info（默认值）。
clientLogLevel: ‘none’,
//当使用 HTML5 History API 时，任意的 404 响应都可能需要被替代为 index.html
historyApiFallback: {
index: index.html,
},
// 启用 webpack 的模块热替换特性
hot: true,
// 告诉服务器从哪里提供内容。只有在你想要提供静态文件时才需要。我们这里直接禁用掉
contentBase: false,
// 一切服务都启用gzip 压缩：
compress: true,
// 指定使用一个 host。默认是 localhost
host: ‘localhost’,
// 指定要监听请求的端口号
port: ‘8000’,
// local服务器自动打开浏览器。
open: true,
// 当出现编译器错误或警告时，在浏览器中显示全屏遮罩层。默认情况下禁用。
overlay: false,
// 浏览器中访问的相对路径
publicPath: ‘’,
// 代理配置
proxy: {
‘/api/’: {
target: ‘https://github.com/’,
changeOrigin: true,
logLevel: ‘debug’,
},
},
// 除了初始启动信息之外的任何内容都不会被打印到控制台。这也意味着来自 webpack 的错误或警告在控制台不可见。
// 我们配置 FriendlyErrorsPlugin 来显示错误信息到控制台
quiet: true,
// webpack 使用文件系统(file system)获取文件改动的通知。监视文件 https://webpack.js.org/configuration/dev-server/#devserver-watchoptions-
watchOptions: {
poll: false,
},
disableHostCheck: true,
},
};
webpack-dev-server 具有许多可配置的选项。关于其他更多配置，请查看配置文档
使用 webpack-dev-middleware
此选项控制是否生成，以及如何生成source map
使用 SourceMapDevToolPlugin 进行更细粒度的配置。查看 source-map-loader 来处理已有的 source map。
devtool
string false
选择一种 source map 格式来增强调试过程。不同的值会明显影响到构建(build)和重新构建(rebuild)的速度。
你可以直接使用 SourceMapDevToolPlugin/EvalSourceMapDevToolPlugin 来替代使用 devtool 选项，因为它有更多的选项。切勿同时使用 devtool 选项和 SourceMapDevToolPlugin/EvalSourceMapDevToolPlugin 插件。devtool 选项在内部添加过这些插件，所以你最终将应用两次插件。
git 仓库 里有用于测试 Source Map 示例，便于理解下面的 Source Map 对比表格
| devtool | 构建速度 | 重新构建速度 | 生产环境 | 质量(quality) |
| — | — | — | — | — |
| none | +++ | +++ | yes | 打包后的代码 |
| eval | +++ | +++ | no | 生成后的代码 |
| cheap-eval-source-map | + | ++ | no | 转换过的代码（仅限行） |
| cheap-module-eval-source-map | o | ++ | no | 原始源代码（仅限行） |
| eval-source-map | – | + | no | 原始源代码 |
| cheap-source-map | + | o | no | 转换过的代码（仅限行） |
| cheap-module-source-map | o | - | no | 原始源代码（仅限行） |
| inline-cheap-source-map | + | o | no | 转换过的代码（仅限行） |
| inline-cheap-module-source-map | o | - | no | 原始源代码（仅限行） |
| source-map | – | – | yes | 原始源代码 |
| inline-source-map | – | – | no | 原始源代码 |
| hidden-source-map | – | – | yes | 原始源代码 |
| nosources-source-map | – | – | yes | 无源代码内容 |
+++ 非常快速, ++ 快速, + 比较快, o 中等, - 比较慢, – 慢
其中一些值适用于开发环境，一些适用于生产环境。对于开发环境，通常希望更快速的 source map，需要添加到 bundle 中以增加体积为代价，但是对于生产环境，则希望更精准的 source map，需要从 bundle 中分离并独立存在。
质量(quality)说明
- 打包后的代码
将所有生成的代码视为一大块代码。你看不到相互分离的模块。
- 生成后的代码
每个模块相互分离，并用模块名称进行注释。可以看到 webpack 生成的代码。示例：你会看到类似 var moduleWEBPACK_IMPORTED_MODULE_1 = webpack_require(42); moduleWEBPACK_IMPORTED_MODULE_1.a();，而不是 import {test} from “module”; test();。
- 转换过的代码
每个模块相互分离，并用模块名称进行注释。可以看到 webpack 转换前、loader 转译后的代码。示例：你会看到类似 import {test} from “module”; var A = function(_test) { … }(test);，而不是 import {test} from “module”; class A extends test {}。
- 原始源代码
每个模块相互分离，并用模块名称进行注释。你会看到转译之前的代码，正如编写它时。这取决于 loader 支持。
- 无源代码内容
source map 中不包含源代码内容。浏览器通常会尝试从 web 服务器或文件系统加载源代码。你必须确保正确设置 output.devtoolModuleFilenameTemplate，以匹配源代码的 url。
- （仅限行）
source map 被简化为每行一个映射。这通常意味着每个语句只有一个映射（假设你使用这种方式）。这会妨碍你在语句级别上调试执行，也会妨碍你在每行的一些列上设置断点。与压缩后的代码组合后，映射关系是不可能实现的，因为压缩工具通常只会输出一行。
对于开发环境
以下选项非常适合开发环境：
- eval
每个模块都使用 eval() 执行，并且都有 //@ sourceURL。此选项会非常快地构建。主要缺点是，由于会映射到转换后的代码，而不是映射到原始代码（没有从 loader 中获取 source map），所以不能正确的显示行数。
- eval-source-map
每个模块使用 eval() 执行，并且 source map 转换为 DataUrl 后添加到 eval() 中。初始化 source map 时比较慢，但是会在重新构建时提供比较快的速度，并且生成实际的文件。行数能够正确映射，因为会映射到原始代码中。它会生成用于开发环境的最佳品质的 source map。
- cheap-eval-source-map
类似 eval-source-map，每个模块使用 eval() 执行。这是 “cheap(阉割版)” 的 source map，因为它没有生成列映射(column mapping)，只是映射行数。它会忽略源自 loader 的 source map，并且仅显示转译后的代码，就像 eval devtool。
- cheap-module-eval-source-map
类似 cheap-eval-source-map，并且，在这种情况下，源自 loader 的 source map 会得到更好的处理结果。然而，loader source map 会被简化为每行一个映射(mapping)。
特定场景
以下选项对于开发环境和生产环境并不理想。他们是一些特定场景下需要的，例如，针对一些第三方工具。
- inline-source-map
source map 转换为 DataUrl 后添加到 bundle 中。
- cheap-source-map
没有列映射(column mapping)的 source map，忽略 loader source map。
- inline-cheap-source-map
类似 cheap-source-map，但是 source map 转换为 DataUrl 后添加到 bundle 中。
- cheap-module-source-map
没有列映射(column mapping)的 source map，将 loader source map 简化为每行一个映射(mapping)。
- inline-cheap-module-source-map
类似 cheap-module-source-map，但是 source map 转换为 DataUrl 添加到 bundle 中。
对于生产环境
这些选项通常用于生产环境中：
- none（省略 devtool 选项）
不生成 source map。这是一个不错的选择。
- source-map
整个 source map 作为一个单独的文件生成。它为 bundle 添加了一个引用注释，以便开发工具知道在哪里可以找到它。
你应该将你的服务器配置为，不允许普通用户访问 source map 文件！
- hidden-source-map
与 source-map 相同，但不会为 bundle 添加引用注释。如果你只想 source map 映射那些源自错误报告的错误堆栈跟踪信息，但不想为浏览器开发工具暴露你的 source map，这个选项会很有用。
你不应将 source map 文件部署到 web 服务器。而是只将其用于错误报告工具。
- nosources-source-map
创建的 source map 不包含 sourcesContent(源代码内容)。它可以用来映射客户端上的堆栈跟踪，而无须暴露所有的源代码。你可以将 source map 文件部署到 web 服务器。
这仍然会暴露反编译后的文件名和结构，但它不会暴露原始代码。
在使用 uglifyjs-webpack-plugin 时，你必须提供 sourceMap：true 选项来启用 source map 支持。
模块热替换(HMR - Hot Module Replacement)功能会在应用程序运行过程中替换、添加或删除模块，而无需重新加载整个页面。主要是通过以下几种方式，来显著加快开发速度：
-
保留在完全重新加载页面时丢失的应用程序状态。
-
只更新变更内容，以节省宝贵的开发时间。
-
调整样式更加快速 - 几乎相当于在浏览器调试器中更改样式。
在应用程序中
通过以下步骤，可以做到在应用程序中置换(swap in and out)模块：
-
应用程序代码要求 HMR runtime 检查更新。
-
HMR runtime（异步）下载更新，然后通知应用程序代码。
-
应用程序代码要求 HMR runtime 应用更新。
-
HMR runtime（同步）应用更新。
你可以设置 HMR，以使此进程自动触发更新，或者你可以选择要求在用户交互时进行更新。
在编译器中
除了普通资源，编译器(compiler)需要发出 “update”，以允许更新之前的版本到新的版本。“update” 由两部分组成：
-
更新后的 manifest(JSON)
-
一个或多个更新后的 chunk (JavaScript)
manifest 包括新的编译 hash 和所有的待更新 chunk 目录。每个更新 chunk 都含有对应于此 chunk 的全部更新模块（或一个 flag 用于表明此模块要被移除）的代码。
编译器确保模块 ID 和 chunk ID 在这些构建之间保持一致。通常将这些 ID 存储在内存中（例如，使用 webpack-dev-server 时），但是也可能将它们存储在一个 JSON 文件中。
在模块中
HMR 是可选功能，只会影响包含 HMR 代码的模块。举个例子，通过 style-loader 为 style 样式追加补丁。为了运行追加补丁，style-loader 实现了 HMR 接口；当它通过 HMR 接收到更新，它会使用新的样式替换旧的样式。
类似的，当在一个模块中实现了 HMR 接口，你可以描述出当模块被更新后发生了什么。然而在多数情况下，不需要强制在每个模块中写入 HMR 代码。如果一个模块没有 HMR 处理函数，更新就会冒泡(bubble up)。这意味着一个简单的处理函数能够对整个模块树(complete module tree)进行更新。如果在这个模块树中，一个单独的模块被更新，那么整组依赖模块都会被重新加载。
有关 module.hot 接口的详细信息，请查看 HMR API 页面。
在 HMR Runtime 中
这些事情比较有技术性……如果你对其内部不感兴趣，可以随时跳到 HMR API 页面或 HMR 用例。
对于模块系统的 runtime，附加的代码被发送到 parents 和 children 跟踪模块。在管理方面，runtime 支持两个方法 check 和 apply。
check 发送 HTTP 请求来更新 manifest。如果请求失败，说明没有可用更新。如果请求成功，待更新 chunk 会和当前加载过的 chunk 进行比较。对每个加载过的 chunk，会下载相对应的待更新 chunk。当所有待更新 chunk 完成下载，就会准备切换到 ready 状态。
apply 方法将所有被更新模块标记为无效。对于每个无效模块，都需要在模块中有一个更新处理函数(update handler)，或者在它的父级模块们中有更新处理函数。否则，无效标记冒泡，并也使父级无效。每个冒泡继续，直到到达应用程序入口起点，或者到达带有更新处理函数的模块（以最先到达为准，冒泡停止）。如果它从入口起点开始冒泡，则此过程失败。
之后，所有无效模块都被（通过 dispose 处理函数）处理和解除加载。然后更新当前 hash，并且调用所有 “accept” 处理函数。runtime 切换回闲置状态(idle state)，一切照常继续。
如果已经通过 HotModuleReplacementPlugin 启用了 HMR，则它的接口将被暴露在 module.hot 属性下面。通常，用户先要检查这个接口是否可访问，然后再开始使用它。举个例子，你可以这样 accept 一个更新的模块：
if (module.hot) {
module.hot.accept(‘./library.js’, function () {
// 使用更新过的 library 模块执行某些操作…
});
}
accept
接受(accept)给定依赖模块的更新，并触发一个回调函数来对这些更新做出响应。
module.hot.accept(
dependencies, // 可以是一个字符串或字符串数组
callback, // 用于在模块更新后触发的函数
);
使用 ESM import 时，将从依赖项中导入的所有符号自动更新。 注意：依赖项字符串必须与 import 中的 from 字符串完全匹配。 在某些情况下，甚至可以省略 callback。 在回调中使用 require()没有意义。
使用 CommonJS 时，您需要通过在 callback 中使用 require()来手动更新依赖项。 省略 callback 在这里没有意义。
decline
拒绝给定依赖模块的更新，使用decline方法强制更新失败。
module.hot.decline(
dependencies, // 可以是一个字符串或字符串数组
);
dispose（或 addDisposeHandler）
添加一个处理函数，在当前模块代码被替换时执行。此函数应该用于移除你声明或创建的任何持久资源。如果要将状态传入到更新过的模块，请添加给定 data 参数。更新后，此对象在更新之后可通过 module.hot.data 调用。
module.hot.dispose((data) => {
// 清理并将 data 传递到更新后的模块……
});
removeDisposeHandler
删除由 dispose 或 addDisposeHandler 添加的回调函数。
module.hot.removeDisposeHandler(callback);
status
取得模块热替换进程的当前状态。
module.hot.status(); // 返回以下字符串之一……
| Status | 描述 |
| — | — |
| idle | 该进程正在等待调用 check（见下文） |
| check | 该进程正在检查以更新 |
| prepare | 该进程正在准备更新（例如，下载已更新的模块） |
| ready | 此更新已准备并可用 |
| dispose | 该进程正在调用将被替换模块的 dispose 处理函数 |
| apply | 该进程正在调用 accept 处理函数，并重新执行自我接受(self-accepted)的模块 |
| abort | 更新已中止，但系统仍处于之前的状态 |
| fail | 更新已抛出异常，系统状态已被破坏 |
check
测试所有加载的模块以进行更新，如果有更新，则应用它们。
module.hot
.check(autoApply)
.then((outdatedModules) => {
// 超时的模块……
})
.catch((error) => {
// 捕获错误
});
autoApply 参数可以是布尔值，也可以是 options，当被调用时可以传递给 apply 方法
可选的 options 对象可以包含以下属性：
| options | 描述 |
| — | — |
| ignoreUnaccepted (boolean) | 忽略对未接受的模块所做的更改。 |
| ignoreDeclined (boolean) | 忽略对拒绝的模块所做的更改。 |
| ignoreErrored (boolean) | 忽略接受处理函数，错误处理函数以及重新评估模块时抛出的错误。 |
| onDeclined (function(info)) | 拒绝模块的通知者 |
| onUnaccepted (function(info)) | 未接受模块的通知程序 |
| onAccepted (function(info)) | 接受模块的通知者 |
| onDisposed (function(info)) | 废弃模块的通知者 |
| onErrored (function(info)) | 异常通知者 |
info 参数可能存在以下对象：
{
type: “self-declined” | “declined” |
“unaccepted” | “accepted” |
“disposed” | “accept-errored” |
“self-accept-errored” | “self-accept-error-handler-errored”,
moduleId: 4, // The module in question.
dependencyId: 3, // For errors: the module id owning the accept handler.
chain: [1, 2, 3, 4], // For declined/accepted/unaccepted: the chain from where the update was propagated.
parentId: 5, // For declined: the module id of the declining parent
outdatedModules: [1, 2, 3, 4], // For accepted: the modules that are outdated and will be disposed
outdatedDependencies: { // For accepted: The location of accept handlers that will handle the update
5: [4]
},
error: new Error(…), // For errors: the thrown error
originalError: new Error(…) // For self-accept-error-handler-errored:
// the error thrown by the module before the error handler tried to handle it.
}
addStatusHandler
总结一下
面试前要精心做好准备，简历上写的知识点和原理都需要准备好，项目上多想想难点和亮点，这是面试时能和别人不一样的地方。
还有就是表现出自己的谦虚好学，以及对于未来持续进阶的规划，企业招人更偏爱稳定的人。
开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】
万事开头难，但是程序员这一条路坚持几年后发展空间还是非常大的，一切重在坚持。
为了帮助大家更好更高效的准备面试，特别整理了《前端工程师面试手册》电子稿文件。
前端面试题汇总
JavaScript
性能
linux
前端资料汇总
前端工程师岗位缺口一直很大，符合岗位要求的人越来越少，所以学习前端的小伙伴要注意了，一定要把技能学到扎实，做有含金量的项目，这样在找工作的时候无论遇到什么情况，问题都不会大。
9030
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
