htmx-spring-boot
htmx-spring-boot copied to clipboard
wimdeblauwe
Add missing annotations for response headers
This will add the missing annotations for all available response headers.
Superseded #117.
@tschuehly @wimdeblauwe one thing I have changed now is that @HxPushUrl has true as default, which pushes the fetched URL to the history. The documentation of the header Hx-Push-Url value is incomplete and this is only mentioned in the documentation of the hx-push-url attribute.
@wimdeblauwe I added another commit which introduces dedicated annotations @HxTriggerAfterSettle and @HxTriggerAfterSwap with support for multiple events. Also @HxTrigger now supports multiple events. This replaces the HxTriggerLifecycle in @HxTrigger which is now deprecated and can be removed at a future version.
It also makes it possible to configure triggers for all three lifecycles (directly after response was processed, after settle and after swap) in the same response.
@xhaggi What is the reasoning to deprecate @HxTriggerLifeCycle? Was there a discussion I need to catch up on?
The reason for this is that all the places where it is used are now code paths that should not be used in the future. Or do you think there is a reason to leave it as it is?
Maybe we should deprecate the lifecycle attribute on @HxTrigger itself as well?
@checketts There was no prior discussion about this as far as I know. For me, both the current and the new proposal are fine. But this:
It also makes it possible to configure triggers for all three lifecycles (directly after response was processed, after settle and after swap) in the same response.
Seems like a nice advantage of the separate annotations, so I think it is a good improvement.
Maybe we should deprecate the lifecycle attribute on @HxTrigger itself as well?
Sure and done. I also updated the README where I missed to add the annotations.
I've added another commit with small adjustments to reduce dupe code and make setting an htmx response header type-safe in HtmxHandlerInterceptor.
I'm fine with the deprecation. We had created it to clarify the usage, but I haven't used it myself so making it more flexible is fine by me.