目前 Vitest 官方并没有向 Vite 那样维护了一个公司列表。Vitest 团队暂时也没有这样的列表。
有一些三方列表,以下为从 https://stackshare.io/vitest 提取的部分公司,多为欧洲公司
目前 Vitest 官方并没有向 Vite 那样维护了一个公司列表。Vitest 团队暂时也没有这样的列表。
有一些三方列表,以下为从 https://stackshare.io/vitest 提取的部分公司,多为欧洲公司
// example.js -- 示例 | |
// verify.js -- 跑一下 type challenge | |
// play/tsconfig.json | |
// play/utils.d.ts | |
// 需要安装 typescript | |
// $ node example | |
// { exitCode: 0, stdout: '', stderr: '', error: undefined } | |
// { | |
// exitCode: 2, |
Array (a collection of elements accessed by integer indices) is probably one of the most commonly used data structures by programmers, and slice is one of the most commonly used array methods. (This statistic also indicates that splice seems to be used more than we thought.)
Method | Search Results |
---|---|
push | more than 2913780 results from 110260 repositories |
forEach | 1303701 results from 94472 repositories |
slice | 743508 results from 76749 repositories |
indexOf | 621518 re |
const HandlerID = Symbol() | |
export function defineEvent(obj, name) { | |
const handlers = new Set() | |
const fn = function () { | |
for (const handler of handlers) { | |
try { | |
handler() | |
} catch (e) { | |
Promise.reject(e) |
NOTE: This proposal was mainly written 2 years ago, many examples may already outdated, but the whole idea should still apply.
I have a dream, that the new JS APIs could be developed like good open source libraries, have reference implementation maintained by champions and volunteers in the whole lifecycle from stage 1 to stage 4, clearly marked as "experimental feature" not "polyfill", follow semver, and available in all platforms (all engines, browsers and node.js) automatically, accept issues and PRs in official github repo, can have branches to test new ideas, allow forks and healthy competition...
Rough exmaple:
switch (x) {
case Number ?n -> console.log(n)
case String ?s -> console.log(s)
case Point {?x, ?y} -> console.log(x, y)
case OtherPattern ?binding -> console.log(binding)
}
// kotlin channel: https://kotlinlang.org/docs/reference/coroutines/channels.html | |
// golang channel | |
class Channel { | |
constructor() { | |
this._s = null | |
this._r = null | |
} | |
send(v) { | |
if (this._r) { |
// 根据 https://www.zhihu.com/question/391388615/answer/1193135808 中的代码重构, | |
// 以对应所 fork 的工业聚版本 | |
// 和工业聚版本的主要区别: | |
// - OO 范式而不是 FP 范式(其实像知乎原版那样不用 class 写成 makeTree 函数也是可以的,这里 | |
// 主要是响应工业聚的号召,更「class」一些。但因为是 JS 而不是 TS 写的,就没有再加额外的 | |
// interface 或 abstract class 了。) | |
// - Tree 没有弄成 immutable 的。要弄成 immutable 也不是不行,但 OO 范式下处理这类数据结构, | |
// 通常不会特意弄成 immutable 的,而是在必要的时候提供 clone 方法。 | |
// - 简易起见,没有对 root 节点做额外处理(实际上似乎也不应该做原本格式的数据必然只有一个 |
译名方法:
术语