Add a turbo:reload event that returns the reason why turbo needed to do a hard reload.

[manuelpuyol]

I feel like we are missing an event fired when the page is going to be hard reloaded. With turbo:reload users will be able to listen to why their Turbo navigations are causing reloads instead of soft-navigation. That will help users track the data and improve their apps.

[dhh]

I like this. @seanpdoyle thoughts on implementation?

[manuelpuyol]

hey @dhh @seanpdoyle 👋
Anything I need to add to get this merged?

[seanpdoyle]

Could you share a use-case that depends on the contents of the event.detail.reason?

I can understand the utility of the turbo:reload event, but I'm curious what types of things more information and context would enable. It's worth mentioning that whatever values we introduce here would be treated as a public API, and we'd be beholden to maintaining those values, regardless of any internal implementation changes or architectural restructuring.

[keithamus]

@seanpdoyle that's a great question. We compute hashes for JS versions, and CSP headers, which we deliver in <meta> tags with data-turbo-track="reload" on. We want to observe when these get triggered so we can measure & potentially react to them. We'd like to differentiate those from from <meta name="turbo-visit-control"> which is far more intentional and would go in a different reporting bucket than changes to CSP headers which invalidate a Turbo request.

[manuelpuyol]

I think that the granularity helps the user understand what is going on with their app. Giving that information to the user will be important so they can react accordingly.

[manuelpuyol]

@seanpdoyle those cases make sense for you?