Uppercase handler names (`export function GET() {...}` etc)
See original GitHub issueDescribe the problem
Details in this discussion. Consensus seems to be that this is a positive change.
Describe the proposed solution
Replace this…
// src/routes/some-endpoint.js
export function get({ params }) {...}
export function del({ params, request }) {...}
…with this:
// src/routes/some-endpoint.js
export function GET({ params }) {...}
export function DELETE({ params, request }) {...}
Alternatives considered
Not doing this.
Importance
nice to have
Additional Information
No response
Issue Analytics
- State:
- Created a year ago
- Reactions:17
- Comments:7 (5 by maintainers)
Top Results From Across the Web
Error in importing custom packages in Go Lang - Stack Overflow
you would need to make your function exportable with an uppercase for its name: func Fastget(... Used as: n:=libfastget.
Read more >Understanding Package Visibility in Go - DigitalOcean
In this package, there are two exported functions: Debug and Log . These functions can be called by any other package that imports...
Read more >Salesforce Naming Conventions Best Practices - Apex Hours
Naming convention in Salesforce is a rule to follow as you decide what to name your identifiers like class, variable, constant, method, etc....
Read more >Develop custom plugins | Apigee Edge | Apigee Docs
The exported plugin functions in <microgateway-root-dir>/plugins/plugin-1/index.js are event handlers that execute at specific times during request and response ...
Read more >Effective Go - The Go Programming Language
Constants: Variables: The init function; Methods: Pointers vs. ... The use of upper-case names for export provides the hook to discriminate the field...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
No, that’s a bad idea. APIs should be as explicit and non-magical as possible — loosey-goosey things like accepting
get
orGET
orGet
orgEt
create confusing documentation and pointless debates over best practiceGitHub permissions are highly mysterious. I’ve just marked that PR as draft, but for the record, I am in favor of this change.