mengxi-ream

@wang_ruo28816 @MinLiBuilds @FiniYang 浏览器我现在用开源的陪读蛙 mengxi-ream/read-frog 桌面端很久之前就买了 Bob bobtranslate.com

非同期 DOM 走査を止めるには、await の後でキャンセルを確認する Read Frog を開発している MengXi です。ブラウザ拡張で大きな DOM を処理するとき、処理を分割してメインスレッドに制御を返すだけでは、ユーザーが押した「停止」を正しく扱えないことがあります。公開ソースにある実装を例に、分割処理とキャンセルの関係を整理します。 制御を返すと、前提が変わる 長い DOM 走査の途中でイベントループに制御を返すと、その間に停止操作や別のセッションの開始が起きます。停止前に有効だった処理が、再開時にも有効とは限りません。 Read Frog の src/utils/host/translate/core/translation-walker.ts の 58–59 行では、再開した直後に次の確認をしています。 await pauseIfBudgetSpent(pacer) if (!shouldContinue()) return 該当コード（固定コミット） 順序が大事です。await の前だけで有効性を調べると、停止操作がその待機中に起きた場合、古い仕事が再開してしまいます。この関数では、待機後に確認してから段落の処理へ進みます。再帰呼び出しにも同じ shouldContinue を渡すため、再開する各呼び出しで停止を確認できます。 これは実行中のネットワークリクエストを中断する仕組みそのものではありません。この確認が止めるのは、この走査から新たに進める DOM 処理です。既に開始したリクエストの中断や、戻ってきた結果の破棄は、別の責務として考える必要があります。 時間の予算を、再帰の間で共有する 同じ実装の src/utils/scheduler.ts では、一度に使う時間の予算を WorkPacer に持たせています。48–51 行を抜粋すると次のようになります。 export async function pauseIfBudgetSpent(pacer: WorkPacer): Promise<void> { if (performance.now() < pacer.deadline) return await yieldToMain() pacer.deadline = performance.now() + pacer.budgetMs } 時間予算の実装 走査は同じ pacer を子の呼び出しへ渡します。子ごとに新しい予算を作ってしまうと、小さい仕事が多数連続したときに、全体としては長時間走り続けることがあります。共有した期限を見ることで、木全体の仕事を同じ予算で区切れます。 公開コードの既定値は 12ms ですが、これは目標の予算であり、12ms ごとに必ず中断できるという保証ではありません。確認と確認の間に重い同期処理があれば、その分は長くなります。固定値だけで応答性を判断せず、実際のページで処理の粒度も確認する必要があります。 yieldToMain() は利用可能な API を調べ、scheduler.yield()、scheduler.postTask()、MessageChannel、setTimeout() の順で切り替えます。単に完了済み Promise を await することと、入力や描画へ処理機会を渡すことは区別しています。 DOM に残る印と、セッションの有効性は別 同じ walker は 71 行で、要素に付いた walk ID が現在の ID と一致するかも確認します。ただし、DOM 属性は状態のすべてを表すものではありません。ソース内のコメントには、停止時にも走査済みの属性が残るため、その属性だけでは途中の処理を停止できないことが書かれています。 このため、二つの条件を分けて読むと理解しやすくなります。 DOM の印は、この要素がどの走査に属していたかを判断する。 shouldContinue() は、再開した仕事が今も続行してよいかを判断する。 テストは「途中で止めた」を扱う 公開リポジトリの translation-walker-liveness.test.ts には、少なくとも次の三つのケースがあります。これはテストコードの内容の紹介で、この文章を書くためにテストを新たに実行したという意味ではありません。 開始時点でキャンセル済みなら、実際の段落翻訳は 0 件。 途中で shouldContinue() が false になったら、6 段落すべては処理しない。 有効なままなら、4 段落すべてを処理する。 テストコード このテストでは予算を 0 にして各入口で待機を発生させ、有効性チェックの回数で途中の停止を再現しています。実時間に依存した長い待機を入れずに、処理が再開する境界を検査できる点が参考になります。 同じ種類の処理を作るときの確認点 DOM 走査、検索結果の組み立て、一覧の段階的描画などで、仕事を分割するなら次の点を確認するとよさそうです。 制御を返した後で、セッションが今も有効かを調べているか。 再帰や複数の入口が、意図した単位で時間予算を共有しているか。 「開始前に停止」と「途中で停止」の両方をテストできるか。 DOM 処理の停止と、ネットワークリクエストの中断を混同していないか。 本記事の例は、私が開発に関わるオープンソース拡張 Read Frog の公開コードです。AI を執筆補助に用い、参照する実装とテストを固定コミットにそろえています。

I’m building Read Frog, an open-source extension for bilingual reading, YouTube subtitles and FSRS flashcards Hi everyone — I’m MengXi, one of the developers of Read Frog. The workflow is to read a page or watch a video in the language you’re learning, save useful words and sentences in context, then review them as flashcards with FSRS. It currently includes side-by-side web-page translation, bilingual subtitles on YouTube and X, selected-text AI actions, and vocabulary flashcards. The extension is open source. There is a free tier, and some AI features are on paid plans; you can also use your own supported API keys. Source: mengxi-ream/read-frog YouTube workflow: readfrog.app I’d like feedback from people who already use translation or language-learning extensions: where does switching between reading, saving vocabulary and reviewing break down for you? Happy to answer questions about the implementation and limitations. I’m posting as a developer, not as an independent reviewer.

这种插件对于我这种文盲太友好了😱 看X的英文长文无痛翻译。。 开源地址：mengxi-ream/read-frog t.co