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
