Skip to content

fix: depend on remendConfig content instead of its identity - #30

Merged
eszlamczyk merged 2 commits into
software-mansion-labs:mainfrom
Xuepoo:fix/remendConfig-effect-rerun
Aug 20, 2026
Merged

eszlamczyk merged 2 commits into
software-mansion-labs:mainfrom
Xuepoo:fix/remendConfig-effect-rerun

Conversation

@Xuepoo

@Xuepoo Xuepoo commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

Summary

Fixes #29 — useStreamdownMarkdown now depends on the content of remendConfig rather than its object identity, so an inline config literal (the documented usage) no longer re-runs the effect — and reschedules the whole-document worklet job — on every render.

Changes

  • src/hooks/useStreamdownMarkdown.ts: extract remendConfigKey = JSON.stringify(options?.remendConfig) and depend on it. Idle re-renders with an unchanged config stop rescheduling; a config whose content actually changed still re-runs. The effect intentionally reads the live options?.remendConfig (with a comment explaining the deliberate exhaustive-deps deviation).
  • src/__tests__/useStreamdownMarkdown.test.tsx: regression test rendering the hook with an inline config literal, asserting idle re-renders do not reschedule and a markdown change does. Fails on the old code (3 worklet calls after 2 idle re-renders, expected 1) and passes with the fix.
  • package.json: add react-test-renderer + @types/react-test-renderer devDependencies (the only test in the repo was it.todo).

Verification

  • jest: new test passes (1/1).
  • tsc --noEmit: clean.
  • eslint: clean on both changed files.
  • Real-React check outside the repo (rendering the actual hook + StreamdownText sources with react-dom, worklet layer stubbed): inline config scheduled 4 jobs across 3 idle re-renders before the fix, 1 after; stable config was 1 in both.

useStreamdownMarkdown depended on options?.remendConfig by object
identity, and StreamdownText forwards the caller's remendConfig into a
fresh options literal every render. A consumer passing the documented
prop inline (remendConfig={{ katex: true }}) therefore re-ran the effect
on every commit: each run called setIsStreaming(true), bumped
versionRef, and scheduled another whole-document remend worklet job.
The version guard discarded stale results, so nothing rendered wrong —
the cost was unbounded re-scheduling, defeating the library's headline
feature of keeping the JS thread free.

Depend on a serialization of the config instead. An unchanged config now
produces a stable key, so idle re-renders stop rescheduling; a config
whose content actually changes still re-runs.

Regression test: renders the hook with an inline config literal, asserts
idle re-renders do not reschedule and a markdown change does. Fails on
the old dependency (3 calls instead of 1).
@Xuepoo
Xuepoo force-pushed the fix/remendConfig-effect-rerun branch from 25b46db to 1f57059 Compare August 7, 2026 11:54

@eszlamczyk eszlamczyk left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @Xuepoo The changes look sound, and the test is great inclusion. Everything LGTM, we will soonish release this along side some deps bump (like for example enriched-markdown bump to 1.0.0 for new features)

@eszlamczyk
eszlamczyk merged commit 5817c2f into software-mansion-labs:main Aug 20, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

useStreamdownMarkdown re-runs the worklet job on every render when remendConfig is passed inline

2 participants