material-ui: [Box] Type error when too many properties exist in JSX.IntrinsicElements
Duplicates
- I have searched the existing issues
Latest version
- I have tested the latest version
Current behavior 😯
The Box component produces type errors when too many properties are added to JSX.IntrinsicElements.
Expected behavior 🤔
The Box component should not produce type error when properties are added to JSX.IntrinsicElements.
Steps to reproduce 🕹
When using @mui/material in the same project with @react-three/fiber and @react-three/drei using the Box component produces a type error:
error TS2590: Expression produces a union type that is too complex to represent.
import React from 'react';
import { Box } from '@mui/material';
import { Canvas } from '@react-three/fiber';
import { OrbitControls } from '@react-three/drei';
function Root() {
return (
<Box sx={{ m: 1 }}>
<Canvas>
<OrbitControls />
</Canvas>
</Box>
);
}
Output
import React from 'react';
import { Box } from '@mui/material';
import { Canvas } from '@react-three/fiber';
import { OrbitControls } from '@react-three/drei';
function Root() {
return (React.createElement(Box, { sx: { m: 1 } },
React.createElement(Canvas, null,
React.createElement(OrbitControls, null))));
}
Compiler Options
{
"compilerOptions": {
"strict": true,
"noImplicitAny": true,
"strictNullChecks": true,
"strictFunctionTypes": true,
"strictPropertyInitialization": true,
"strictBindCallApply": true,
"noImplicitThis": true,
"noImplicitReturns": true,
"alwaysStrict": true,
"esModuleInterop": true,
"declaration": true,
"experimentalDecorators": true,
"emitDecoratorMetadata": true,
"target": "ES2017",
"jsx": "react",
"module": "ESNext",
"moduleResolution": "node"
}
}
Playground Link: Provided
This behavior can also be replicated without any dependence on @react-three/fiber or @react-three/drei by adding properties to JSX.IntrinsicElements:
import React from 'react';
import { Box } from '@mui/material';
declare global {
namespace JSX {
interface IntrinsicElements {
test1: number;
test2: number;
test3: number;
test4: number;
test5: number;
test6: number;
test7: number;
test8: number;
test9: number;
test10: number;
test11: number;
test12: number;
test13: number;
test14: number;
test15: number;
test16: number;
test17: number;
test18: number;
test19: number;
test20: number;
test21: number;
test22: number;
test23: number;
test24: number;
test25: number;
test26: number;
test27: number;
test28: number;
test29: number;
test30: number;
test31: number;
test32: number;
test33: number;
test34: number;
test35: number;
test36: number;
test37: number;
test38: number;
test39: number;
test40: number;
test41: number;
test42: number;
test43: number;
test44: number;
test45: number;
test46: number;
test47: number;
test48: number;
test49: number;
test50: number;
test51: number;
test52: number;
test53: number;
test54: number;
test55: number;
test56: number;
test57: number;
test58: number;
test59: number;
test60: number;
test61: number;
test62: number;
test63: number;
test64: number;
test65: number;
test66: number;
test67: number;
test68: number;
test69: number;
test70: number;
test71: number;
test72: number;
test73: number;
test74: number;
test75: number;
test76: number;
test77: number;
test78: number;
test79: number;
test80: number;
test81: number;
test82: number;
test83: number;
test84: number;
test85: number;
test86: number;
test87: number;
test88: number;
test89: number;
test90: number;
test91: number;
test92: number;
test93: number;
test94: number;
test95: number;
test96: number;
test97: number;
test98: number;
test99: number;
test100: number;
test101: number;
test102: number;
test103: number;
test104: number;
test105: number;
test106: number;
test107: number;
test108: number;
test109: number;
test110: number;
test111: number;
test112: number;
test113: number;
test114: number;
test115: number;
test116: number;
test117: number;
test118: number;
test119: number;
test120: number;
test121: number;
test122: number;
test123: number;
test124: number;
test125: number;
test126: number;
test127: number;
test128: number;
test129: number;
test130: number;
test131: number;
test132: number;
test133: number;
test134: number;
test135: number;
test136: number;
test137: number;
test138: number;
test139: number;
}
}
}
function Root() {
return <Box sx={{ m: 1 }} />;
}
Output
import React from 'react';
import { Box } from '@mui/material';
function Root() {
return React.createElement(Box, { sx: { m: 1 } });
}
Compiler Options
{
"compilerOptions": {
"strict": true,
"noImplicitAny": true,
"strictNullChecks": true,
"strictFunctionTypes": true,
"strictPropertyInitialization": true,
"strictBindCallApply": true,
"noImplicitThis": true,
"noImplicitReturns": true,
"alwaysStrict": true,
"esModuleInterop": true,
"declaration": true,
"experimentalDecorators": true,
"emitDecoratorMetadata": true,
"target": "ES2017",
"jsx": "react",
"module": "ESNext",
"moduleResolution": "node"
}
}
Playground Link: Provided
Context 🔦
This is primarily in the context of trying to use @react-three/fiber and @react-three/drei in the same project as @mui/material. Related issues include https://github.com/mui/material-ui/issues/29176 and https://stackoverflow.com/questions/68692230/ts-expression-produces-a-union-type-that-is-too-complex-to-represent-with-materi. The latter issue seems to suggest this has been resolved, but I do not believe it has been.
Your environment 🌎
tsconfig.json included above.
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 13
- Comments: 31 (21 by maintainers)
With the mui 5.14.1 update this error occurs on even more components, e.g. ToggleButton, Typography, Card, Divider, etc. Version 5.14.0 was fine.
I’m working on a large code base and changing the imports or updating the component type everywhere is not deemed acceptable, so I am also still looking for a real solution.
We experienced this issue in joy-ui but somehow it just happened yesterday and we’ve been updating the betas on each new release 🤷 . Now when I roll back I can still see the issue. After a lot of refactoring we had to remove ALL usages of
Boxand mostly use this now:So generally
Boxis completely broken for us.This cost us a lot of nerv and unplanned refactoring.
Please prioritize this issue as it can/will break a lot of big projects.
I’m a bit scared to check which new bugs were introduced by the refactoring but hopefully our tests will catch them.
❤️
EDIT: this is probably helpful 😉
Yes, of course.
I have a workaround by patching the
Box.d.tstype in @mui/material, @mui/system, and @material-core withpatch-packageand replacing the types with