feat: use org name in header

[zugdev]

Resolves #141

This pulls from #140 so merge it first.

Check the video:

org-label.mp4

Also am not sure if we should keep DEVPOOL always? Lmk

[ubiquity-os-deployer]

7faad19

30d7066

c459465

363dcd7

c4d5b58

[0x4007]

Async this instead

[zugdev]

like this? self.addEventListener("install", async (event) => { not sure why though

[0x4007]

Resolves #141

This pulls from #140 so merge it first.

Check the video:

org-label.mp4

Also am not sure if we should keep DEVPOOL always? Lmk

I'm not sure either so let's leave it for now and change later if we need to.

We have the domain name devpool.directory/ubiquity etc so it makes sense to still reference it.

It would be interesting to

1. Have orgs cname the domain to "host" on their own domains
2. Dynamically generate the color theme based on their org avatar but seems difficult hard to do well, and isn't a priority so I think we can't fund that research.

[zugdev]

It would be interesting to

1. Have orgs cname the domain to "host" on their own domains

I have that in mind, yes.

2. Dynamically generate the color theme based on their org avatar but seems difficult hard to do well, and isn't a priority so I think we can't fund that research.

This is very cool and is not that hard tbh. We could create an issue with low priority and re-label it when the right time comes.

[0x4007]

It's strange that you do self invoking functions to do async. Just wrap the entire callback inside an async function like we discussed here and then you can await them like normal.

Also change catch to try catch. And don't use thenable, use async await.

[zugdev]

The self invoking functions are needed because event's waitUntil() method receives a promise as a parameter - not a function that returns a promise, (see reference). I can only imagine that your idea was to remore the use of waitUntil entirely, for instance:

// Install event (caches all necessary files)
self.addEventListener("install", async (event) => {
  try {
    const cache = await caches.open(cacheName);
    await cache.addAll(urlsToCache);
    console.log("[Service Worker] Files cached successfully");
  } catch (error) {
    console.error("[Service Worker] Cache failed:", error);
  }
  self.skipWaiting(); // Activate the new worker immediately
});

instead of:

// Install event (caches all necessary files)
self.addEventListener("install", async (event) => {
  event.waitUntil(
    (async () => {
      try {
        const cache = await caches.open(cacheName);
        await cache.addAll(urlsToCache);
        console.log("[Service Worker] Files cached successfully");
      } catch (error) {
        console.error("[Service Worker] Cache failed:", error);
      }
      self.skipWaiting(); // Activate the new worker immediately
    })()
  );
});

The difference between these approaches is that with waitUntil() adding assets to cache becomes an asynchronous task, which would allow the task to be completed even after returning inside the event handler. During install this is not a problem, however in a fetch event I want the service worker to return whatever is in cache, but fire an asynchronous task to update the cache with a network response. If we remove waitUntil() and just await the network response, we would have to wait for network response to return whatever is in cache, seriously compromising speed in very slow networks.

Here is a QA using waitUntil() to return from cache and asynchronously update cache with network response, in a simulated 10kbps network speed:

10kbps-network.webm

Here is a QA awaiting the network response, in a simulated 10kbps network speed:

10kbps-network-await.webm

Here are some additional references to clarify:

What does event.waitUntil do in service worker and why is it needed?

JavaScript how to use event.waitUntil() to wait for an async function call

Should I use event.waitUntil() or await fetch() or just fetch()?

[0x4007]

Okay seems like you did your research so let's do what you think is right.

[zugdev]

That was good feedback, it's very important that we understand each others code practices, as well as document weird patterns. Thanks.

[zugdev]

Can we merge #140 and then this one (#143)?

[0x4007]

Can we merge #140 and then this one (#143)?

I don't think order should matter git is supposed to handle this