Open tylersouthard opened 1 year ago
It doesn't look like this bug report has enough info for one of us to reproduce it.
Please provide a CodeSandbox (https://material-ui.com/r/issue-template-latest), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem.
Here are some tips for providing a minimal example: https://stackoverflow.com/help/mcve
@mnajdova Here's a link to a CodeSandbox.
My problem with doing a repro is that I can't seem to get CodeSandbox to give eslint errors.
Anyway, in PassingSxProp.tsx on line 20 you can see that sx (when it is an array), is of type any[]
. With the eslint rule 'no-unsafe-assignment' (here), eslint throws an error for the code, which was taken from the MUI example, as described in the original description of the issue.
I'm running into the same issue; the recommended way of passing spreading the sx
prop runs afoul of the aforementioned eslint rule.
I believe the issue is that the Array.isArray()
type guard returns arg is any[]
, which seems to cause typescript's type inference to infer that the type of sx
on the respective branch is any[]
(instead of
ReadonlyArray<
boolean | SystemStyleObject<Theme> | ((theme: Theme) => SystemStyleObject<Theme>)
>
which is the actual variant of SxProps
that is an array. I'm a bit disapointed in the inference.
I couldn't figure out how to get type inference to do the right thing. It seems to me that the the way forward would be for material-ui
to provide a type guard function returning this type, and for the examples to reference it.
Hi everyone,
I see there's been some great discussion around the issue with the sx prop type inference when it's an array, especially in relation to the eslint rule 'no-unsafe-assignment'. I'd like to propose a couple of solutions: a quick fix for now and a more robust long-term solution.
For an immediate resolution, you can use a custom type guard function instead of `Array.isArray(sx)`. Here's the code snippet:
export function isSxArray(
sx: SxProps<Theme>,
): sx is ReadonlyArray<
| boolean
| SystemStyleObject<Theme>
| ((theme: Theme) => SystemStyleObject<Theme>)
> {
return Array.isArray(sx);
}
This should help satisfy the eslint rule by providing a more specific type guard.
To provide a more comprehensive and permanent fix, I suggest making some changes to the type declarations and adding a new exported function:
export type SxPropsArray<Theme extends object> = ReadonlyArray<
boolean | SystemStyleObject<Theme> | ((theme: Theme) => SystemStyleObject<Theme>)
>;
/**
SxProps
can be either object or function
*/
export type SxProps
Add a new exported function:
export function isSxArray(
sx: SxProps<Theme>,
): sx is SxPropsArray<Theme> {
return Array.isArray(sx);
}
Update the docs accordingly
These changes will enhance type safety and address the type loss issue more effectively.
I'm more than happy to assist further with these changes. Let me know if you'd like me to proceed with a pull request or if there are any other steps required.
Looking forward to your feedback!
Best regards,
Nayan
Duplicates
Related page
https://mui.com/system/getting-started/the-sx-prop/#passing-the-sx-prop
Kind of issue
Broken demonstration
Issue description
Perhaps the expectation is that users are not prohibiting the use of the
any
type via eslint, but if I copy theListHeader
component example from the referenced docs page, eslint marks it as an error. Specifically, the case wheresx
is an array, eslint sees it as typeany[]
(see screenshot). I'm wondering if there's a way to make this work with the eslint setting to prevent the use ofany
?Context 🔦
Attempting to make a component that accepts an
sx
property and passes it to its first child component (a MUIBox
) and add a few style prop settings. See screenshot.