-
Notifications
You must be signed in to change notification settings - Fork 412
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Major: Rework exports; Add throttle
and limit
options
#120
Conversation
- add `throttle` option - add `limit` option - export `prefetch` directly - export old `default` as `listen` method - remove `urls` option (temp?) - return early if no IO support - return `reset` function if okay
timeout: options.timeout || 2e3 | ||
}); | ||
|
||
return function () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is good for SPA environments, where listen
is initially called on a parent container and then any page/route-change can dump the contents of what was relevant to the previous page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
I agree with the rationale for removal, but do have some questions. If we drop the const urls = ['1.html', '2.html'];
const promises = urls.map(url => Quicklink.prefetch(url));
Promise.all(promises); I would be supportive of dropping |
Thank you for working on these changes, @lukeed!
A shift to working against the same cache list was a good call. I'm also glad to hear you discovered a set of changes to improve code reuse when we've finally bundled Quicklink.
No worries. I'm happy to treat this PR as the next major release candidate once we are further along in the reviews. Given the breaking changes in the API surface, we should probably consider this Quicklink 2.0.0. Top of mind is making sure there's feature parity in this new version. Looking forward to the tests :) |
*/ | ||
export default function (options) { | ||
export function listen(options) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you talk a little about the thought process of switching from a default to using listen
? In practice, I think most users are likely to copy/paste the default code snippet we provide (and so I don't view this as a huge ergonomics change), but would be good to walk through reasoning :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe there's not as much consensus as I think there is, but I think have mixed imports vs default-only and/or named-only is the trickiest of the three. So, for me it basically comes down to convention/simplicity. It's certainly not impossible to have mixed exports.
However, for UMD and CJS users, it does mean you have to call "listen" function via quicklink.default()
* @param {Object} [conn] - navigator.connection (internal) | ||
* @return {Object} a Promise | ||
*/ | ||
export function prefetch(url, isPriority, conn) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 to exposing prefetch
like this.
I am excited about is us enabling Quicklink to be viewed as both a library with a heuristic for prefetching but also as just a generally good prefetcher. I believe hiding prefetch.mjs behind our abstraction likely led to users thinking you had to use our heuristic to take advantage of any of the prefetching behavior at all, which isn't the case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very enthusiastic about the changes here so far. Left some comments along the way :)
I was envisioning the a |
Pushed up some changes, including a look at having Once we have the changelist ironed out, I think I'll wrap this up with a set of test & doc updates. These are the updated build stats:
|
Thank you, @lukeed! |
Catching up on the latest discussions, I believe we now have quorum? :) Thanks again. If there's anything design-wise you're waiting on further input for please feel free to reach out anytime. I think moving on to tests and docs (whenever you have time) should feel unblocked. |
Hey hey, here are final build stats
Not sure how to test throttle – not familiar enough with all puppeteer APIs. Follow up with docs in the morning~ |
Thanks for working through these changes, @lukeed! Tests LGTM so far. |
Hey, sorry for the delay on this one 🙈 Good news is that I figured how to test the throttling~! Let me know if you need anything to be changed. Now that the bulk of the work is out of the way, anything else should be much quicker, even with my current forever-catchup schedule. |
Hey @addyosmani, I reformatted the README in a way that reads easier to my eyes – I felt like the They are here (lukeed#1 – rendered). If you like them, I'll merge that PR which will update this guy. |
Rendered README LGTM. Thanks for reworking it, Luke! Just read through. |
Cool! Merged the README changes |
Thank you, Luke! As far as I'm concerned, reviewing through the full set of changes I think this is in a good place to land it in master 🚢 I'm thinking that we do this, tag the release as an alpha and invite developers to try out the new API. We can then rework the upcoming site for the project to account for API changes and launch the new major version + site + updated demos at the same time. Sound reasonable? |
Yup, sounds good! Thanks for all the continuous feedback |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Sorry for the big diff; I was zoning & not really paying attention to git.
TLDR:
limit
option – total allowed requests (Option to limit the maximum number of prefetched requests #4)throttle
option – max concurrency control viathrottles
(Option to limit the maximum number of prefetched requests #4 (comment))urls
option (temp?)prefetch
method directlydefault
aslisten
methodlisten
early if no IO supportlisten
listen
returns areset
/ unlisten functionCode Size
Notes:
I realized we were using the
toPrefetch
set somewhat incorrectly. We did a bunch of work to figure out if we should "queue" the link'shref
value, and then, once the link was intersecting, we did more work to see if thelink.href
was approved, and then finally did more work to clear the queue.That's a lot of work.
Instead, it was much simpler to do the first set of work to see if we should observe the
link
in the first place! Then anything else the IO is processing is already okay'd for processing.This leaves the
toPrefetch
set as a track record of what has been called, which is identical to what this makeshift cache was doing, too.Thirdly, these individually-operating caches were individually operating, which means that when you were brave enough to venture into
quicklink/src/prefetch.mjs
, you were prefetching things that (a) may have already been prefetched; and/or (b) prefetching things that your IO won't ever know about.The best way to solve this was to get everything in the same file and operating on the same cache list. It also allows for easy access to the
prefetch
function w/o manually traversing the module contents #98 (comment) which actually prevented code reuse too (quicklink was bundled, but reached back in for another copy of source code).Finally, I removed the
urls
option because of the easily accessibleprefetch
export. It feels redundant and very out of place now that the "Go get this" and the "Please listen to that" behaviors have been separated. Of course, I can revert this if it should be kept.TODOs
Closes #4
Closes #79
Closes #118
Unblocks #98