How to synchronously test route matches?

[bever1337]

In a service worker environment, it is required to synchronously decide to respond to a fetch event. What is the recommendation when an itty router may not always respond to a fetch event? Because of the getter, I'm not sure how to safely hack on the router and manually test matches. Thankfully the source code could fit on an index card so I'm not afraid to fork. Thanks for the awesome lib.

[bever1337]

I made this fork as a first attempt at this task: https://github.com/bever1337/itty-worker-router

Instead of testing if any handlers MIGHT match, this fork uses a greedy router. Any returned value from a handler is considered a match. This is a small but also huge design change from the current itty so I'm interested to hear what folks think. Is there a way to bring some sync testing to itty without completely changing its design?

Thanks!

[kwhitley]

For instance, in itty-router-extras, I export a ThrowableRouter that intercepts errors in handlers and adds a catch automatically and such, but that's wrapping additional logic on top of itty, rather than fundamentally changing the internals (which is more easily accomplished by options/config to direct internal logic, but at the expense of many precious bytes)

[bever1337]

does it matter if the onFetch returns a promise ultimately resolving to undefined vs just returning undefined synchronously?

Unfortunately yes, the resolved value must be a response! If the promise passed to respondWith resolves to undefined (or anything besides Response) then the browser throws a network error on the original fetch request.

I didn't realize service workers were so picky until I started this project. In the past I had only handled standard asset caching behavior. It's a ride.

Out of curiosity, why would you prefer a fixed-method, non-Proxy approach? Is it a performance thing?

Actually I've got very little in the way of preferences! I defer to your itty best practices 😄 If you believe that a build step to create a new export is appropriate, then I am really grateful for y'all to support a sync handle. (Notice the space between "a" and "sync"- ha!) If it were a separate file, it'd have no impact on a "tree shaken" bundle, so that is a convenient approach. That's not even a major version change 😎

[bever1337]

I'm not familiar with the itty toolchain, but I'm sure I could come up to speed if y'all require a contribution. I would also be glad to contribute an updated README for the changes. In #106 I mentioned how it could be neat if each environment example also showed a different feature of itty. For example, if a sync router were created, a service worker example would be appropriate.

[bever1337]

Also howdy, I know I'm just a random internet stranger suddenly very interested in y'all's project. I really appreciate your time and consideration to this request 🙏

[bever1337]

I think this is what the build approach looks like. Note that by removing async and await, the router actually fails three tests. Two are because .catch() is unable to catch an error so the test itself throws. Wrapping those in try/catch blocks successfully finishes the test for a sync handler. Another test fails because now undefined (not Promise<undefined>) can be returned.

https://github.com/bever1337/itty-worker-router/pull/2/files