Open elvarb opened 1 week ago
There are ways to prevent multiple calls to an API, you could use the disabled
flag and assign a req-id
to save the response and not call the API again, unless you remove the disabled
flag. It is not the most practical or intuitive, but it is an option.
Some time ago I was thinking about adding the Recall
button, but I didn't do it because the current code is a complete mess. Everything is mixed up and there are no defined functions. I need to organize everything to be able to add something like this
Maybe for the moment, the first option is more feasible, to add a flag like rep-req-after: X
or something like that.
Totally understand, this can be a backlog enhancement for later.
Regarding the option of using racall. Would that work if I had many files which include the api request codeblock from a templater template, meaning they all use the same codeblock. If one sends out a requests and sets a req-id, wouldn't the same req-id be used when viewing the next file?
Regarding the option of using racall.
Do you mean using the actual mode (disabled
with req-id
) or the "new mode" (that is not yet implemented) rep-req-after: X
?
Ether way, the actual mode use localStorage
so responses can be access from every file that has the same req-id
(the disabled
is just to prevent new calls to the endpoint). I would imagine the new mode would reuse the same idea. The response would be stored in localStorage
and would be reusable from any code-block (from any document) with the same req-id
.
Totally understand, this can be a backlog enhancement for later.
I had try to clean up the code so many times but I always end up overwhelm haha. One day tho; for sure.
Do you mean using the actual mode (disabled with req-id) or the "new mode" (that is not yet implemented) rep-req-after: X?
I mean using the "new mode" and the way you describe it I think that way could potentially solve some use cases but not all.
If you have the same code block in different documents but you don't want the response of one document to be the same for all of them you can use different ids.
Something that could be implemented would be an option to add or remove the "Run" button in the code-blocks. If the button is enabled run the request only the first time it is defined and every time the user presses the button. If it is disabled, run the requests every time the document is reloaded (the way they run right now).
Good points, is it possible to use the file name or some other file property to define the id ?
Perhaps we can use the name as id, filename+path
to prevent repeated names.
Having that option would be great, that would open the option of limiting the queries by file and by the api 👍
I don't know if that would make a good ID, because we can have multiple code-blocks within a single file.
Is your feature request related to a problem? Please describe. Many API's are rate limited by tier or cost each time it is used. The plugin sends a request out to the API each time the page is loaded regardless if there is need to update the data itself.
Describe the solution you'd like Few options that would work to limit repeat calls.
Offer a setting that will automatically call the API if N amount of time has passed since the last call. This would require storing the last request time in some way, could be done with a custom defined property within the code block. If there is nothing in the file property for that custom name then call the api. If a datetime is stored there compare the time difference between than and now, evaluate as stated in the codeblock. The Period could be defined in the codeblock as is in ISO8601 (https://en.wikipedia.org/wiki/ISO_8601#Durations)
Offer a setting to be used in the code block that will present a button in Obsidian labeled "Refresh", or "Recall", or better yet have the text customizable. Offering the same custom defined property in the code block as above to store when the API was last called could be helpful as it can be used to present to the user how old the data is.
I think the second option would probably be simpler to implement and be good enough for most use cases.
Describe alternatives you've considered Only alternative solution I can think of is running a reverse proxy locally with lots of caching to prevent repeated api requests (I have done this in the past for a different use case)