As our tests currently perform asserts only for root slot these tests are not applicable.

As our typings are strict we don't allow to pass data- attributes:

src/components/Tooltip/Tooltip.test.tsx:52:11 - error TS2322: Type '{ children: JSX.Element; id: string; 'data-testid': string; }' is not assignable to type 'ShorthandProps<{ as?: "div" | undefined; } & Pick<DetailedHTMLProps<HTMLAttributes<HTMLDivElement>, HTMLDivElement>, "key" | keyof HTMLAttributes<...>> & { ...; } & { ...; }>'.
  Object literal may only specify known properties, and ''data-testid'' does not exist in type 'ReactElement<any, string | JSXElementConstructor<any>> | ReactNodeArray | ReactPortal | ({ as?: "div" | undefined; } & Pick<...> & { ...; } & { ...; })'.

52           'data-testid': 'the-tooltip',
             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This probably should be turned into an issue.

FYI, I'm removing the data attributes from the tests with this PR: #21331.

I agree it's still an issue that our types don't allow for data attributes, but at least it won't be an issue in this particular case.

Keeping it as it is impossible as it causes a set of TS issues:

src/components/Tooltip/Tooltip.tsx:11:14 - error TS2322: Type 'ForwardRefExoticComponent<RefAttributes<unknown>>' is not assignable to type 'never'.

11 export const Tooltip: ForwardRefComponent<TooltipProps> = React.forwardRef((props, ref) => {
                ~~~~~~~
src/components/Tooltip/Tooltip.tsx:12:28 - error TS2345: Argument of type '{ children?: ReactNode; }' is not assignable to parameter of type 'TooltipProps'.
  Type '{ children?: ReactNode; }' is not assignable to type '{ children?: (ReactElement<any, string | JSXElementConstructor<any>> & { ref?: Ref<unknown> | undefined; }) | ((props: TooltipTriggerProps) => ReactNode) | undefined; }'.
    Types of property 'children' are incompatible.
      Type 'ReactNode' is not assignable to type '(ReactElement<any, string | JSXElementConstructor<any>> & { ref?: Ref<unknown> | undefined; }) | ((props: TooltipTriggerProps) => ReactNode) | undefined'.
        Type 'null' is not assignable to type '(ReactElement<any, string | JSXElementConstructor<any>> & { ref?: Ref<unknown> | undefined; }) | ((props: TooltipTriggerProps) => ReactNode) | undefined'.

12   const state = useTooltip(props, ref);
                              ~~~~~
src/components/Tooltip/Tooltip.tsx:18:9 - error TS2339: Property 'displayName' does not exist on type 'never'.

Merging is not longer requires as it's done in useTriggerElement().

Since we don't have a root slot, this probably shouldn't use forwardRef. If someone needs a ref to the content slot, they can pass it as an attribute to that slot.

Well, it should as we also forwarding refs for composition purpose to trigger:

<MenuTrigger>
  <Tooltip>
    <button />
  </Tooltip>
</MenuTrigger>

In this example MenuTrigger still need to pass ref to button, without ref forwarding it's not possible. As an option we can use cast to a regular React.FunctionComponent to hide this contract. WDYT?

Just to make sure I understand, if I write the following, you're saying myRef be the <button />?

<Tooltip ref={myRef} content="...">
   <button />
</Tooltip>

That seems weird to me... first that the ref on Tooltip goes to another element other than the Tooltip, and second if we're forwarding ref, why aren't we forwarding other props?

Stepping back a minute, I wonder if another way to solve the problem of applying props to the trigger would be to update onlyChild to know to drill through to the children of Tooltip and MenuTrigger the same way that it currently drills through to the children of React.Fragment. That way both MenuTrigger and Tooltip would be able to "see through" each other to the trigger element, and they could apply props and refs to the trigger directly, instead of relying on the other to forward them.

E.g. maybe we could have an attribute e.g. isFluentTrigger (except with a better name) on the Tooltip and MenuTrigger types like:

// in Tooltip.tsx:
Tooltip.isFluentTrigger = true;

// in MenuTrigger.tsx:
MenuTrigger.isFluentTrigger = true;

// New utility function isFluentTrigger:
const isFluentTrigger = <P>(type: React.ReactElement<P>['type'] & { isFluentTrigger?: boolean }) => {
  return typeof type !== 'string' && 'isFluentTrigger' in type && type.isFluentTrigger;
};

// in onlyChild.ts:
return child.type === React.Fragment || isFluentTrigger(child.type) ? onlyChild(child.props.children) : child;

Just to make sure I understand, if I write the following, you're saying myRef be the <button />?

<Tooltip ref={myRef} content="...">
   <button />
</Tooltip>

That seems weird to me... first that the ref on Tooltip goes to another element other than the Tooltip, and second if we're forwarding ref, why aren't we forwarding other props?

Correct and we are forwarding props. It's how composition of triggers works.

Stepping back a minute, I wonder if another way to solve the problem of applying props to the trigger would be to update onlyChild to know to drill through to the children of Tooltip and MenuTrigger the same way that it currently drills through to the children of React.Fragment. That way both MenuTrigger and Tooltip would be able to "see through" each other to the trigger element, and they could apply props and refs to the trigger directly, instead of relying on the other to forward them.

We had similar approach in N*, but with React you cannot predict element's children:

function MyTrigger(props) {
  const data = useData();

  return (
    <MenuTrigger {...props}>
      <CustomButton>{data.count}</CustomButton>
    </MenuTrigger>
  );
}

In this example MyTrigger.isFluentTrigger will be undefined, but it still valid code.

This type cast allows to hide ref from Tooltip props.