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

Should we normalize casing for decl names and type names? #3146

Closed
wesbillman opened this issue Oct 17, 2024 · 5 comments
Closed

Should we normalize casing for decl names and type names? #3146

wesbillman opened this issue Oct 17, 2024 · 5 comments
Labels
console Web console dx

Comments

@wesbillman
Copy link
Member

Some examples:

  • should we always use typealias vs. typeAlias in urls and other areas where we check decl case?
  • should we always use getuser vs. getUser for decl names in urls, etc?

We've seen a couple bugs lately specifically with typealias/typeAlias that are a bit tricky to track down. Maybe we need some normalizeX functions to keep things consistent?

@wesbillman wesbillman added console Web console dx next Work that will be be picked up next labels Oct 17, 2024
@github-actions github-actions bot added triage Issue needs triaging and removed triage Issue needs triaging labels Oct 17, 2024
This was referenced Oct 16, 2024
@alecthomas
Copy link
Collaborator

We're supposed to be using lowerCamelCase everywhere for values and UpperCamelCase everywhere for types.

@alecthomas
Copy link
Collaborator

It would be good to have explicit named functions for this though, as opposed to us implicitly using strcase.ToLowerCamel() et al

wesbillman added a commit that referenced this issue Oct 17, 2024
- Fixes issues with `CommandPallete` erroring when `typeAlias` is used
since we had `typealias` in the icons list
- Fixes issues with urls that have `module/typealias/declName` in them
vs. `module/typeAlias/declName`
- Performance improvements on `CommandPallete` searching/filtering.

See also #3146
@alecthomas alecthomas self-assigned this Oct 17, 2024
@github-actions github-actions bot removed the next Work that will be be picked up next label Oct 17, 2024
@alecthomas
Copy link
Collaborator

Caveat to this is that for non-FTL names we should use whatever the casing is for that system. eg. for JSON REST API's we should use whatever the most common naming convention for JSON is. FTR Proto's JSON encoding uses lowerCamel.

@wesbillman
Copy link
Member Author

It would be good to have explicit named functions for this though, as opposed to us implicitly using strcase.ToLowerCamel() et al

Yeah that's the spirit of this ticket for the console side. We currently have quite a few toLower() calls in the ts code, which I would prefer to have a noralizeDecl or something to keep things consistent. So the ftl side is consistent with like getEcho, but console isn't so much.

It's also a bit brittle on the console because a url with typealias will fail, where typeAlias would succeed so we just need to be a bit more tolerant there I think.

@alecthomas
Copy link
Collaborator

Aha! I see, I thought you were referring to the backend, where it's also true.

@alecthomas alecthomas removed their assignment Oct 17, 2024
@alecthomas alecthomas added the triage Issue needs triaging label Oct 17, 2024
@bradleydwyer bradleydwyer added next Work that will be be picked up next and removed triage Issue needs triaging next Work that will be be picked up next labels Nov 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
console Web console dx
Projects
None yet
Development

No branches or pull requests

3 participants