Reintroduce a parent link on model nodes

[QuentinRoy]

Fixes #167

Model nodes expose their sub-items but have no way back up: given an item, there's no way to find the menu it belongs to. This link existed before the TypeScript migration and was dropped there, since restoring it created a circular type: a node's type would reference its parent's type, which references it back.

This restores parent by changing how a node's type is described. Instead of a node's own id, label and items, each node is now described by the whole menu it belongs to, plus a path locating it within that menu. parent is then the same lookup with the last step of the path dropped, so a node and its parent are derived independently from the menu description rather than one being defined in terms of the other. The root's parent is always null.

The runtime construction order changes to match: a node is built before its items, which are then built with it as their parent.

A menu built at runtime rather than described as a literal still works, but its items lose the precise typing, the same trade-off id and label already make in that case.

You can check the new behavior directly:

const menu = createModel({
  items: [{ id: 'a', label: 'A', items: [{ id: 'b', label: 'B' }] }],
});
menu.items[0].items[0].parent === menu.items[0]; // true
menu.parent; // null

Tests cover parent at runtime, at every level, with the root having none, and what the type system knows about it for both a literal menu description and one built dynamically.

[changeset-bot]

🦋 Changeset detected

Latest commit: 16934e4

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
marking-menu	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR