Runtime change: the component was not receiving any props (and it's internal to this file)

Runtime change: always return a motion.div — I made this change because it would have been otherwise difficult to type AnimatedWrapper, since standard HTML elements and motion elements have different types for the same prop names

Using new variables because flip and resize are readonly (const)

Runtime change: using firstElementChild instead of firstChild, since firstChild can return a Node (that doesn't have the style property). The additional instanceof HTMLElement makes TypeScript happy and adds an extra layer of precaution.

This was somehow necessary to make TypeScript happy

Runtime change: somehow Number.isFinite( arrowData.x ) was not guarding against arrowData.x not being undefined, and so I added an explicit check (same for arrowData.y)

An alternative to this could be to:

• move the Popover component from index.tsx to component.tsx
• use index.tsx to export the Slot, __unstableSlotNameProvider and default exports — something like:

export function Slot (
	{ name = SLOT_NAME }: { name?: string },
	ref: ForwardedRef< any >
) {
	return (
		<Slot
			// @ts-expect-error Need to type `SlotFill`
			bubblesVirtually
			name={ name }
			className="popover-slot"
	);
}

export const __unstableSlotNameProvider = slotNameContext.Provider;

export {Popover as default} from './component.tsx`;

Thoughts? Could it work?

Runtime change: function return type changed to null instead of undefined, in order to match @floating-ui's setReference function signature (used in the Popover component)

Runtime change: using parentElement instead of parentNode, since Nodes don't have the getBoundingClientRect() function and therefore can't be used as the popover's reference (anchor)

Just checking: The reasoning behind this change is that consumers should be responsible for changing the object reference when necessary?

No, I simply wanted to simplify the code and avoid the creation of a new object every time — was that intended? Happy to revert

Seems intentional to me, although it's unclear whether it's warranted. If you haven't looked into it specifically, it might be better to bump that change to a separate issue, since it seems like the kind of thing that would have implications 👻 (It might be good implications though!)

The last PR to edit those lines was #41900

Anyway, I went ahead and reverted the above change in dac81ea

Removed container as a possible option as it looks like it was removed in #27699