Closed Netail closed 6 months ago
Could you elaborate why this is needed? If you don't provide a reproducible example of the bug then it's hard to judge if these changes are needed.
Could you elaborate why this is needed? If you don't provide a reproducible example of the bug then it's hard to judge if these changes are needed.
@types/react added bigint support since v18.2.78, which currently seems to break typescript when building;
Type error: Argument of type '[string, string | false | 0 | 0n | null | undefined, string | undefined, string | false | undefined, string | undefined]' is not assignable to parameter of type 'ArgumentArray'.
Type 'string | false | 0 | 0n | null | undefined' is not assignable to type 'Argument'.
Type '0n' is not assignable to type 'Argument'.
75 | }) => {
76 | const classes = classnames(
> 77 | children && css.hasChildren,
| ^
as classnames does not support this type. Same issue with clsx; https://github.com/lukeed/clsx/pull/96
I don't think we ever explicitly supported passing in a ReactNode
, what would be the expectation of that? Could you provide a minimal example of passing a ReactNode
in a practical use-case?
I don't think we ever explicitly supported passing in a
ReactNode
, what would be the expectation of that? Could you provide a minimal example of passing aReactNode
in a practical use-case?
For example if you want change some css based on if the children are passed into the component;
import type { FC, PropsWithChildren } from 'react';
import classNames from 'classnames';
import css from './test.module.scss';
export const Test: FC<PropsWithChildren> = ({ children, className }) => {
const classes = classNames(
css.root,
children && css.hasChildren,
className,
);
return (
<div className={classes}>
<h1>Hello</h1>
{children}
</div>
)
}
Thanks, I see your point. Since we have supported this historically I think we should land this, however this should be redirected to the v2
branch, as we intend a different API for v3
in the future, and it will likely not be released for a while.
Thanks, I see your point. Since we have supported this historically I think we should land this, however this should be redirected to the
v2
branch, as we intend a different API forv3
in the future, and it will likely not be released for a while.
You can merge it into main and then cherry pick this change into the v2 branch, maybe? Cuz the main also has the wrong typings
No, this has to go into the v2 branch. The typings are correct for v3, and permutations there are likely to be reduced even further.
No, this has to go into the v2 branch. The typings are correct for v3, and permutations there are likely to be reduced even further.
Will create a new PR for that :) As changing the target branch pulls the commits in
Support new @types/react version (v18.2.78 and higher)