先自我介绍一下,小编浙江大学毕业,去过华为、字节跳动等大厂,目前阿里P7
深知大多数程序员,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年最新Web前端全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上前端开发知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
如果你需要这些资料,可以添加V获取:vip1024c (备注前端)
正文
proposal-top-level-await这个提案感觉就没有啥展开描述的必要了,很多人应该已经用上了。简单地说,就是你的 await
语法不再和 async
强绑定了,你可以直接在应用的最顶层使用 await
语法而不再需要套一个 async
函数,NodeJS也从 14.8 开始支持了这一提案。
Import Assertions (stage 3)
proposal-import-assertions 这一提案为导入语句新增了用于标识模块类型的断言语句,语法如下:
import json from “./foo.json” assert { type: “json” };
import(“foo.json”, { assert: { type: “json” } });
注意,对 JSON 模块的导入最开始属于这一提案的一部分,后续被独立出来作为一个单独的提案:proposal-json-modules。
这一提案最初起源于为了在 JavaScript 中更便捷的导入 JSON 模块,后续出于安全性考虑加上了 import assertions
来作为导入不可执行模块的必须条件。
这一提案同样解决了模块类型与其 MIME 类型不符的情况,并且,和现在如火如荼的基于 ESM 的 Bundleless 工具结合应该会有奇妙的化学反应,期待 Vite3.0 能安排上这个提案。
Error Cause (stage 3)
proposal-error-cause这一提案目前由淘系技术部的昭朗同学在推进,其目的主要是为了便捷的传递导致错误的原因,如果不使用这个模块,想要清晰的跨越多个调用栈传递错误上下文信息,通常要这么做:
async function getSolution() {
const rawResource = await fetch(‘//domain/resource-a’)
.catch(err => {
// 想想要怎么抛出一个携带有效信息的错误?
// 直接抛出个异常?
// 1. throw new Error('Download raw resource failed: ’ + err.message);
// 实例化一个error再指定属性?
// 2. const wrapErr = new Error(‘Download raw resource failed’);
// wrapErr.cause = err;
// throw wrapErr;
// 创建Error的子类?
// 3. class CustomError extends Error {
// constructor(msg, cause) {
// super(msg);
// this.cause = cause;
// }
// }
// throw new CustomError(‘Download raw resource failed’, err);
})
const jobResult = doComputationalHeavyJob(rawResource);
await fetch(‘//domain/upload’, { method: ‘POST’, body: jobResult });
}
await doJob(); // => TypeError: Failed to fetch
看起来好像都不太直观?而按照这一提案的语法:
async function doJob() {
const rawResource = await fetch(‘//domain/resource-a’)
.catch(err => {
throw new Error(‘Download raw resource failed’, { cause: err });
});
const jobResult = doComputationalHeavyJob(rawResource);
await fetch(‘//domain/upload’, { method: ‘POST’, body: jobResult })
.catch(err => {
throw new Error(‘Upload job result failed’, { cause: err });
});
}
Decorators (stage 2)
proposal-decorators这一提案…,或许是我们最熟悉的老朋友了。但是此装饰器非彼装饰器,历时五年来装饰器提案已经走到了第三版,仍然卡在 stage 2。
来看看它现在的实现是这样的,是不是感觉有点诡异?
decorator
这里引用笔者早前的一篇文章来简单讲述下装饰器的历史:
首先我们需要知道,JS 与 TS 中的装饰器不是一回事,JS 中的装饰器目前依然停留在 stage 2 阶段,并且目前版本的草案与 TS 中的实现差异相当之大(TS 是基于第一版,JS 目前已经第三版了),所以二者最终的装饰器实现必然有非常大的差异。
其次,装饰器不是 TS 所提供的特性(如类型、接口),而是 TS 实现的 ECMAScript 提案(就像类的私有成员一样)。TS 实际上只会对 stage-3 以上的语言提供支持,比如 TS3.7.5 引入了可选链(Optional chaining)与空值合并(Nullish-Coalescing)。而当 TS 引入装饰器时(大约在 15 年左右),JS 中的装饰器依然处于 stage-1 阶段。其原因是 TS 团队与 Angular 团队 PY 成功了,Ng 团队不再维护 AtScript,而 TS 引入了注解语法(Annotation)及相关特性。
但是并不需要担心,即使装饰器永远到达不了 stage-3/4 阶段,它也不会消失的。有相当多的框架都是装饰器的重度用户,如Angular、NestJS、MidwayJS等。对于装饰器的实现与编译结果会始终保留,就像JSX一样。如果你对它的历史与发展方向有兴趣,可以读一读 是否应该在 production 里使用 typescript 的 decorator?(贺师俊贺老的回答)
和类的私有成员、静态成员提案一样,目前使用最广泛的还是 TS 中的装饰器,但是二者的语义完全不同,因此原生装饰器的提案不太可能会影响 TypeScript 到 JavaScript 的编译结果。
Iterator Helpers (stage 2)
proposal-iterator-helpers提案为ES中的Iterator使用与消费引入了一批新的接口,虽然实际上,如 Lodash 与 Itertools(思路来自于Python3中的 itertools)这样的工具库已经提供了绝大部分能力,如 filter、filterMap 等。其他语言如 Rust、C# 中也内置了非常强大的Iterator Helpers,见Prior Art。
示例:
function* naturals() {
let i = 0;
while (true) {
yield i;
i += 1;
}
}
const evens = naturals()
.filter((n) => n % 2 === 0);
for (const even of evens) {
console.log(even, ‘is an even number’);
}
虽然目前很少会直接和 Generator、Iterator 打交道了,但这些毕竟是语言底部的东西,了解其基本使用与运行机制还是有好处的。
throw Expressions (stage 2)
proposal-throw-expressions这一提案主要提供了 const x = throw new Error()
这一语法,但这并不是 throw
语法的替代品,更像是 **面向表达式(Expression-Oriented) ** 能力的补齐。
function getEncoder(encoding) {
-
const encoder = encoding === “utf8” ? new UTF8Encoder()
-
encoding === “utf16le” ? new UTF16Encoder(false)
-
encoding === “utf16be” ? new UTF16Encoder(true)
-
throw new Error(“Unsupported encoding”);
}
Upsert(Map.prototype.emplace) (stage 2)
proposal-upsert这一提案为 Map 引入了 emplace 方法,在当前 Map 上的key已存在时,执行更新操作,否则执行创建操作。确实是很甜的语法糖,感觉底层框架、工具库用 Map 多一些。
Observable (stage 1)
proposal-observable这一提案,其实懂的同学看到 Observable 这个词已经懂这个提案是干啥的了,它引入了 RxJS 中的Observable、Observer(同样是next/error/complete/start)、Subscriber(next/error/complete)等概念,当然还有 Operators(但目前只是部分),同样支持高阶Observable,以及在被订阅时才会开始推送数据(Lazy-Data-Emitting)。
function listen(element, eventName) {
return new Observable(observer => {
// Create an event handler which sends data to the sink
let handler = event => observer.next(event);
// Attach the event handler
element.addEventListener(eventName, handler, true);
// Return a cleanup function which will cancel the event stream
return () => {
// Detach the event handler from the element
element.removeEventListener(eventName, handler, true);
};
});
}
估计是因为还在 stage1 的关系,目前支持的操作符只有of、from这种最基础的,但按照这个趋势下去RxJS中的大部分操作符都会被吸收过来。个人感觉需要非常久的时间才能看到未来结果,因为 RxJS 拥有的海量操作符可不是说着玩的,如果全都要吸收过来可能会吃力不讨好的。同时,RxJS的学习成本还是有的,我不认为大家会因为它被吸收到JS语言原生就会纷纷开始学习相关概念。
Do Expression (stage 1)
proposal-do-expressions这个提案和 throw
Expressions 一样,都是面向表达式(Expression-Oriented)的语法,函数式编程的重要特性之一。
看看示例代码:
let x = do {
let tmp = f();
tmp * tmp + 1
};
let y = do {
if (foo()) { f() }
else if (bar()) { g() }
else { h() }
};
对于像笔者一样没接触过函数式编程的同学,这种语法可能确实很新奇有趣,但提案中还存在着一些注意点:
-
在
do {}
中不能仅有声明语句,或者是缺少 else 的if,以及循环。 -
空白的
do {}
语句效果等同于void 0
。 -
await
/yield
标识继承自上下文
对于异步版本的do expression
,存在一个尚未进入的提案proposal-async-do-expressions,旨在允许使用async do {}
的语法,如:
// at the top level of a script
async do {
await readFile(‘in.txt’);
let query = await ask(‘???’);
// etc
}
Pipeline Operator (stage 1)
目前star最多的提案,似乎没有之一?
proposal-pipeline-operator提案引入了新的操作符|>
,目前对于具体实现细节存在两个不同的竞争提案。这一语法糖的主要目的是大大提升函数调用的可读性,如 doubleNumber(number)
会变为 number |> doubleNumber
的形式,对于链式的连续函数调用更是有奇效,如:
function doubleSay (str) {
return str + ", " + str;
}
function capitalize (str) {
return str[0].toUpperCase() + str.substring(1);
}
function exclaim (str) {
return str + ‘!’;
}
在管道操作符下,变为如下形式:
let result = exclaim(capitalize(doubleSay(“hello”)));
result //=> “Hello, hello!”
let result = “hello”
|> doubleSay
|> capitalize
|> exclaim;
result //=> “Hello, hello!”
确实大大提高了不少可读性对吧?你可能会想,上面都是单个入参,那多个呢,如下图示例:
function double (x) { return x + x; }
function add (x, y) { return x + y; }
function boundScore (min, max, score) {
return Math.max(min, Math.min(max, score));
}
let person = { score: 25 };
let newScore = person.score
|> double
|> (_ => add(7, _))
|> (_ => boundScore(0, 100, _));
newScore //=> 57
等同于
let newScore = boundScore( 0, 100, add(7, double(person.score)) )
_只是形参名称,你可以使用任意的形参名称。
Partial Application Syntax(stage 1)
proposal-partial-application这一提案引入了新的柯里化方式,即原本我们使用 bind 方法来预先固定一个函数的部分参数,得到一个高阶函数:
function add(x, y) { return x + y; }
const addOne = add.bind(null, 1);
addOne(2); // 3
const addTen = x => add(x, 10);
addTen(2); // 12
使用Partial Application Syntax,写法会是这样的:
const addOne = add(1, ?);
addOne(2); // 3
const addTen = add(?, 10);
addTen(2); // 12
我们上一个列举的提案proposal-pipeline-operator,其实可以在 Partial Application Syntax 的帮助下变得更加便捷,尤其是在多参数情况下:
let person = { score: 25 };
let newScore = person.score
|> double
|> add(7, ?)
|> boundScore(0, 100, ?);
总结
-
框架原理真的深入某一部分具体的代码和实现方式时,要多注意到细节,不要只能写出一个框架。
-
算法方面很薄弱的,最好多刷一刷,不然影响你的工资和成功率😯
-
在投递简历之前,最好通过各种渠道找到公司内部的人,先提前了解业务,也可以帮助后期优秀 offer 的决策。
-
要勇于说不,对于某些 offer 待遇不满意、业务不喜欢,应该相信自己,不要因为当下没有更好的 offer 而投降,一份工作短则一年长则 N 年,为了幸福生活要慎重选择!!!
喜欢这篇文章文章的小伙伴们点赞+转发支持,你们的支持是我最大的动力!
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
需要这份系统化的资料的朋友,可以添加V获取:vip1024c (备注前端)
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
add(7, ?)
|> boundScore(0, 100, ?);
总结
-
框架原理真的深入某一部分具体的代码和实现方式时,要多注意到细节,不要只能写出一个框架。
-
算法方面很薄弱的,最好多刷一刷,不然影响你的工资和成功率😯
-
在投递简历之前,最好通过各种渠道找到公司内部的人,先提前了解业务,也可以帮助后期优秀 offer 的决策。
-
要勇于说不,对于某些 offer 待遇不满意、业务不喜欢,应该相信自己,不要因为当下没有更好的 offer 而投降,一份工作短则一年长则 N 年,为了幸福生活要慎重选择!!!
喜欢这篇文章文章的小伙伴们点赞+转发支持,你们的支持是我最大的动力!
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
需要这份系统化的资料的朋友,可以添加V获取:vip1024c (备注前端)
[外链图片转存中…(img-4JvE5P3k-1713466369154)]
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!