refactor(js): harden native inserter pattern payload shape#467
Merged
Conversation
github-actions
Bot
added
the
[Type] Task
jkmassel
force-pushed
the
jkmassel/native-inserter-pattern-shape
branch
from
039d75c to
9dd9daa
Compare
1 task
jkmassel
force-pushed
the
jkmassel/android-block-picker
branch
from
88d07a8 to
932e7ed
Compare
jkmassel
force-pushed
the
jkmassel/native-inserter-pattern-shape
branch
from
9dd9daa to
b225bcf
Compare
4 tasks
jkmassel
force-pushed
the
jkmassel/native-inserter-pattern-shape
branch
from
b225bcf to
85d870d
Compare
jkmassel
force-pushed
the
jkmassel/native-inserter-pattern-shape
branch
from
85d870d to
4f01de9
Compare
Contributor
Author
|
e2e test failures will be resolved by #473 |
Pulls the inline pattern/pattern-category serialization in `NativeBlockInserterButton` into named helpers in `src/utils/blocks.js` and flips array fields (`blockTypes`, `categories`, `keywords`) from `?? null` to `?? []` so the JSON shape matches the non-nullable `List<String>` contract in the Kotlin `BlockPattern` model. Emitting `null` for those fields would throw `SerializationException` on the Android side.
Adds `schemas/block-inserter-payload.schema.json` mirroring the Kotlin `BlockInserterPayload` contract at android/Gutenberg/src/main/java/org/wordpress/gutenberg/model/BlockInserter.kt, plus `src/utils/blocks.test.js` which validates the output of `preprocessBlockTypesForNativeInserter`, `formatPatternsForNativeInserter`, and `formatPatternCategoriesForNativeInserter` against it via `ajv`. The schema is draft-07 with `additionalProperties: false` on every definition, and is co-located at the repo root so it can be consumed by cross-language tooling (`quicktype`, `kotlinx-serialization` codegen) alongside the hand-written Kotlin model. Upstream Gutenberg ships no JSON Schema for these shapes (only JSDoc typedefs on `WPEditorInserterItem` / `WPBlockType`), so the schema is hand-written and tracks the Kotlin model as the source of truth. Catches the null-vs-array drift that motivated #465, plus drift in required fields, types, and unknown-field leaks that Kotlin's `ignoreUnknownKeys = true` would otherwise silently tolerate. Adds `ajv` as a direct devDependency (was transitive).
jkmassel
force-pushed
the
jkmassel/native-inserter-pattern-shape
branch
from
4f01de9 to
436b233
Compare
oguzkocer
approved these changes
Apr 27, 2026
3 tasks
jkmassel
added a commit
that referenced
this pull request
Apr 28, 2026
* refactor(js): extract native inserter pattern formatters Pulls the inline pattern/pattern-category serialization in `NativeBlockInserterButton` into named helpers in `src/utils/blocks.js` and flips array fields (`blockTypes`, `categories`, `keywords`) from `?? null` to `?? []` so the JSON shape matches the non-nullable `List<String>` contract in the Kotlin `BlockPattern` model. Emitting `null` for those fields would throw `SerializationException` on the Android side. * test(js): validate native inserter payload against JSON Schema Adds `schemas/block-inserter-payload.schema.json` mirroring the Kotlin `BlockInserterPayload` contract at android/Gutenberg/src/main/java/org/wordpress/gutenberg/model/BlockInserter.kt, plus `src/utils/blocks.test.js` which validates the output of `preprocessBlockTypesForNativeInserter`, `formatPatternsForNativeInserter`, and `formatPatternCategoriesForNativeInserter` against it via `ajv`. The schema is draft-07 with `additionalProperties: false` on every definition, and is co-located at the repo root so it can be consumed by cross-language tooling (`quicktype`, `kotlinx-serialization` codegen) alongside the hand-written Kotlin model. Upstream Gutenberg ships no JSON Schema for these shapes (only JSDoc typedefs on `WPEditorInserterItem` / `WPBlockType`), so the schema is hand-written and tracks the Kotlin model as the source of truth. Catches the null-vs-array drift that motivated #465, plus drift in required fields, types, and unknown-field leaks that Kotlin's `ignoreUnknownKeys = true` would otherwise silently tolerate. Adds `ajv` as a direct devDependency (was transitive).
jkmassel
added a commit
that referenced
this pull request
Apr 29, 2026
#468 added `iconForeground: getBlockIconForeground(item)` to the block payload, but the schema (added in #467, in trunk) still has `additionalProperties: false` on `BlockType` with no `iconForeground` entry. Trunk doesn't emit the field so trunk CI is fine; this branch carries both pieces and AJV rejects the payload. Mirrors the existing `icon` entry: nullable string.
2 tasks
jkmassel
added a commit
that referenced
this pull request
May 12, 2026
) * fix(js): add iconForeground to block-inserter payload schema #468 added `iconForeground: getBlockIconForeground(item)` to the block payload, but the schema (added in #467, in trunk) still has `additionalProperties: false` on `BlockType` with no `iconForeground` entry. Trunk doesn't emit the field so trunk CI is fine; this branch carries both pieces and AJV rejects the payload. Mirrors the existing `icon` entry: nullable string. * test(js): read AJV dataPath alongside instancePath in shape helper Resolved AJV in node_modules is 6.12.6 (despite package.json declaring ^8.18.0 — pulled in transitively). AJV 6 surfaces the failing field as `dataPath`; AJV 7+ uses `instancePath`. The helper only read `instancePath`, so error messages came back as `/: should be array` instead of `.patterns[0].blockTypes: should be array`, and the regex matchers in the rejection tests failed to find the field name. Read both, fall back across versions.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
NativeBlockInserterButtoninto named helpers insrc/utils/blocks.js.blockTypes,categories,keywords) from?? nullto?? []to match the non-nullableList<String>contract in the KotlinBlockPatternmodel (feat(android): add block inserter payload model #465). Emittingnullthere would throwSerializationExceptionon Android.schemas/block-inserter-payload.schema.jsonthat mirrors the KotlinBlockInserterPayloadcontract, plus unit tests that validate the formatters against it viaajv.Dependencies
Targets
trunkdirectly. Self-contained — all files it touches exist ontrunkand #465 (the KotlinBlockInserterPayloadmodel the schema mirrors) has merged.Landing this early rather than stacked on #461 is deliberate: the formatter fix and shape-validating tests act as a defensive guardrail, so when the Android native inserter (#461) flips to ready nothing lands on
trunkalready broken. The?? []path has no consumer until #461 lands — technically dead code today — but the cost of landing early is low and the payoff (no broken-on-trunk intermediate state) is real.feat(android): add block inserter payload model— merged. KotlinBlockInserterPayloadis now ontrunk.feat(android): add native block inserter— still draft. This PR is a guardrail for it but no longer blocks on it.Root Cause
NativeBlockInserterButtonproducedpattern.blockTypes ?? null,pattern.categories ?? null, andpattern.keywords ?? null. The Kotlin model declares those fields as non-nullableList<String>withemptyList()defaults, which meansnullon the wire fails strict deserialization. The bug only surfaces once the bridge is wired up end-to-end, so the shape tests here are the earliest place to catch it.Fix
src/utils/blocks.js: AddformatPatternsForNativeInserterandformatPatternCategoriesForNativeInserter. Array fields default to[]; nullable scalars (description,source,viewportWidth) staynull.src/components/native-inserter/index.jsx: Replace ~20 lines of inline mapping with two function calls.schemas/block-inserter-payload.schema.json: Standalone JSON Schema (draft-07) with$id, field-level descriptions pulled from the Kotlin doc comments, andadditionalProperties: falseon every definition. Consumable by cross-language tooling (quicktype,kotlinx-serializationcodegen) alongside the hand-written KotlinBlockInserterPayload.src/utils/blocks.test.js: Imports the schema and validates payloads viaajv. When either side drifts — wrong type, missing field, or unknown field — the tests fail loudly with a JSON-Pointer path instead of failing silently at bridge-deserialization time. Upstream Gutenberg ships no JSON Schema for these shapes (only JSDoc typedefs onWPEditorInserterItem/WPBlockType), so the schema is hand-written but tracks the Kotlin model as the source of truth.package.json: Addsajvas a direct devDependency (was transitive).Test plan
npx vitest run src/utils/blocks.test.js— 17 tests passmake lint-js-fix— clean