Tab Atkins Jr. wrote:
The APIs for Caches and dealing with responses are designed so that they work nicely together, acting the same way whether you pass a Response or a Promise<Response>. So you can often respond to requests with a simple "e.respondWith(cache.get('foo'))" and it Just Works®.
Nice.
But say you wanted to do something a bit more complicated. For example, if the cache hits, but the result is a Promise, you might want to show a throbber until the Promise resolves. Under the old consensus, you could do this pretty easily - just do "cache.get().chain(...)" and then operate on the result. Under the new, you can't, because the cache promise won't resolve until after the response promise resolves. We can't say "just hand-box", because it breaks the easy pattern above when you*don't* want to do anything complicated - you have to .then() it and unbox there.
Yeah, that would suck for the pretty one-liner. But is it really that much more? Write it out and let's see A vs. B.
There are various ways to work around this. One way is to auto-handbox:
Heh, an oxymoron, like "Military Intelligence". But I know what you mean!
we subclass Promise to CachePromise and hang a .chain() off of it which receives the actual value you stored in the map, while .then() silently unboxes and continues flattening as normal. Another way is to just guarantee that Cache promises never hand promises to their callbacks, and ensure that there are alternate ways to check if a Response is ready yet (maybe just forcing people to more explicitly track the Response promises directly, and make sure they're synced with the stuff in the Cache).
Sure, there are longer ways to go, but they seem to require if-else's or similar. I still would like to see the A-B test.
/be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss