Pre-81: Switch to newer rendering pathways for stagedRender and improve type safety of framework

[JasonVMo]

Platforms Impacted

• all

Description of changes

Type fixes

React 19 + RN 0.81 has much stricter types and the way the framework was handling types was problematic in a number of ways. In particular the framework was mishandling children. This was the result of me not understanding things fully when I wrote the original framework. Some rules to keep in mind:

• a functional component will include children in props.
• the props, ...children[] applies to React.createElement but should not be part of the components themselves.
• ReactElement is a created ReactElement in the tree. Props with children: React.ReactElement must have exactly one child. children?: React.ReactElement means 0 or 1 child.
• ReactNode can be an element, an array of elements, or even a string. children?: React.ReactNode is how you denote a collection of children.
• If props are declared correctly the JSX checker will do the work for you.
• key is not a part of props, it ends up being set on the element itself.

To make things work better this change makes the following type shifts:

• useSlot and it's derivatives accept React.ComponentType. It no longer accepts strings, which means it will not work with web components. In truth it works if you coerce the type of 'div' and so on, but the acceptance of strings complicates some inference rules and makes things less deterministic.
• these always produce ReactElements, you can't return a raw text string as your component value. To my knowledge no one did this, but it has the effect of keeping strong typing and allowing things like native component prop access to work correctly without being cast to any.
• These changes are propogated through useSlots and up through the framework.
• Slot elements are now showing up as real component types in the framework
• Added type templating to Component.compose that allows overriding the type of the slots. It should inference correctly without being set.

stagedComponent -> phasedComponent

I moved much of the stagedComponent usage over to phasedComponent which uses a new signature. The difference is effectively:

// staged example
const MyControl = stagedComponent((props) => {
  // do something including calling your hooks
  return (innerProps, ...children[]) => {
    return <InnerComponent>{children}</InnerComponent>
  }
}
// phased example
const MyOtherControl = phasedComponent((props) => {
  // do hooks work
  return (innerProps) => {
    return <InnerComponent>{innerProps.children}</InnerComponent>
  }
}

With this approach the types of children remain correct and we aren't fighting against the system. I also adjusted it to call the jsx stuff directly and added an interop helper to allow a stagedComponent to act like a phasedComponent.

• direct usage has been moved to phasedComponent
• usage baked into the frameworks has not yet shifted.

Common rendering

Both the old and new code now runs through the jsx-runtime rather than createElement. You can see the code in framework-base to see the adjustments. The renderWithJsxRuntime can now pick the jsx/jsxs routines automatically if they are not specified.

Verification

Tests, pipelines, manual inspection of the controls.

• the tests do validate the node structure hasn't changed.
• e2e tests validate the controls launch and run
• I've done some manual testing as well.