feat(input): heading blocks (H1-H6) on the block pipeline by wildseansy · Pull Request #497 · software-mansion/react-native-enriched-markdown

wildseansy · 2026-07-03T16:21:33Z

What

Second PR in the block-editing series: the first concrete block type — headings H1–H6 — plugging into the pipeline foundation merged in #460. Follows the extension pattern exactly: one entry in each parser's central block map + one registered handler, no orchestrator changes.

How

Both platforms

HeadingBlockHandler / ENRMHeadingBlockHandler — owns heading paragraph styling (per-level font size/weight/color) and the markdown line prefix ("# "…"###### "). One handler instance serves all six levels, registered under each HEADING_n key.
BlockType.HEADING_1..6 / ENRMInputBlockTypeHeading1..6; parsers map heading nodes centrally — Android nodeTypeToBlockType reads the AST node's level attribute, iOS kSupportedBlocks + resolveBlockLevel reads MD_BLOCK_H_DETAIL.level.
Per-level h1–h6 style props on the input, mirroring the readonly renderer's markdownStyle so heading sizing is configured consistently across read and edit views (normalized with complete defaults on the JS side).
BlockStore gains normalizeToLineBounds (idempotent): after an edit is adjusted, ranges re-snap to whole-line bounds — re-absorbs characters typed at a block's edges, clips a newline-split heading to its first line, and drops blocks orphaned by line joins.

Testing

Example app builds green on both platforms (iOS sim via xcodebuild, Android compileDebugKotlin), ktlint/clang-format clean.
Manual: type # prefixes, import markdown with H1–H6, edit at heading boundaries, serialize round-trip.

🤖 Generated with Claude Code

First concrete block type on the software-mansion#460 foundation. Adds HeadingBlockHandler / ENRMHeadingBlockHandler (paragraph styling + markdown line prefix), maps md4c/AST heading nodes in each parser's central block map, exposes per-level h1-h6 style props mirroring the readonly renderer's markdownStyle, and re-normalizes block ranges to whole-line bounds after edits. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

hryhoriiK97

Paste doesn't import block ranges

Pasting markdown containing headings (e.g. # Hello) will lose the heading — the paste path only round-trips through InputParser → FormattingStore, not BlockStore. This gap becomes user-visible and should be addressed in a follow-up 🙏

hryhoriiK97 · 2026-07-04T09:38:59Z

+      text?.let { blockStore.normalizeToLineBounds(it) }
      applyPendingStyles(editStart, insertedLength)
-      applyFormatting()
+      applyFormattingScopedToEdit(editStart, insertedLength)


Android scopes block re-application to the edited line(s) here via applyFormattingScopedToEdit, but iOS re-applies across the full document on every edit (see EnrichedMarkdownTextInput.mm:668). This should be aligned for performance parity.

Done in fe13ff9. handleTextChanged now calls a scoped variant that re-applies attributes only on the line(s) touched by the edit, mirroring Android's applyFormattingScopedToEdit. One iOS-specific wrinkle: scoping only applyBlockRanges: would have broken headings — the inline pass stamps baseFont across its whole range, so any heading outside the scope would lose its size. Both passes therefore share the same line-expanded scope, and layout invalidation shrinks to it as well (previously it invalidated + ensured layout for the full document every keystroke, which was the bigger cost). Full-range re-apply is kept for import, style changes, and commands — same split as Android.

hryhoriiK97 · 2026-07-04T09:38:59Z

+  return [self isValidHeadingLevel:level] ? _headingColors[level] : nil;
+}
+
+- (UIFont *)headingFontForLevel:(NSInteger)level


This creates a new UIFont on every call, bypassing the _fontCache already used by fontForTraits: (line 131 in this file). Could we cache heading fonts keyed by level in the same dictionary to avoid repeated allocations?

Done in fe13ff9. Used a per-level _headingFontCache[7] array alongside _fontCache rather than sharing the dictionary — level ints would collide with the traits-bitmask key space. Invalidated together with _fontCache on base-font change, and per level when that level's size/weight config changes.

hryhoriiK97 · 2026-07-04T09:38:59Z


+// Headings h1..h6 share an identical struct shape (fontSize / fontWeight /
+// color). Read each level into the formatter style's per-level heading config.
+#define ENRM_APPLY_HEADING_PROPS(levelNumber, headingKey)                                                              \


The rest of this file (and the input codebase) uses static inline functions for reusable logic (e.g. ENRMAutocapitalizationTypeFromString at line 9, applyInputStyleProps at line 22). A static helper function or a loop over a {level, accessor} mapping would be more consistent while avoiding the readability/debugging drawbacks of multi-line macros.

Done in fe13ff9 — replaced with a static template helper applyHeadingLevelProps (template because the codegen h1..h6 structs are distinct types with an identical shape), matching the existing applyInputStyleProps pattern.

hryhoriiK97 · 2026-07-04T09:47:03Z

+    // A handler instance maps to one ENRMInputBlockType, but a single
+    // ENRMHeadingBlockHandler serves all six heading levels (it dispatches on
+    // blockRange.level), so the same instance is registered under all six
+    // heading keys.


This comment narrates what the loop below already shows (same instance registered 6 times). The code is self-explanatory — consider removing.

Removed in fe13ff9.

hryhoriiK97 · 2026-07-04T09:47:03Z

+/// Representative block type. One instance serves all six heading levels; the
+/// formatter registers it under every heading key explicitly rather than relying
+/// on this single value, and applyAttributesToParagraphStyle: dispatches on
+/// blockRange.level.


This repeats the class-level doc from the .h and explains caller internals that don't belong on a simple property accessor. Consider removing.

Removed in fe13ff9.

hryhoriiK97 · 2026-07-04T09:47:03Z

+  }
+
+  // The font is merged onto existing inline runs by the formatter (preserving
+  // bold/italic traits), so it is set here as the target size/weight only.


Redundant with the mergeFontSize: doc comment in ENRMInputFormatter.mm which already explains this. One or the other is enough.

Removed in fe13ff9.

hryhoriiK97 · 2026-07-04T09:47:04Z

+  if (level < 1 || level > 6) {
+    return @"";
+  }
+  // `#` * level followed by a single space, e.g. "### " for an H3.


The code ([@"" stringByPaddingToLength:level withString:@"#"...]) is self-explanatory. Remove.

Removed in fe13ff9.

hryhoriiK97 · 2026-07-04T09:47:04Z

                  deletedLength:(NSUInteger)deletedLength
                 insertedLength:(NSUInteger)insertedLength;

+/// Re-normalizes every stored range back to the whole-line bounds of the line


10 lines is a lot for a method doc — it reads more like an algorithm tutorial than a contract. Consider shortening to:

/// Snaps every stored range to the line bounds of its start position. /// Absorbs edge-typed chars, clips split ranges to first line, drops /// duplicates. Call after adjustForEditAtLocation: once text is final. /// Idempotent.

Shortened to the suggested wording in fe13ff9.

hryhoriiK97 · 2026-07-04T09:47:04Z

    }
  }

+  // Block-level syntax (e.g. a heading's "# " line prefix) is structural markup,


The doubling bug is non-obvious and worth documenting, but 5 lines is heavy. Shorten to:

// Strip block markers (e.g. "# ") from plain text — same as inline delimiters. // Without this the marker survives and the serializer doubles it ("# # ").

Shortened to the suggested two lines in fe13ff9.

hryhoriiK97 · 2026-07-04T09:47:04Z

+import com.swmansion.enriched.markdown.input.model.InputFormatterStyle
+
+/**
+ * Sizes (and optionally weights/colors) a heading line in the editor per the


9 lines — could be halved:

/** * Sizes and optionally weights/colors a heading line per [InputFormatterStyle.headingStyle]. * Preserves inline bold/italic via [BOLD_ITALIC_MASK] so emphasis composes with heading weight. * Tagged [MarkdownSpan] for formatter cleanup. */

Applied the suggested doc in fe13ff9.

hryhoriiK97 · 2026-07-04T09:47:04Z

    try {
      formattingStore.adjustForEdit(editStart, deletedLength, insertedLength)
      blockStore.adjustForEdit(editStart, deletedLength, insertedLength)
+      // Blocks are line-scoped: snap ranges back to whole-line bounds so


This 3-line comment is duplicated verbatim at all 3 normalizeToLineBounds call sites (here + iOS x2). The method name + its doc comment are enough context at the call site — remove these.

Removed at all three call sites in fe13ff9.

hryhoriiK97 · 2026-07-04T09:47:04Z


  [_formattingStore adjustForEditAtLocation:editLocation deletedLength:selection.length insertedLength:text.length];
  [_blockStore adjustForEditAtLocation:editLocation deletedLength:selection.length insertedLength:text.length];
+  // Blocks are line-scoped: snap ranges back to whole-line bounds so characters


Duplicate of the comment at the other call site and on Android. The method doc covers it — remove.

Removed in fe13ff9.

hryhoriiK97 · 2026-07-04T09:47:04Z


  [_formattingStore adjustForEditAtLocation:editLocation deletedLength:deletedLength insertedLength:insertedLength];
  [_blockStore adjustForEditAtLocation:editLocation deletedLength:deletedLength insertedLength:insertedLength];
+  // Blocks are line-scoped: snap ranges back to whole-line bounds so characters


Same duplicate — remove.

Removed in fe13ff9.

…ines, cache heading fonts - iOS now re-applies inline + block attributes only on the line(s) touched by an edit (parity with Android's applyFormattingScopedToEdit). Scoping the block pass alone would break: the inline pass stamps baseFont over its range, so both passes share the same line-expanded scope. Layout invalidation shrinks to the scope as well. - Cache heading fonts per level in ENRMInputFormatterStyle, invalidated with the trait font cache on base-font change and per level on config change. - Replace ENRM_APPLY_HEADING_PROPS macro with a template helper, matching the file's existing applyInputStyleProps pattern. - Trim/remove narrating and duplicated comments flagged in review. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

wildseansy · 2026-07-04T16:41:46Z

Thanks for the review @hryhoriiK97!

Review comments addressed in fe13ff9:

iOS/Android perf parity — iOS now scopes per-keystroke re-formatting (inline + block passes, and layout invalidation) to the line(s) touched by the edit, mirroring Android's applyFormattingScopedToEdit. Both passes had to share the scope: the inline pass stamps baseFont over its range, so scoping only the block pass would have dropped heading sizes outside the edited line. Full-document re-apply remains for import, style changes, and commands.
Heading font cache — per-level cache in ENRMInputFormatterStyle, invalidated with the trait cache on base-font change and per level on config change.
Macro → helper — ENRM_APPLY_HEADING_PROPS replaced by a static template function following the applyInputStyleProps pattern.
Comment cleanup — all flagged comments removed or shortened to the suggested wording.

Paste gap — confirmed: pasteMarkdown (iOS) and the Android paste path only feed FormattingStore, so pasted # Hello loses the heading. Agreed on handling it in a follow-up PR; happy to pick that up next.

Verified: ktlint + compileDebugKotlin green, example app xcodebuild succeeds, and a simulator run importing # Big Title / **bold** / ## Subheading then typing inside a heading line confirms the scoped path re-stamps the edited line while untouched lines keep their heading/inline styling.

🤖 Generated with Claude Code

wildseansy mentioned this pull request Jul 3, 2026

feat(input): block-editing pipeline foundation #460

Merged

hryhoriiK97 reviewed Jul 4, 2026

View reviewed changes

Uh oh!

Conversation

wildseansy commented Jul 3, 2026

What

How

Testing

Uh oh!

hryhoriiK97 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wildseansy commented Jul 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

hryhoriiK97 left a comment •

edited

Loading

wildseansy commented Jul 4, 2026 •

edited

Loading