Closed tarsius closed 5 years ago
I will think on this. If caching should be done at the ghubp-request level, then it should probably exist within ghub+ itself. I'd like to keep ghub+ as general-use as possible (though I wouldn't immediately expect it to be used by other packages at this stage of the game, even as relatively stable as it is) and this seems contraindicated by the need for a magit-specific caching solution.
Although… You can tell I'm tired… this is not how that variable works 😄 but something similar could easily be written.ghubp-request-override-function
exists. It was originally created to effect reliable unit testing, however that would be a good approach to this as well. Every ghub request should already be wrapped in the magithub-request
macro – perhaps this macro can be expanded upon into come magithub-cached-request
that uses the functionality you've outlined here.
I probably won't be able to act on this until the weekend, but thanks for your notes; they're always appreciated 😄
It's probably not worth doing this anymore.
You might want to use
magit--refresh-cache
instead of rolling your ownmagithub-cache--refreshed-forms
.Note however how in this case cache lookup is done shortly before the value would be calculated by other means, while your cache has to be explicitly used by every caller. I think Magit's approach is superior, but it could be rather difficult to change your code to do it like that because you work a lot with wrappers such as
magithub-request
andmagithub-unpaginate
. The right place to implement this in my opinion would be inghubp-request
. Somethink like (untested):