Closed Bug 1165860 Opened 9 years ago Closed 9 years ago

[ServiceWorkers] We need a more seamless way of falling through the route rather than forcing middleware developers to add the "work-only-if-no-response-yet" code pattern at the beginning of its code

Categories

(Firefox OS Graveyard :: Gaia, defect)

defect
Not set
normal

Tracking

(b2g-master fixed)

RESOLVED FIXED
NGA S2 (12Jun)
Tracking Status
b2g-master --- fixed

People

(Reporter: arcturus, Assigned: salva)

References

Details

(Whiteboard: [s3])

Attachments

(1 file)

      No description provided.
Whiteboard: [s2]
Get to a consensus on how we want to do this and implement this :)
Summary: [serviworkers] We need a more seamless way of falling through the route rather than forcing middleware developers to add the "work-only-if-no-response-yet" code pattern at the beginning of its code. → [serviceworkers] We need a more seamless way of falling through the route rather than forcing middleware developers to add the "work-only-if-no-response-yet" code pattern at the beginning of its code.
Summary: [serviceworkers] We need a more seamless way of falling through the route rather than forcing middleware developers to add the "work-only-if-no-response-yet" code pattern at the beginning of its code. → [ServiceWorkers] We need a more seamless way of falling through the route rather than forcing middleware developers to add the "work-only-if-no-response-yet" code pattern at the beginning of its code
Assignee: nobody → salva
Status: NEW → ASSIGNED
Whiteboard: [s2] → [s3]
Target Milestone: --- → NGA S2 (12Jun)
Hi Francisco. Long but fully tested and working. Can you review, please?
Attachment #8615166 - Flags: review?(francisco)
Notice I stop to clone request and responses. I prefer the user to crash rather than perform unneeded operations if goals for SWW are "lean and fast".
Comment on attachment 8615166 [details] [review]
Implement the new onFetch() workflow and API for middlewares

Just left some comments, tiny ones, but this work looks amazing :)

Amazing that we keep the compatibility and have the new mechanism. We should think in the future if we remove the compatibility, but so far looks like a win.

Thanks a lot for the fantastic work!
Attachment #8615166 - Flags: review?(francisco) → review+
Comment on attachment 8615166 [details] [review]
Implement the new onFetch() workflow and API for middlewares

I've updated the specification and implementation in separated commits. Can you double-check the implementation, please?
Attachment #8615166 - Flags: review+ → review?(francisco)
I added three commits more about warning the developer about errors in the middleware pipeline. Problem is that according with the specification [1], if `.respondWith()` is passed with a rejecting promise or a promise resolving in a thing different than a Response instance, the client's fetch will fail with network error. I would want to give an opportunity for the developer to see the error in the console as well.

[1] http://www.w3.org/TR/service-workers/#respond-with-method
Comment on attachment 8615166 [details] [review]
Implement the new onFetch() workflow and API for middlewares

Excellent job, everything pretty clear and well documented.

I really like the flexibility but everything is looking quite consistent.

Just one thing before merging, we should bump the version both for npm package and bower to 0.1.0, wdyt?
Attachment #8615166 - Flags: review?(francisco) → review+
master: f31ce642b4b68307602c4b8f1cbb3d0a1465c07b
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: