一周热榜

Hi HN， 过去几年，我一直在使用多个前端技术栈（React、Vue、Angular 等），并且一直遇到一个反复出现的烦恼： 核心 UI 组件，比如下拉选择框和提示通知，每次框架变更时都要重写。 即使行为和用户体验基本相同，实现方式也与框架紧密耦合，这使得长期存在的 UI 逻辑出乎意料地脆弱。 因此，我决定尝试一种不同的方法：将 UI 原语构建为原生 Web Components，然后选择性地为框架进行封装，而不是重新实现它们。 因此，我构建了两个组件： SeoSelect — 面向生产环境的下拉选择框组件 虚拟滚动，适用于大型数据集 多语言模糊搜索（包括韩语、日语和中文输入模式） 默认支持键盘和屏幕阅读器的无障碍访问 零运行时依赖 SeoToast — 轻量级、与框架无关的提示通知组件 多种位置和动画效果 重复消息分组 SSR（服务器端渲染）安全行为 ~10KB gzipped 这两个组件首先被实现为纯 Web Components，仅在需要提升开发者体验时才添加框架封装。 我并不是想取代框架——这更多的是关于测试 UI 原语是否可以在框架生命周期之外存在，同时仍然适用于实际应用。 我非常感谢那些有以下经验的人的反馈： 在生产环境中使用过 Web Components 构建过跨框架共享的设计系统 遇到过这种方法的局限性或棘手问题 链接： https://www.npmjs.com/package/seo-select https://www.npmjs.com/package/seo-toast 很乐意回答问题或讨论权衡取舍。 谢谢！

我用 Notion 写日记好几年了，但我发现切换到它的 DSL（领域特定语言）的认知成本对我来说不划算。Notion 基于块构建，比如建立在块之上的数据库。即使我将笔记导出为 Markdown 格式，它仍然反映了 Notion 的内部数据结构，而不是给我一些干净且可移植的东西。 例如，内联数据库最终会变成一个表格，其中包含指向文档其他部分的 href 链接——很好，但当我想要可以实际使用的纯文本时，它就不是很有用了。 与此同时，我一直在进行大量的提示，而 Markdown 更适合我的工作流程。它不是一个日记工具，但它简单且被广泛支持——GitHub、VSCode 等，并且它消除了使用专用笔记应用程序带来的许多上下文切换。 我可能会怀念的是内联数据库和其他丰富的内容，但我已经学会了停止使用它们。但是，我已经将我的日记工作流程优化到很多我的提示技巧。我使用常规表格并更刻意地拆分文档。如果需要，我会在日记之间引用它们，有点像为工作流程的每个部分设置了专门的提示。 我还在日记中使用许多提示技巧——我使用常规表格（更扁平且未链接）而不是创建内联数据库，并开始更多地拆分文档，并在我的日记中引用它们。 我有时也会在顶部放置 YAML 前置元数据和描述。这样，如果我想要运行一个 LLM 来处理我的日记——用于总结年份或构建语义搜索——我已经准备好了。（甚至可能将其变成 https://gpt.qalam.dev 的一个功能） 我意识到工具的重要性不如我组织思想的方式。

我开始在 X 上给“接触草地”的人发放徽章，纯粹是为了好玩，而且大多数人都很喜欢！所以，我决定为此创建一个网站。<p>流程很简单： - 输入 X 用户名 / 链接 - 获取头像并选择徽章 - 生成一个徽章页面，可以分享，带有漂亮的 OG 图片<p>该网站部署在 Vercel 上，使用 R2 和浏览器渲染 OG 图片，并用于数据存储。