Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restrict props types #17

Open
jgoux opened this issue Mar 25, 2021 · 10 comments
Open

Restrict props types #17

jgoux opened this issue Mar 25, 2021 · 10 comments

Comments

@jgoux
Copy link

jgoux commented Mar 25, 2021

Hello,

When using styled I noticed that all the possible html props types are available on the component created which hid the variant in a very long list.

I think the whole point of styled is to restrict the set of the possible native props + providing our variants.

Is there a way to restrict the component's props to its variants + a specific subset (or no subset at all) of the possible other native props for the specific component used as the first argument?

For example I defined a Text component using styled("span", { /* some variants */ }) and here is what I have as possible props (a very long list ^^) :
image

@sastan
Copy link
Collaborator

sastan commented Mar 25, 2021

That kind of autocompletion is not helpful. I noticed that too. Do you know how emotion/styled-components handle that?

I see 2 ways to solve this:

  1. remove all additional attributes and use Record<string, unknown> – that would remove all type checking for these props
  2. Extend the Twind VS Code Extension to show the variants first in the list

Did I miss something?
Are there other ways?

@jgoux
Copy link
Author

jgoux commented Mar 26, 2021

This doesn't seem to be an issue with stitches :

image

Codesandbox here : https://codesandbox.io/s/competent-almeida-oxf56?file=/src/App.tsx

They are doing a lot of heavy lifting at the type level : https://github.com/modulz/stitches/blob/canary/packages/react/types/index.d.ts#L42

@sastan
Copy link
Collaborator

sastan commented Mar 26, 2021

I see the same problem with stitches in the codesandbox: https://codesandbox.io/s/busy-matsumoto-tp3ik?file=/src/App.tsx

Bildschirmfoto 2021-03-26 um 16 40 32
Bildschirmfoto 2021-03-26 um 16 40 48

@sastan
Copy link
Collaborator

sastan commented Mar 26, 2021

But that doesn't mean it can not be improved

Maybe we go with solution 2: Extend the Twind VS Code Extension to show the variants first in the list

What do you think?

@jgoux
Copy link
Author

jgoux commented Mar 26, 2021

Yes it would be a great improvement to start with, then maybe in the future we will find TS tricks to have a more native solution. 👍

@sastan
Copy link
Collaborator

sastan commented Mar 26, 2021

I believe the problem is that the default typescript IntelliSense shows all possible properties. But if you remove them you either allow any properties or no additional properties.

I'll try to take a look at the weekend.

Would be ok with if I move this to the typescript-plugin repo?

@jgoux
Copy link
Author

jgoux commented Mar 26, 2021

Of course @sastan, let's move this and have a great week-end!

@sastan sastan transferred this issue from tw-in-js/twind-react Mar 26, 2021
@andreypopp
Copy link

Maybe we go with solution 2: Extend the Twind VS Code Extension to show the variants first in the list

I'm using tsserver with this plugin but with vim, not VS Code so it would be really nice to have this fixed on the plugin side rather than on an editor extension side.

Does the plugin has access to AST? In this case the plugin could only provide additional autocompletion if the cursor is within the tw(...) call, what do you think of this solution?

@sastan
Copy link
Collaborator

sastan commented Apr 12, 2021

Once solved the fix would be within the typescript-plugin.

Does the plugin has access to AST?

Yes. Autocompletion should only be provided within specific methods (tw, style, apply).

@igorbrasileiro
Copy link

I'm using tsserver with this plugin but with vim, not VS Code so it would be really nice to have this fixed on the plugin side rather than on an editor extension side.

Can you share your setup to use this plugin with vim?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants