From 2a4907d9579a3ebeec19b20a21c91b3f7b711047 Mon Sep 17 00:00:00 2001 From: Darius Lesch Date: Thu, 30 Jul 2026 22:32:41 +0200 Subject: [PATCH 1/3] Added `## Migration to JSON Forms 3.9` heading Added heading "Migration to JSON Forms 3.9" and moved "Data update paths treat all segments literally" from "Mifration to JSON Forms 3.8" to "Migration to JSON FOrms 3.9". This resolves the change request comment for `MIGRATION.md` file in PR #2585. --- MIGRATION.md | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/MIGRATION.md b/MIGRATION.md index 93027572f..7b8be6dfe 100644 --- a/MIGRATION.md +++ b/MIGRATION.md @@ -1,5 +1,17 @@ # Migration guide +## Migration to JSON Forms 3.9 + +### Data update paths treat all segments literally + +Data updates (e.g. dispatched `update` actions) previously wrote to the form data via lodash's `set`/`unset`, which interpret bracket notation and array indices in paths. +This corrupted data for property names that look like lodash path syntax, for example numeric property names like `"15"` were turned into array indices and names containing brackets like `"prop[0]"` were split up (see [#2397](https://github.com/eclipsesource/jsonforms/issues/2397) and [#2102](https://github.com/eclipsesource/jsonforms/issues/2102)). + +Updates now use the new `setDataAt`/`unsetDataAt` utilities of `@jsonforms/core`, which split paths on `.` and treat every segment as a literal property name, matching how JSON Forms resolves values for display. +When a missing intermediate container is created, the JSON Schema decides whether it becomes an array or an object; without schema type information, a numeric follow-up segment creates an array, as before. + +If you dispatch update actions yourself, make sure to use dot-separated paths (e.g. `update('list.0.name', ...)`) instead of lodash bracket syntax (e.g. `update('list[0].name', ...)`), which is no longer interpreted. + ## Migrating to JSON Forms 3.8 ### `Translator` type changed from overloaded signatures to a generic conditional type @@ -40,16 +52,6 @@ return this.t(label, label) as string; This does not affect the Composition API where `Translator` is accessed directly from a `ComputedRef`. -### Data update paths treat all segments literally - -Data updates (e.g. dispatched `update` actions) previously wrote to the form data via lodash's `set`/`unset`, which interpret bracket notation and array indices in paths. -This corrupted data for property names that look like lodash path syntax, for example numeric property names like `"15"` were turned into array indices and names containing brackets like `"prop[0]"` were split up (see [#2397](https://github.com/eclipsesource/jsonforms/issues/2397) and [#2102](https://github.com/eclipsesource/jsonforms/issues/2102)). - -Updates now use the new `setDataAt`/`unsetDataAt` utilities of `@jsonforms/core`, which split paths on `.` and treat every segment as a literal property name, matching how JSON Forms resolves values for display. -When a missing intermediate container is created, the JSON Schema decides whether it becomes an array or an object; without schema type information, a numeric follow-up segment creates an array, as before. - -If you dispatch update actions yourself, make sure to use dot-separated paths (e.g. `update('list.0.name', ...)`) instead of lodash bracket syntax (e.g. `update('list[0].name', ...)`), which is no longer interpreted. - ### Angular support now targets Angular 20 to 22 When using JSON Forms 3.8, your Angular application now needs to target Angular 20, 21 or 22. From 50538936c18943562338b9f23020e502228d4dc4 Mon Sep 17 00:00:00 2001 From: Darius Lesch Date: Thu, 30 Jul 2026 22:44:05 +0200 Subject: [PATCH 2/3] Strict equality checks inside `ownPropertyValue` Added strict equality checks (`!== null && !== undefined`) inside `ownPropertyValue`. This resolves comment in PR #2585 regarding use of loose inequality. --- packages/core/src/util/setData.ts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/packages/core/src/util/setData.ts b/packages/core/src/util/setData.ts index de19f09bb..59f898f15 100644 --- a/packages/core/src/util/setData.ts +++ b/packages/core/src/util/setData.ts @@ -95,7 +95,7 @@ const cloneContainer = (data: any): any => { * properties like `__proto__`, mirroring the semantics of `resolveData`. */ const ownPropertyValue = (data: any, segment: string): any => - data != null && Object.prototype.hasOwnProperty.call(data, segment) + data !== null && data !== undefined && Object.prototype.hasOwnProperty.call(data, segment) ? data[segment] : undefined; From da9df958d563a95dfb8e50a1e9074e15758f7d9c Mon Sep 17 00:00:00 2001 From: Darius Lesch Date: Fri, 31 Jul 2026 10:51:06 +0200 Subject: [PATCH 3/3] Resolve linting issue --- packages/core/src/util/setData.ts | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/packages/core/src/util/setData.ts b/packages/core/src/util/setData.ts index 59f898f15..5b8abdfdd 100644 --- a/packages/core/src/util/setData.ts +++ b/packages/core/src/util/setData.ts @@ -95,7 +95,9 @@ const cloneContainer = (data: any): any => { * properties like `__proto__`, mirroring the semantics of `resolveData`. */ const ownPropertyValue = (data: any, segment: string): any => - data !== null && data !== undefined && Object.prototype.hasOwnProperty.call(data, segment) + data !== null && + data !== undefined && + Object.prototype.hasOwnProperty.call(data, segment) ? data[segment] : undefined;