Perf: About the as prop [RFC]

[segunadebayo]

Hey Chakra friends,

I had a test of rc.5 with a friend and I noticed the slowness in the TypeScript IntelliSense as the component gets bigger. To ensure we maintain the same level of Developer Experience when migrating to v1, I'd like to share some drastic ideas.

I have some questions in mind, please feel free to reply with your answers to this:

• How often do you use the as prop?
• Is it worth it to slow down TypeScript IntelliSense in exchange for proper type inference?
• Could we solve this in a different way?

Get rid of the type inference in the as prop
Simply removing the as prop typescript inference, the speed gets back to how it feels in v0.8. To provide some escape hatch for those who heavily rely on the as prop is to provide asProps prop.

// Instead of doing this. TS is slow
<Button as="a" href="..."></Button>

// Use the escape hatch
<Button as="a" asProps={{ href : "..." }}></Button>

Leverage the Chakra factory function
The chakra(...) function already helps to solve a specific problem, which is, enable the use Chakra's style props from any component or element.

// Instead of doing this. TS is slow
<Box as={CustomComponent} />

// Use the chakra function
const Comp = chakra(CustomComponent)

Leverage the chakra object for common HTML elements
Chakra provides a chakra.[element] syntax to supercharge any JSX element with Chakra's style props.

// Instead of doing this. TS is slow
<Box as="a" href="..." />

// Use the chakra object
<chakra.a href="..."></chakra.a>

Let me know your thoughts. The goal is to make this final decision for v1 before the official release (end of October).

[with-heart]

I had a test of rc.5 with a friend and I noticed the slowness in the TypeScript IntelliSense as the component gets bigger. To ensure we maintain the same level of Developer Experience when migrating to v1, I'd like to share some drastic ideas.

Do you have an example of this? I've honestly not been noticing any issues.

[segunadebayo]

I'll prepare an example repo soon. It works perfectly in CodeSandbox but not during local development

[with-heart]

That's really weird! I wonder what would cause the results to be so different.

[ljosberinn]

I'd be curious too, haven't had issues with it either.

[ljosberinn]

Anything that improves DX is fine by me.

• asProps: minor inconvenience to write, but generally helps maintainability with the given component because it's easier to separate chakra props from props passed to the casted component
• chakra(CustomComponent) can be type safe through the use of its generics since it accepts <ReturnType<GivenComponent>, Props>
• leveraging chakra.tag for basic components seems reasonable to me anyways

Of the proposed solution, although I really love as, I'd favor a mix of the 2nd and 3rd.

Edit - a few thoughts when trying to move away from as in my project. Unless we have solid solutions for the following concerns, I'd prefer asProps.

• some props would no longer be possible at this time:

✔️ 
<Heading as="h3" size="md">
⚠️ // this is currently invalid TS
<chakra.h3 size="md"> 
✔️ // works as workaround
const H3 = chakra<'h3', HeadingProps>('h3');
// but this doesn't apply the `size` prop properly

• Another limitation then would be not being able to use e.g. Flex as any other tag than div. I'm using it as section .
  You'd have to use chakra.section d="flex" or

const Section = chakra('section', {
  baseStyle: {
    display: 'flex',
  },
});

then which imo defeats the purpose.

• chakra.b/chakra.strong are currently not supported, but that can be fixed easily. chakra('b') works.

• the docs recommend using MenuButton as={Button}:
  

Without as, how would we solve that?

similarily, I'm using MenuItem as={ExternalLink}:

ExternalLink is already Link from chakra, so wrapping it in chakra wouldn't do anything. I'd be losing the forwarded props of MenuItem without as.

another example: Button as={ExternalLink} - a tag with the visuals of Button

• using chakra on e.g. react-icons with IconProps should allow all IconProps to be passed to baseStyle (or at least right now I'm under the assumption baseStyle is basically defaultProps).

const ExternalLinkIcon = chakra<IconType, IconProps>(FaExternalLinkAlt, {
  baseStyle: {
    display: 'inline-block',
  },
});

However, this errors when trying to add focusable: false. Passing it to the resulting component works.

[chasinhues]

My team and I are experiencing this issue as well, although until now I didn't know it was because of the as prop. We are using as across about ~15 files, some of which are getting up to 150-200 lines. It can sometimes take ~5 seconds for intellisense to do its thing.

It's annoying and hampers DX a bit, but isn't the end of the world. I prefer having as prop and a slightly hampered DX than not having as.

Having said that, being able to have as and an unhindered DX would be ideal 😛

❤️ your work team

[jsefiani]

+ 1

[TimKolberger]

I am using the as prop very often, e.g. 42 times in an application with 54 components.
I think it is one of the USPs which chakra provides.

The lagging TS interference is an issue for me, because it slows me down. Personally I rank the DX higher than the perfect TS interference.

The introduction of asProps is a good way to cope with the TS perf issue.

As @ljosberinn mentioned, the Flex component would be obsolete due <chakra.div d="flex" /> and thats totally fine, the flex component is just renaming prop names, which slows me down when I refactor a Flex to a Box due the shortened prop names.
I would recommend to remove the Flex Component from chakra and enhance the documentation with examples how to build a flexible UI element with chakra.<tag>

[ianstormtaylor]

FWIW, I think asProps sounds like a bad option, since it feels much more convoluted to use than the existing practice of just passing props through. It seems like it would worsen the API to work around TypeScript's performance.

Whereas the <chakra.div> API seems like it actually makes using Chakra easier while also being easier to understand exactly what's going on. And it fixes other UX issues that are present in Chakra, and has the potential to eliminate the need for many existing Chakra components, so I'd definitely prefer it. It sounds great!

[segunadebayo]

I agree @ianstormtaylor!

Thanks for sharing your thoughts.

[segunadebayo]

Updates: We managed to figure out a way to keep the as props, infer types correctly (not 100% perfect though), and get fast IntelliSense in VSCode and WebStorm (IntelliJ).

We'll keep an eye out for things we can improve in the future regarding this.

Cheers

[JakeGinnivan]

I know we have struggled with this in emotion itself, it might be worth pushing the changes down into emotion itself so we can share the benefits of work in this area?