3 ms·

Sounds very cool. Not impressed with the cross platform claim when the first thing I see is that android web is not supported, though.

schickling 1y ago
That's a good point. I'm in touch with the Android/Chrome team about the underlying issue. I was hoping the underlying Android web issue would have been fixed by now (as I first noticed it ~3 years ago with some indication for progress), but looks like LiveStore needs a custom workaround for it. You can track the progress here: https://github.com/livestorejs/livestore/issues/321 https://github.com/livestorejs/livestore/issues/321 I hope you understand that bridging the gaps between various levels of supported web APIs take a lot of effort and is non-trivial when building ambitious systems like LiveStore.
- wlib 1y ago
  I’ve been working on a very similar sync problem and hit this too. I think the way forward is to use a broadcast channel to elect an individual worker that communicates with all other contexts using the broadcast channel.
  - dugmartin 1y ago
    fyi, I've done something similar and the cleanest method for leader election is to use the web locks api: https://developer.mozilla.org/en-US/docs/Web/API/Web_Locks_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Locks_A... It is supported by all browsers. You just have all the tabs try to lock the same resource and have them return a promise in the lock callback. The first one wins and when that tab closes the next one in line gets automatically elected. The leader can then use a broadcast channel and act as a server for all the other tabs to serialize access to any shared resources.
    - wlib 1y ago
      That’s very elegant, thanks!
- growthwtf 1y ago
  Very interesting context. Thank you for sharing.
- autoconfig 1y ago
  It’s beyond shameful that chrome on android doesn’t support shared workers yet. We decided to simply nix multi tab support on android because of it.

schickling 1y ago

That's a good point. I'm in touch with the Android/Chrome team about the underlying issue. I was hoping the underlying Android web issue would have been fixed by now (as I first noticed it ~3 years ago with some indication for progress), but looks like LiveStore needs a custom workaround for it. You can track the progress here: https://github.com/livestorejs/livestore/issues/321 https://github.com/livestorejs/livestore/issues/321 I hope you understand that bridging the gaps between various levels of supported web APIs take a lot of effort and is non-trivial when building ambitious systems like LiveStore.

wlib 1y ago
I’ve been working on a very similar sync problem and hit this too. I think the way forward is to use a broadcast channel to elect an individual worker that communicates with all other contexts using the broadcast channel.
- dugmartin 1y ago
  fyi, I've done something similar and the cleanest method for leader election is to use the web locks api: https://developer.mozilla.org/en-US/docs/Web/API/Web_Locks_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Locks_A... It is supported by all browsers. You just have all the tabs try to lock the same resource and have them return a promise in the lock callback. The first one wins and when that tab closes the next one in line gets automatically elected. The leader can then use a broadcast channel and act as a server for all the other tabs to serialize access to any shared resources.
  - wlib 1y ago
    That’s very elegant, thanks!
growthwtf 1y ago
Very interesting context. Thank you for sharing.
autoconfig 1y ago
It’s beyond shameful that chrome on android doesn’t support shared workers yet. We decided to simply nix multi tab support on android because of it.