Build better business applications, faster. No more juggling REST endpoints or deciphering GraphQL queries. Hilla seamlessly connects Spring Boot and React to accelerate application development.
Currently, generated endpoints contain a hard-coded paths to the service and the method to be called, as well as a constant Hilla-specific prefix.
Generated endpoints can't currently be called from service workers because of CSRF information needed from the document head (or a cookie), but once the CSRF token is supplied to the service workers, there's nothing preventing the service worker from calling the endpoint method. This just means that the fetch call needs to be built manually, which can be done based on the information found from the generated sources plus the CSRF token. This is prone to breaking if anything changes either in the endpoint methods or in Hilla internals.
Describe the solution you'd like
The simplest approach would be to alter the endpoint generation in a way that the generated modules export the constant values used in there: the service name, the method name, and the clientconnect prefix. This would make any custom code calling the endpoints more stable and changes in the generated artifacts or in Hilla internals would be less likely to break usage.
Describe alternatives you've considered
Most use cases won't need the exported constants, and the generated codebase will be slightly larger than without this feature, so it could be beneficial to make the exports configurable, e.g. with a special annotation like @ExportConstants, an annotation argument in @BrowserCallable like @BrowserCallable(exportConstants = true) or a configuration option in application.properties.
Describe your motivation
Currently, generated endpoints contain a hard-coded paths to the service and the method to be called, as well as a constant Hilla-specific prefix.
Generated endpoints can't currently be called from service workers because of CSRF information needed from the document head (or a cookie), but once the CSRF token is supplied to the service workers, there's nothing preventing the service worker from calling the endpoint method. This just means that the fetch call needs to be built manually, which can be done based on the information found from the generated sources plus the CSRF token. This is prone to breaking if anything changes either in the endpoint methods or in Hilla internals.
Describe the solution you'd like
The simplest approach would be to alter the endpoint generation in a way that the generated modules export the constant values used in there: the service name, the method name, and the clientconnect prefix. This would make any custom code calling the endpoints more stable and changes in the generated artifacts or in Hilla internals would be less likely to break usage.
Describe alternatives you've considered
Most use cases won't need the exported constants, and the generated codebase will be slightly larger than without this feature, so it could be beneficial to make the exports configurable, e.g. with a special annotation like
@ExportConstants, an annotation argument in@BrowserCallablelike@BrowserCallable(exportConstants = true)or a configuration option inapplication.properties.Additional context
No response