Rmwc: TS x rmwc x styled component: Type instantiation is excessively deep and possibly infinite

[Msordet]

Hi!

Following a Typescript update, I'm getting this error a lot when using styled component above a rmwc component:
Type instantiation is excessively deep and possibly infinite. (ts2589)

Right now my workaround is to move the styled components to Sass but that's not ideal.
I'm not sure what to look at here but I'd like to help!

Reproduction

https://codesandbox.io/s/recursing-cdn-f00ic
It uses all the latest version of the libraries.

[jamesmfriedman]

I isolated the issue by going through the code sandbox and downgrading @types/styled-components point release by point release and have found that the conflicts pops up in in 4.1.9. 4.1.8 is a working version.

Something they introduced between that point release is causing the issue, you may want to open an issue up with them at definitely typed. For now, it appears you can downgrade you types package, though I'm unsure of the implications of that.

Working sandbox https://codesandbox.io/s/elastic-agnesi-rxiq3

[gabehayes]

Not saying that the change has to occur here or there, just wanted to share some additional context from what I found when encountering this.

I found that exporting material components with the ComponentType in the base component was causing this complaint. My hunch is that when wrapping these with styled components, because ComponentType has branches it introduces too many conditions and hence, this complaint?

Anyhow, I quieted it down by casting the specific type of export, such as:

import { Card as MaterialCard, CardProps } from '@rmwc/card';
import { ComponentProps, MergeInterfacesT } from '@rmwc/types';
import { FunctionComponent } from 'react';
import styled from 'styled-components';

export const Card = styled(MaterialCard as FunctionComponent<
  MergeInterfacesT<CardProps, ComponentProps>
>)`
  // card styles
`;

[baidefeis89]

you have to specify type for you're custom component

const CustomCard = styled(Card)
width: 21rem;
background: whitesmoke;
.withComponent('div');

[j-o-d-o]

The problem we got now, is that the styled component version 4.1.8 is not working properly with the latest typescript (v3.7.x) anymore :(. So currently we are stuck with ts: 3.6.4 and styled components: 4.1.8.

By the way, here is the corresponding typescript issue. Looks like they are still trying to figure out if it a bug or a feature ;)

[LonJonn]

It isn't a bug and is working as intended.

For example, here are the typings for the Button component:

// @rmwc/button/dist/index.d.ts
export declare const Button: React.ComponentType<Pick<ButtonProps & RMWC.ComponentProps, "onError" | "className" | "icon" | "prefix" | "size" | "children" | "ripple" | "value" | "cite" | "data" | "form" | "label" | "span" | "style" | "summary" | "title" | "pattern" | "theme" | "onBlur" | "onClick" | "onContextMenu" | "onCopy" | "onCut" | "onAuxClick" | "onDoubleClick" | "onDragEnd" | "onDragStart" | "onDrop" | "onFocus" | "onInput" | "onInvalid" | "onKeyDown" | "onKeyPress" | "onKeyUp" | "onMouseDown" | "onMouseUp" | "onPaste" | ... & so on

That _is_ excessively deep. TS stops after 50 steps and then gives this message. Here is another thread with the same issue.

Seems like type definitions will need to be changed to resolve this issue.

[jamesmfriedman]

All RMWC components extend React.HTMLProps. It looks like transpiler is splitting those apart for some reason which could be the cause of the issue.

In more than a few places, a type has a key that has to be ommited because it conflicts. For instance Button has a label prop that accepts Reacf.ReactNode but HTMLProps says it can only be a string, so I Omit the level prop dome HTMLProps.

This could be the issue as the compiler is deciding to flatten that type and end up with the very long union type. TS now includes an Omit helper which was not previously available, so maybe refactoring to use that could help this issue. Thoughts?

[LonJonn]

Seems like a good choice and will definitely improve maintainability. I wish TS would add a setting to change the number of steps it will go through before throwing the error though.

[jamesmfriedman]

Hard to know what fixed this, I did have a major overhaul of the internal typing of RMWC, but as of 6.rc0 (and just blindly upgrading all of the types across the board) the sandbox works.

https://codesandbox.io/s/nervous-goodall-7rph5

[jamesmfriedman]

Fixed in 6.0.0.

[JCofman]

Hi @jamesmfriedman I played around with the current version -> https://codesandbox.io/s/festive-meninsky-uhtic but I think some types are still problematic for example the TextField component

[jamesmfriedman]

@JCofman I haven't used this with styled components + Typescript, but the problem seems to just be with the styled components part. Check out this sandbox, the non styled component works without issue.

https://codesandbox.io/s/quizzical-lichterman-0zhvx

[jamesmfriedman]

@JCofman I still think this is a problem with styled-components typings. I installed the same dependencies as the code sandbox locally so I could poke around and modify the types in realtime. Heres what I know.

• Yes, RMWC does have some complex type signatures under the hood to allow for things like passing in your own component (the tag prop) and inheriting the types from that. My initial reaction was "oh, it must be from that"

Here is the base declaration of TextField

Which results in our current error

Now, if I strip this type down to the a react component that accepts all of the props for a standard input element, I get our old error

It is necessary for a UI library to allow all of the props that the DOM allows, at least at this point I know it's not RMWC.

Now, the absolute lamest workaround is you can manually cast the types.

This is pissing me off, I'm going to contact someone from styled components and see if we can figure it out.

[JCofman]

Hi, @jamesmfriedman thanks a lot for putting your time and afford in regards to my annotation :) 👍. I didn't want to disturb you just noticed this behavior. Let me know if I can help you

[jamesmfriedman]

Help would be great. It’s definitely something on the styled components side though, I’m sure of that now.

[gugu]

@jamesmfriedman I did some investigation. Currently @types/styled-components check if component extends React.ComponentClass and treats is as a component in this case.

All RMWC Components extend RMWC.ComponentType, which is

{ <Tag extends React.ElementType<any> = Element>(props: ComponentProps<Props, ElementProps, Tag>, ref: any): JSX.Element; displayName?: string; } . Changing base class to React.ComponentClass fixes the problem. I'll try to send PR

[jamesmfriedman]

That would appear to be a shortcoming on the styled components side then (I think). React.ComponentClass references class based components where React.ComponentType is both functional and class components.