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

Add SSR support for use_web_notification and use_service_worker #46

Open
1 of 2 tasks
maccesch opened this issue Nov 9, 2023 · 6 comments
Open
1 of 2 tasks

Add SSR support for use_web_notification and use_service_worker #46

maccesch opened this issue Nov 9, 2023 · 6 comments
Labels
good first issue Good for newcomers

Comments

@maccesch
Copy link
Contributor

maccesch commented Nov 9, 2023

  • use_web_notification
  • use_service_worker
@maccesch maccesch added the good first issue Good for newcomers label Nov 9, 2023
@maccesch maccesch self-assigned this Dec 5, 2023
maccesch added a commit that referenced this issue Dec 6, 2023
@maccesch maccesch removed their assignment Dec 6, 2023
@rakshith-ravi
Copy link
Contributor

What do you have in mind for use_service_worker? I could take a stab at it

@maccesch
Copy link
Contributor Author

Nothing really. I have no idea 😂 I'm not sure if it even makes sense to anything on the server for this. But if we can make sure that it doesn't panic on the server that's already better than now.

@rakshith-ravi
Copy link
Contributor

rakshith-ravi commented Aug 29, 2024

Hmmm, how about this:

  • Get the user-agent header
  • If the user-agent header doesn't exist, return the struct that says Service worker is unsupported
  • If it does, check it against https://github.com/kdy1/rust-caniuse to see if service workers are supported
  • If it is supported, check if a /service-worker.js file exists (or is there any other variable to check?) for the file tree
  • If that does exist as well, then it is considered supported. If not, unsupported. Very complex, I know, but since most of this runs on the server side, it shouldn't be too much of an issue.

Also, rust-caniuse embeds the entire data in the library through a build script, which is great for air gapped solutions and reliability, but it would certainly increase compile times significantly.

@maccesch
Copy link
Contributor Author

As far as I understand this, the function is more about installing and using a concrete service worker which has to be done on the frontend anyway.

So I think if we can just make sure that you can run this function without having to put it inside a create_effect would already be enough.

I'm not convinced that all this extra work on the server would be worth it.

Or am I missing something?

@rakshith-ravi
Copy link
Contributor

Hmmm, fair enough. I was thinking of also providing data if the service worker is supported, so that SSR can be rendered differently based on whether it is supported or not, but I think this should work too. What should be returned in the server side in the version you'd mentioned?

@maccesch
Copy link
Contributor Author

maccesch commented Sep 1, 2024

I think this should work:

{
  registration: ServiceWorkerRegistrationError::NeverQueried,
  installing: false,
  waiting: false,
  active: false,
  check_for_update: || (),
  skip_waiting: || (),  
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants