You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The syntax for template names is kind of like a single method interface.
The method parameter types are based on known identifiers.
The method signature itself can be a call on an interface but instead of methods on an interface, we can generate calls to functions that return a method.
The returned function could be expected to match the method signature.
Given a template has name `GET / F() as Index`
When `must generate` is executed
Then a function with signature `func Index() http.HandlerFunc` should be generated
And it instead of using a function literal the `routes` function should invoke `mux.HandleFunc` like so: `mux.HandleFunc("GET /", Index())`
Many Gophers (myself included) often prefer to write higher order functions for handlers instead of methods (see https://changelog.com/gotime/322). So we should support that.
I suspect a decent experience would be to have the handler method invoked in the generated http.HandlerFunc refer to the higher order function name. The first order parameters should be sorted by name and added to the routes function and the result signature should be invoked like we invoke receivers. This behavior effectively adds dependency injection for better ∨ worse.
I might want to call Welcome once outside of the call scope. This would be adding logic to the routes function (currently it only registers routes). This would then allow each handler to do its setup once before returning the method.
crhntr
changed the title
Allow template Names to specify a function name
Support higher order functions instead of receivers
Aug 30, 2024
The syntax for template names is kind of like a single method interface.
The method parameter types are based on known identifiers.
The method signature itself can be a call on an interface but instead of methods on an interface, we can generate calls to functions that return a method.
The returned function could be expected to match the method signature.
Many Gophers (myself included) often prefer to write higher order functions for handlers instead of methods (see https://changelog.com/gotime/322). So we should support that.
I suspect a decent experience would be to have the handler method invoked in the generated
http.HandlerFunc
refer to the higher order function name. The first order parameters should be sorted by name and added to the routes function and the result signature should be invoked like we invoke receivers. This behavior effectively adds dependency injection for better ∨ worse.So given a go and template source files:
Then the generated routes function should be:
The text was updated successfully, but these errors were encountered: