fix(react): IonNav apply properties to page components

[sean-perkins]

Pull request checklist

Please check if your PR fulfills the following requirements:

• Tests for the changes have been added (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)
  • Some docs updates need to be made in the ionic-docs repo, in a separate PR. See the contributing guide for details.
• Build (npm run build) was run locally and any changes were pushed
• Lint (npm run lint) has passed locally and any fixes were made for failures

Pull request type

Please check the type of change your PR introduces:

• Bugfix
• Feature
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Documentation content changes
• Other (please describe):

What is the current behavior?

Root params set on IonNav are not inherited by the root component.

Issue URL: resolves #25602

What is the new behavior?

IonNav will now assign the properties to the page components correctly.

IonNav now supports two ways to assign properties to page components:

Memorized Components

const root = useCallback(() => <MyComponent first="Sean" last="Perkins />, []);

<IonNav root={root} />

rootParams

<IonNav root={MyComponent} rootParams={{ first: "Sean", last: "Perkins" }} />

Additionally, this PR caches element references, which partially resolves an issue with Vite + React and hmr clearing the views within IonNav.

Does this introduce a breaking change?

• Yes
• No

Other information

Dev-build: 6.1.15-dev.11657908598.17be2d80

[averyjohnston]

Do we need to update the docs for rootParams as well?

[sean-perkins]

I have a thought here on how to support both implementation patterns... will report back if it works.

[sean-perkins]

Ok this is ready, we can support both memorized components and rootParams usages. 🎉

[liamdebeasi]

Why do we need the map?

[sean-perkins]

One instance of the delegate is constructed for one instance of IonNav, but IonNav can attach multiple views to the DOM.

The map allows us to keep track of all instances of the individual views that were pushed inside the Nav. We can then do a look-up against the map to find the correct instance to remove the view from the DOM.

In the previous implementation, the value of Component would be reset when a new view was pushed, which prevented the previous view from ever being removed.

Alternatively you could use an object instead of a map here, but since we are associating to a React component, a WeakMap would be my recommendation here so that it does not interfere with garbage collection.