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

Allow constant exports doesn't work with objects. #36

Closed
AaronPowell96 opened this issue Jan 19, 2024 · 7 comments
Closed

Allow constant exports doesn't work with objects. #36

AaronPowell96 opened this issue Jan 19, 2024 · 7 comments
Labels
enhancement New feature or request

Comments

@AaronPowell96
Copy link

I am looking to create some way where these constants would work.
If I am able to say these are immutable with as const or if the plugin would be able to infer that simply by a full capitalisation of a variable that would be nice. If I write const MY_CONSTANT = {} I am telling you 'I will not mutate this, it is a constant'.

There should be no warning below?
image

@ArnaudBarre
Copy link
Owner

The issue is that you need also the React refresh runtime to skip that. I will probably add an option to the Vite React plugins to support Remix, and this option could be later used to support this kind of use case.

For now the safest way is to have a small file along the current file to export this constants

@ArnaudBarre ArnaudBarre added the enhancement New feature or request label Jan 21, 2024
@DonnyVerduijn
Copy link

It seems, that this option also doesn't involve enums?

@ArnaudBarre
Copy link
Owner

Yeah TS enums are transpiled to JS objects so they are not "constants". I encourage you to use string based enums that are ignored because type only and aligned better with the current direction of TS to not add any runtime behaviour that is not defined in JS.

@GerroDen
Copy link

GerroDen commented Jul 24, 2024

I agree, that it would be great to have this feature to allow enums as part of the prop definition to be exported without any issue. This seems a valid case to me.

export enum Type {
  a = "a",
  b = "b",
}

interface ComponentProps {
  type: Type;
}

export function TypeComponent({ type }: ComponentProps) {
  return <div>{type}</div>;
}

So I can use

<TypeComponent type={Type.a} />

@ArnaudBarre
Copy link
Owner

Using enum is really something that goes against the current trend of TS to be just a typechecker for JS. These kind of runtime features (enum, namespaces, parameters properties) where all added a long ago.

I strongly advised using string enums:

export Type  = "a" |  "b";

interface ComponentProps {
  type: Type;
}

export function TypeComponent({ type }: ComponentProps) {
  return <div>{type}</div>;
}
<TypeComponent type="a" />

@GerroDen
Copy link

In vanilla JS we would likely define a constant object with these string types as values just like an enum does. It's just a shorthand.
So instead of enums we would like to define:

export Type = "a" | "b";
export componentType = {
  a: "a",
  b: "b".
} as const;

Which is equal to the output of string-based enums in TS.

@ArnaudBarre
Copy link
Owner

I'm doing some cleanup of the backlog, and few months later I don't think this worth adding. This would require a lot a coordinations with bundlers and still make the rule more confusing on what can be exported.
Primitive constant is good because it easy and ship to implement, but everything else then come with edge cases.

@ArnaudBarre ArnaudBarre closed this as not planned Won't fix, can't repro, duplicate, stale Nov 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants