Bump @types/react to v18.3.6

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
@types/react (source)	^18.3.4 -> ^18.3.6
@types/react (source)	18.3.4 -> 18.3.6

---

Configuration

📅 Schedule: Branch creation - "on sunday before 6:00am" in timezone UTC, Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[mui-bot]

Netlify deploy preview

https://deploy-preview-43555--material-ui.netlify.app/

Bundle size report

Details of bundle changes (Toolpad)
Details of bundle changes

Generated by 🚫 dangerJS against 97bacdd

[DiegoAndai]

@michaldudak this @types/react version breaks how we handled polymorphic components in @mui/base (see DefinitelyTyped/DefinitelyTyped#70361). We could freeze the @mui/base version of @types/react, but we need to solve BasePopper.tsx, which was copied to @mui/material to remove the @mui/base dependency. For example, this removes the error:

-const PopperTooltip = React.forwardRef(function PopperTooltip<
+const PopperTooltip = React.forwardRef<HTMLDivElement, PopperTooltipProps>(function PopperTooltip<
   RootComponentType extends React.ElementType,
 >(props: PopperTooltipProps<RootComponentType>, forwardedRef: React.ForwardedRef<HTMLDivElement>) {

(source)

But it seems to me like this breaks the polymorphic usage of the RootComponentType generic. I'm not that familiar with the PolymorphicProps type so I'm not sure.

Is this the correct fix?

[michaldudak]

Since we're casting the result of forwardRef to PolymorphicComponent<PopperTypeMap>, the change you're proposing should be safe and not noticeable for external users.

[Janpot]

@DiegoAndai This seems to be the naive solution. Wouldn't that work?

[DiegoAndai]

Thanks @Janpot! looks good to me.

Does this mean we can revert my commit? a5548f5

[Janpot]

Does this mean we can revert my commit?

I believe so, we can solve it the same way by making the ref optional.

[DiegoAndai]

I believe so, we can solve it the same way by making the ref optional.

Thanks! I'll do it and update the PR

[aarongarciah]

@DiegoAndai I just rebased on top of master and removed your commit. I need this PR to fix some stuff #43964 (comment) I'll try to apply the necessary changes. Let's see if we can land this PR today.

[DiegoAndai]

@aarongarciah @Janpot I had to bring back my fix (this one): dd9c8fe and bb9f21b

Seems to me that this particular problem can't be fixed with the approach in #43792, but instead is caused by something not working with forward ref inference and our polymorphic types after DefinitelyTyped/DefinitelyTyped#70361. Please correct me if I'm wrong.

Because this issue is mainly inside mui-base, which is stale, and one material component that should be eventually removed, plus the components being casted anyways, I would merge this one to unblock the release.

[aarongarciah]

@DiegoAndai it's fine for me. I see we need to bring the changes in the docs Next.js config file because after pnpm dedupe, next points to the newest 14.x.x version (see error https://app.netlify.com/sites/material-ui/deploys/66fd4632cd5fe8000889b866#L295)

[Janpot]

Seems to me that this particular problem can't be fixed with the approach in #43792, but instead is caused by something not working with forward ref inference and our polymorphic types after DefinitelyTyped/DefinitelyTyped#70361. Please correct me if I'm wrong.

Ok, I think I see what's happening, forwardRef infers PopperTooltipProps<React.ElementType> as props which includes the <details> element, which has a open property that can be undefined. The solution should be fine.