Make use of the Cache API?

[aarongustafson]

I’m curious if there are places to make use of the internal Cache API (which I just discovered). @ashmaroli Do you know when that was added?

[miklb]

Last release. I wondered about that too while I was following its development

[aarongustafson]

I tried bumping my site to 3.8.3, but the build failed with undefined class/module Liquid::Token :-/

[ashmaroli]

there are places to make use of the internal Cache API

@aarongustafson Its a Jekyll 4.0 feature.. It has not been released yet. Wonder how I missed that when reviewing the PR for the Jekyll Docs.. :face_with_head_bandage:

[DirtyF]

🤙 /cc @pathawks — as you're the one that implemented the cache API and who can best answer Aaron's legitimate question. 💪

[pathawks]

The cache API is for deterministic functions, which is to say given a particular input s and corresponding output o, 𝑓(s) always outputs the same o.

This means that the cache API would not be a good fit for REST requests where the payload from the network is expected to contain the most recent web mentions at the time of each request, but would be a great fit if there is some boilerplate JS that is generated based on a site's configuration and is not ever expected to change.

Without knowing more about this plugin, it is difficult for me to provide a more comprehensive answer, but I hope that helps. I am happy to answer any questions.

[aarongustafson]

That’s awesome, @pathawks thanks! Will there be an easy way to test for this feature’s availability? Currently we are caching (in our own way) JavaScript just as you are saying. If there are any performance gains to be made by handing it off to Jekyll, we should by all means do it.

I can also see this being very useful for plugins that pull in video from YouTube or code from Github Gists or CodePen.

[pathawks]

I can also see this being very useful for plugins that pull in video from YouTube or code from Github Gists or CodePen.

No doubt!

Will there be an easy way to test for this feature’s availability?

Either by checking for Jekyll > 4 or the existence of Jekyll::Cache

If there are any performance gains to be made by handing it off to Jekyll, we should by all means do it.

If there is any performance to be gained, it will be from Jekyll's cache persisting across builds. As long as a sites configuration does not change, objects will stay cached.

[aarongustafson]

If there is any performance to be gained, it will be from Jekyll’s cache persisting across builds. As long as a sites configuration does not change, objects will stay cached.

Ooooh! I didn’t realized it will persist across builds. That’s rad!

Question: If we use it and, say, need to ship an update to the JS code, will it recognize that the plugin has been updated an automatically purge the cache or will we need to manage that ourselves (maybe by tying into the gem’s version number or something)?

[DirtyF]

I do believe that when the content of the file change, the cache is indeed updated.

[aarongustafson]

I kept having Ruby/Jekyll issues when upgrading my Mac, so I have moved off of Jekyll and will not be working on this project anymore, going forward. I am going to flag this as won’t fix, but leave it open in case someone else wants to pick up the project from here.