Box from @mui/material/Box and return from createBox return different types

[subvertallchris]

Duplicates

• I have searched the existing issues
• There was an identically named issue a year ago, createBox and Box from @mui/system return different types. #29978. A fix was merged in December 2021. I'm not sure if this is a new issue or a regression.

Latest version

• I have tested the latest version

Steps to reproduce 🕹

Link to live example: https://codesandbox.io/s/mystifying-fog-0xol3s?file=/src/App.tsx

Steps: You'll see the compiler error on line 10 when assigning the variable and then another on line 34 when we try to use BoxProps with an instance whose type has been inferred.

Current behavior 😯

There is a compiler error when you assign the output of createBox to a variable whose type is typeof Box. It appears that the typeof Box coming from createBox and the one from @mui/material/Box are different.

Expected behavior 🤔

I expect that the Box returned by createBox accepts the same props as the Box imported from @mui/material/Box so I can use them interchangeably.

Context 🔦

I discovered that Box has a unique approach to custom themes, so I need to swap out my project's internal definition of Box with a custom one. After doing this, I'm seeing that spots where I spread BoxProps into components, like <CustomBox {...props}>, get a compiler error. This is surprising because createBox has a return type of typeof Box, so I conclude that these are different boxes!

Your environment 🌎

React 18 with MUI 5.11.0 in CodeSandbox and React 17 with MUI 5.8.3 locally. The browser appears to work correctly but I am concerned that these errors mean that the two Box versions will not behave consistently, so I don't know whether to push past the error by asserting type or wait for a fix.

Appreciate your help!

[mnajdova]

Nice, catch, there is a space for improvement here. We could add generics for the Theme and provide a component that would reflect the props based on this. We could also accept additional props just to be safe.

[subvertallchris]

Great, thanks. Can you explain the root of the problem? I wouldn't expect the theme to change props that Box accepts so I don't understand the relationship between a new generic for Theme and the new component's props. I can try to provide a PR if you can point me in the right direction.

In the meantime, is it safe for us to do createBox({ defaultTheme }) as typeof Box to workaround the compiler error for now?

[subvertallchris]

Hi, sorry to be a bother but can you let me know about whether it is safe for us to assert the type? Phrased differently, is this a type problem where the underlying code will accept the right props or is the object coming out of createBox truly incompatible with MUI's Box?

[mnajdova]

@subvertallchris sorry for the delay, it is a type, not a runtime problem. Doing a cast is the recommendation, until we merge #35532 which would fix the issue.

As long as you use the right defaultTheme - Material UI's as you already are, there shouldn't be any problems.

[mnajdova]

Btw, what's the motivation for creating a custom Box component?

[subvertallchris]

Perfect, thank you! Our theme extends the default with custom breakpoints, a custom Box is needed to keep everything consistent.

…

On Wed, Jan 4, 2023 at 6:25 AM Marija Najdova ***@***.***> wrote: Btw, what's the motivation for creating a custom Box component? — Reply to this email directly, view it on GitHub <#35506 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA7IJ5Y7ULGOXU4XY56SRFTWQVMYZANCNFSM6AAAAAATBRVUOM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mnajdova]

Perfect, thank you! Our theme extends the default with custom breakpoints, a custom Box is needed to keep everything consistent.

You shouldn't need a custom Box component for this but maybe there are more details that I am not aware of. The issue has been fixed, it will be part of the release next Monday.

[subvertallchris]

Odd, so what's the process to apply our theme's breakpoints to Box? It doesn't respect ThemeProvider with our custom theme. The docs here say that this is the right approach. Is there an alternative for applying our custom theme's breakpoints?

[subvertallchris]

@mnajdova When you've got a moment, could you let me know if I could/should be doing something other than creating a custom Box if my goal is drawing breakpoints from our custom theme?

[mnajdova]

Ah I see, the use-case there is if you want to process differently some values in the sx prop, but we changed the approach with https://mui.com/system/experimental-api/configure-the-sx-prop/. It should work as expected if you have custom breakpoints. Maybe a codesandbox of what doesn't work would help. The "Custom breakpoints" section here should help with what you need: https://mui.com/system/getting-started/usage/#responsive-values