fix(edit-content): scope RelationshipFieldStore to component level #34795

[oidacra]

Summary

• Root cause: RelationshipFieldStore was declared with providedIn: 'root', creating a singleton shared across all relationship field instances on a form
• Fix: Removed root-level provision and added the store to DotRelationshipFieldComponent's providers array so each field instance gets its own isolated store
• Pattern: Follows the same approach used by FileFieldStore and CategoryFieldStore in the codebase

Closes #34795

Changes

File	Change
core-web/.../store/relationship-field.store.ts	Removed { providedIn: 'root' } from signalStore() config
core-web/.../dot-relationship-field.component.ts	Added RelationshipFieldStore to component providers array
core-web/.../dot-edit-content-relationship-field.component.spec.ts	Removed store from host providers, updated edge case tests to access store from component instance

Acceptance Criteria

• Each relationship field in the new Edit Content maintains its own value independently
• Filling one relationship field does not change the value of other relationship fields
• When a content type has two relationship fields referencing different content types (e.g., Blog's "author" and "comments"), both display correct data
• Existing content with multiple relationship fields displays and edits correctly in the new editor
• Content types with a single relationship field continue to work correctly (no regression)
• The legacy Edit Content editor behavior remains unchanged
• When a content type has three or more relationship fields, all fields maintain independent state

Test Plan

• Create a content type with two relationship fields referencing the same content type. Fill one field — verify the other stays empty
• Create a content type with two relationship fields referencing different content types. Verify both display correct related content
• Edit an existing contentlet (e.g., Blog with author + comments) using the new editor — verify both fields show correct data
• Verify single-relationship-field content types still work correctly
• Delete a related item from one field — verify the other field is unaffected

Visual Changes

CleanShot.2026-03-17.at.14.47.49.mp4

Notes

• The component spec (dot-edit-content-relationship-field.component.spec.ts) remains xdescribe (skipped) due to a pre-existing test setup issue (ɵcmp resolution error) unrelated to this fix
• Store unit tests (relationship-field.store.spec.ts) pass — 100 suites, 1639 tests
• The edge case tests in the spec were updated to access the store via spectator.query(DotRelationshipFieldComponent).store instead of spectator.inject(RelationshipFieldStore, true) since the store is now component-scoped

This PR fixes: #34795

[claude]

Claude finished @oidacra's task in 1m 23s —— View job

---

PR Review

• Gather context
• Read changed files
• Analyze changes
• Post review

---

The fix is correct and minimal. Removing providedIn: 'root' and adding the store to providers[] on the component is the right pattern — it matches FileFieldStore and CategoryFieldStore and properly scopes each instance.

A few things worth a second look:

onRowReorder doesn't actually reorder
dot-relationship-field.component.ts:266

this.store.setData(this.store.data());

This calls setData with the unchanged store data — it completely ignores event.dragIndex and event.dropIndex. PrimeNG's table fires this event after mutating its own internal value binding, but the store never reflects the new order. This is pre-existing and not introduced by this PR, but it's worth flagging since it's an observable bug in the field being changed.
Fix this →

xdescribe means none of the component-level tests run
dot-edit-content-relationship-field.component.spec.ts:96
The entire DotEditContentRelationshipFieldComponent spec is still skipped. The test that would actually validate "two fields on the same form stay independent" never runs in CI. The isolation tests added to relationship-field.store.spec.ts are good, but they test the store in isolation — not the component hosting multiple instances. The PR notes this is pre-existing. Fine to merge as-is, but it should be tracked.

Isolation tests reset TestBed mid-test
relationship-field.store.spec.ts:420

const injector1 = TestBed.configureTestingModule({ ... });
const store1 = injector1.inject(RelationshipFieldStore);

TestBed.resetTestingModule();  // store1's injector is now torn down

store1.setData(dataA);  // called on a destroyed injector

This works in practice because setData is synchronous and the store object stays in memory after the injector is reset. But it's fragile — any async operation or DestroyRef-dependent code in a future store method would fail silently. The comment in the file explains the reasoning correctly. It's acceptable for now, but worth noting.

Cosmetic nit — relationship-field.store.ts:90

return `${identifiers}`;

Wrapping a string in a template literal adds nothing. Pre-existing, can ignore.

---

Overall: fix is correct, clean, and follows the established pattern. The xdescribe gap is the only real concern worth tracking in a follow-up.