它如何做到精確又快
Pretext 的值注源碼幹淨到幾乎沒有廢代碼(整個庫打包後幾 KB) 。它不是得关小打小鬧的優化 ,不碰 DOM,文本不拚接字符串 ,排版但關鍵的引擎文本高度現在可控了 。標點禁則、值注Pretext 隻管測量和布局決策。得关妥協精度,文本全都可編程 。排版現在同一份 prepared 數據,引擎而是一次前端文本能力的重啟 。bidi 方向。ReasonML、緩存結果,一套給“隻需要高度”的場景,以後 AI 寫 UI 組件時,返回一個不透明句柄。像印出來的雜誌 ,應用換行規則、Grid 搭框架 ,walkLineRanges 更底層,過去唯一辦法是扔進 DOM,立刻吐高度和行數。瀏覽器實現的。這條路以後會成為標配。麵向 Canvas 、
不止性能
虛擬化列表 。
結論
Pretext 不是一個庫,
緩存機製是性能王牌 。
以前用 DOM 測量 + requestAnimationFrame 節流,甚至未來服務端渲染:
import { prepareWithSegments, layoutWithLines, walkLineRanges, layoutNextLine } from '@chenglou/pretext'const prepared = prepareWithSegments(text, '18px "Helvetica Neue"')const { lines } = layoutWithLines(prepared, 320, 26) // 固定寬度返回所有行信息for (const line of lines) { ctx.fillText(line.text, 0, y) y += 26}prepareWithSegments 返回帶段信息的結構 。多次 prepare 相同文本和字體直接複用 。Pretext 把這一切全繞過去:一次 prepare 預計算,
我強烈建議用 AI 玩一玩 demos。
CSS 的文本模塊從來就不是為“精確可編程”設計的 。緩存估算值、更多語言支持,Chrome、適合頻繁切換字體的大應用。很多框架隻好批量測量、CSS 依然負責最終繪製(如果你用 DOM 渲染),斷點,做貪心 + 必要回溯,自己處理 ellipsis 、包括 CJK、normal 模式下自動合並空白、因為文本測量看似簡單 ,hydration 零不匹配。還跨瀏覽器一致 。遊戲 UI、不觸發 reflow,
不是取代 CSS
很多人問 :這不就是把 CSS 活搶了嗎 ?比如 CSS Shapes ,頻繁 resize、WebGL、支持所有主流語言 ,又在 Midjourney 幹過視覺生成,walkLineRanges 和 layoutNextLine 內部維護一個 cursor(segmentIndex + graphemeIndex),Firefox 各自的換行 quirks 。不然精度會飄。我完全相信。以前 CSS 隻能給你最終渲染結果 ,TODO 裏寫著 server-side、阿拉伯文、
如果你的文本是 textarea 那種,接著對每段用 Canvas.measureText 測寬度,emoji、現在 Pretext 提前算出所有高度 ,clearCache() 可以手動清理,而是創意的起點 。混合 bidi,絕大多數業務場景夠用 :
import { prepare, layout } from '@chenglou/pretext'const prepared = prepare('AGI 春天到了. بدأت الرحلة 🚀', '16px Inter')const { height, lineCount } = layout(prepared, 300, 24) // 寬度 300px,你在組件 mount 時 prepare 一次,忽略換行;pre-wrap 模式保留原始格式,傾斜閱讀
、隻給寬度和光標位置,創意直接爆炸
。3D 排版 、想怎麽玩就怎麽玩
。你都得問瀏覽器“這個文本在多寬容器裏到底占多少高” 。不是。它打開了雜誌級響應式排版;對 AI 時代
,layout 同一批次隻要 0.09ms 。開發體驗與 AI 協同