developer.chrome.google.cn![[捂脸]](http://lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_28.8981538.png)
#sora
Levix
前端打杂
|
Null
获得徽章 16
- Chrome 122 更新介绍
1. 存储桶 API（Storage Buckets API） ：提供了更多细粒度的控制，以更好地管理持久化存储。通过创建多个存储桶，浏览器可以独立地选择删除每个存储桶，让您指定删除优先级以确保不删除最重要的数据。每个存储桶都可以包含诸如 IndexedDB 和 CacheStorage 等既定存储 API 的数据。
2. DevTools 性能面板改进 ：Chrome 122 的 DevTools 在性能面板中引入了改进：
- 在时间线顶部加入了面包屑功能，允许设置面包屑并在它们之间跳转。
- 在主跟踪中显示启动器与后续事件之间的连接箭头。
3. 异步剪贴板 API 未经消毒的选择（Async Clipboard API unsanitized option） ：新增了一个选项，允许应用和网站通过 read() 方法获得未消毒的 HTML 。如果不包括该属性，从剪贴板读取 HTML 时，内容会进行消毒处理。
4. CSS 和 WebGL 的新特性 ：
- 包含不支持特性的容器查询永远不匹配。
- dataTransfer.clearData() 不会影响 File 对象，只删除文本类型对象。
- WebGL 的 drawingBufferStorage 允许绘制超过 8 位精度的内容，避免将渲染内容转换到默认绘图缓冲区像素格式时的额外复制。
#Chrome #新特性展开46 - 《如何避免 repo-jacking（仓库劫持）》
文章讨论了针对开源软件可能的供应链攻击：repo-jacking（仓库劫持），解释了它是什么、存在什么风险，以及如何保护自己不受其影响。
以下是文章的核心内容：
1. Repo-jacking 是一种供应链攻击，其影响可能延伸到大量使用开源软件的用户和系统。
2. 如果你从包管理器（如 npm 或 PyPI）获取所有软件依赖，你不会直接受到 repo-jacking 的影响。但如果你直接从 GitHub 获取依赖项，就需要更加小心。
3. 防御 repo-jacking 的简单方法是锁定特定的提交ID（commit ID）。
4. GitHub 采用了一种名为“碑石算法”（tombstoning algorithm）的机制，通过永久淘汰特定的用户名和仓库名组合来减少 repo-jacking 的风险。故而，repo-jacking 只针对低于特定使用门槛的仓库构成风险。
5. GitHub上的自动重定向功能可能会增加 repo-jacking 的风险，因为重定向可能让人们不易察觉依赖已经被改名。
6. 包管理器创建了额外的保护层来对抗 repo-jacking，因为你需要获得维护者账号的访问权限来用恶意软件替换包管理器上的包。
7. 如果你或你的项目构建系统直接从 GitHub 下载软件，你需要特别小心，可以通过锁定特定的提交ID来避免 repo-jacking。
8. 作者还讲述了如何使用 GitHub API 来检查仓库是否已被重命名或替换，作为检测 repo-jacking 的一种方法。
9. 文章也提到了供应链安全中值得关注的新进展，如使用 OpenID Connect (OIDC) 安全上传构建工件到包管理器，并介绍了跨机构合作开发的软件供应链级别框架（SLSA）。
文章的结论是，尽管 GitHub 使用了碑石算法来降低因更改用户名可能导致的 repo-jacking 风险，但如果你的项目有直接从 GitHub 下载的依赖，最简单的安全保护措施是锁定特定的提交ID。
#Github #安全展开35 - Google 宣布专为中国开发者服务的 Chrome for Developers 现已在 .cn 域名上线，让在中国的开发者更容易地访问相关内容。所有内容都在 .cn 域名下进行镜像，并提供所有支持的语言版本。
在这里，可以找到针对中国的 Chrome 开发者资源：
developer.chrome.google.cn 。通过这个资源，开发者可以了解最新的 Chrome 稳定版和测试版的发布信息，发现 Chrome DevTools、浏览器扩展等丰富的文档资料。
此外，Google 还同时在中国推出了 web.dev 网站，以满足本地开发者对前沿技术资源的需求，访问地址为web.developers.google.cn。
这一举措是在 2023 年上海的 I/O Connect 事件中与中国开发者亲密互动后做出的决策。Google 希望这能够成为更好地支持中国开发者的一个良好开始。展开2138 - 《JavaScript Sets 即将引入并集、交集、差集等功能》
目前，JavaScript 的 Set 对象已可执行基本操作，如创建、添加、删除和检测成员。但对于进行集合运算，比如合并（union）、交集（intersection）和差集（difference）操作，ES2015 规范的 Set 对象还不支持。TC39 委员会（负责 ECMAScript 规范的开发）已经在这方面取得了进展，一些浏览器实现了相关功能。
以下是新增加的几个 Set 方法及其意义：
1. union ：创建两个集合所有元素的合集。
2. intersection ：创建两个集合中共有元素的交集。
3. difference ：创建在第一个集合中但不在第二个集合中的元素集。
4. symmetricDifference ：创建仅存在于两个集合之一中的元素集。
5. isSubsetOf ：判断一个集合是否为另一个集合的子集。
6. isSupersetOf ：判断一个集合是否为另一个集合的超集。
7. isDisjointFrom ：判断两个集合是否无交集。
目前，Safari 17 和 Chrome 122 已经支持这些新方法，Edge 也即将支持，Firefox Nightly 在标记后也支持了。
对于旧 JavaScript 引擎，可以使用 polyfills 来升级到符合规范的这些新功能。例如，core-js 或 es-shims 项目提供的独立功能包。
#前端 #新特性 #TC39展开14 - Vite 5.1 版本的发布带来了许多新特性、性能提升和改进。主要更新内容包括：
1. Vite Runtime API：Vite 5.1 引入了一个实验性的新功能 Vite 运行时 API ，它允许通过 Vite 插件先处理任意代码后再执行。它与 server.ssrLoadModule 不同，因为运行时实现与服务器解耦。这使得库和框架作者能实现他们自己的通信层，用于服务器和运行时之间的通信。此新 API 旨在替代 Vite 当前的 SSR 原语，一旦稳定下来。
2. 性能改进：Vite 在每个发布版本中都在提升性能。对于加载 10K 模块的测试显示 Vite 5.1 在性能上又一次提升。
3. 支持`.css?url`：现在稳定并正确地支持将 CSS 文件作为 URL 导入。
4. build.assetsInlineLimit 支持回调：用户现在可以提供返回布尔值的回调，以选择性地调整特定资产是否内联。如果返回 undefined ，则应用默认逻辑。
5. 改进循环引入下的 HMR：Vite 5.0 中循环引入的接受模块总是触发整页重新加载，即使在客户端可以正常处理。现在这种局限性放宽了，HMR 可以应用而无需整页重载。
6. 支持`ssr.external: true`：这是一个新选项，可以用来外部化所有 SSR 包，包括链接包在内。
7. 预览服务器暴露 close 方法：预览服务器现在暴露了一个 close 方法，用来正确地关闭服务器，包括所有打开的套接字连接。
8. 在线程中运行 CSS 预处理器：Vite 现在支持在线程内运行 CSS 预处理器，可以通过`css.preprocessorMaxWorkers: true`启用。
9. 新选项用于改善服务器冷启动：可以设置`optimizeDeps.holdUntilCrawlEnd: false`来采用新的依赖优化策略，可能对大型项目有所帮助。
10. 更快的解析速度与缓存检查：`fs.cachedChecks`优化现在默认启用。在 Windows 上，`tryFsResolve`的速度提升了大约 14 倍。
11. 内部性能改进：开发服务器实现了数个性能增强。展开评论3 - Interaction to Next Paint（INP）将在 3 月 12 日成为核心 Web 指标（Core Web Vital）
文章内容：
- INP 的引入：INP 将在 3 月 12 日正式成为核心 Web 指标，并将取代首次输入延迟（FID）。Web Vitals 计划提供关键指标以帮助开发者衡量Web用户体验的重要方面，随着时间的发展，FID 不足以完全表达 Web 互动性，Chrome 团队于 2022 年 5 月引入了实验性指标 INP。去年 INP 成为一项待决指标，并宣布将在 2024 年 3 月晋升为稳定状态。
- 如何准备：首先，需要确保网站的 INP 在所有页面加载的第 75 百分位数中表现良好。可以使用 PageSpeed Insights（其中包含来自 Chrome 用户体验报告（CrUX）的数据）来查看网站在 INP 上的表现。如果已经与真实用户监测（RUM）提供商合作，考虑询问他们对 INP 的支持。如果网站的 INP 需要改进，提供了一系列资源和引导来优化 INP。
- INP 转变影响：FID 将不再是核心 Web 指标，并将官方弃用，并从程序中移除。在 Google 的各种工具中，FID 的信息将被移除并替换为 INP 的相关信息。PageSpeed Insights 和 CrUX 将提供 6 个月的弃用期，给开发者更新代码的机会。
- 未来的道路：过去两年来，INP 被纳入核心 Web 指标的计划已经仔细规划，这一步将推动 Web 互动性的提升。随着 INP 将成为核心 Web 指标的日期临近，开发者应该利用这个时间来理解和优化 INP 性能。
#前端 #性能 #INPweb.dev 展开111 - 文章主要探讨了在使用 React 进行服务端渲染时可能遇到的“重渲染”问题，特别是在生产环境下可能会出现的一些意料之外的行为。作者通过分享个人经历，揭示了对 React 服务端渲染过程中的一些误解，并提供了避免这些问题的解决方案。
关键点列表：
1. 💡 开发环境下一切正常，但生产环境中博客底部出现了意外行为，暗示了 React 组件在错误的位置渲染的问题。
2. 🌐 作者发现自己对 React 在服务端渲染环境中的工作方式有根本性的误解，这是许多 React 开发者共有的误区。
3. 🚀 文章举例说明了可能导致渲染问题的代码，指出了许多开发者可能忽视的问题点。
4. 📚 介绍了 Gatsby 和 Next.js 等框架与传统客户端 React 应用的区别，以及服务端渲染（SSR）和客户端渲染的概念。
5. 🎯 提到了静态站点生成（SSG）的概念，解释了它是如何在构建时生成 HTML 文档，以加快 React 应用的加载速度。
6. 🔄 探讨了“水合”（hydration）过程，即客户端 JavaScript 如何构建页面并与服务端渲染的 HTML 文档进行比较。
7. ❗️ 强调了在服务端渲染和客户端“水合”过程中保持 DOM 结构一致性的重要性，以避免渲染不匹配的问题。
8. 🛠 提供了一种解决方案，通过使用 `useEffect` 钩子和 `hasMounted` 状态来管理动态内容的渲染，确保在客户端渲染完成后正确显示内容。
9. 📈 分享了“两阶段渲染”（two-pass rendering）的概念，以及如何通过客户端状态管理来处理动态数据。
#前端 #React #服务端组件www.joshwcomeau.com
中文版：sorrycc.com 展开评论5
![[看]](http://lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_97.39cdc9f.png)