Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sessionDidFinishRequest replacement #67

Open
lqrs opened this issue Dec 26, 2024 · 3 comments
Open

sessionDidFinishRequest replacement #67

lqrs opened this issue Dec 26, 2024 · 3 comments

Comments

@lqrs
Copy link

lqrs commented Dec 26, 2024

I have been using Turbo in the past, and I am migrating to Hotwire Native. One thing I can't seem to find is an equivalent alternative to sessionDidFinishRequest for some post-processing logic after a page loads.

My current workaround is to fork this repo and add a requestDidFinish to NavigatorDelegate (lqrs@68b0fdb). Ideally, this should be provided by upstream so I don't have to maintain a separate fork.

May I know if I overlooked anything and if there is a recommended approach to this? I am also happy to open a pull request with my changes.

@joemasilotti
Copy link
Member

It might help to get context on what you’re trying to do. What does your post-processing logic do?

@lqrs
Copy link
Author

lqrs commented Dec 27, 2024

@joemasilotti thanks for replying. Yes, in addition to web logic, we also have native logic that is triggered upon a page request finishes. The native logic consists of login status tracking, push notification permission requests, submitting device tokens using an HTTP client, and more.

We like the concept of Turbo/Hotwire and pioneered using the Turbo framework and liked it. We want to transit to depend on Hotwire. However, the Turbo framework supports these out of the box, and lacking such support in Hotwire is quite a bit inconvenient.

@joemasilotti
Copy link
Member

Just to keep kicking this can…

login status tracking, push notification permission requests, submitting device tokens using an HTTP client

A bridge component would work just as well for each of those. And it keeps more logic on the server - you won't need to track if the user is signed in (or not) in the app at all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants