-
Notifications
You must be signed in to change notification settings - Fork 7
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
Comments
We're supposed to be using lowerCamelCase everywhere for values and UpperCamelCase everywhere for types. |
It would be good to have explicit named functions for this though, as opposed to us implicitly using |
- 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
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. |
Yeah that's the spirit of this ticket for the It's also a bit brittle on the |
Aha! I see, I thought you were referring to the backend, where it's also true. |
Some examples:
typealias
vs.typeAlias
in urls and other areas where we check decl case?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 somenormalizeX
functions to keep things consistent?The text was updated successfully, but these errors were encountered: