filter without refetch?

[JohnRDOrazio]

Perhaps filtering can be applied on the fetched data, without refetching, to avoid unnecessary requests to the API? The data from the API is not changing when applying filters, so it shouldn't really be necessary to fetch the data again. Fetched data could be stored either in local storage, or even in a Javascript static class member, and filters could then be added / removed even after the data is fetched, without making another network request.

Seeing that this is written in Javascript, perhaps it could be useful to implement similar functionality in the https://github.com/Liturgical-Calendar/liturgy-components-js package, perhaps as a component of it's own.

[HPaulson]

Father, thanks for the issue!

A couple of notes. This repo is intended firstly as an API wrapper. I did build a sandbox frontend, but this is entirely second. The only goal of the frontend is for example queries to be built for the wrapper and for someone to easily see what the filter syntax looks like without playing around in Postman. Because of this, I can't exactly fetch from the LitCal API once and then do filters client-side, because the filtering system is entirely backend.

I could make a client-side implementation of the filters (It's a JS class, after all). This would mean the frontend sandbox does not rely at all on the API Wrapper in the data it displays. This wouldn't be useful, though, unless somewhere were using the frontend for some unintended purpose (See above). Since my use case is a filtered iCal subscription, which requires backend filtering, the filtering system must be backend in a wrapper, and not in client-side code.

I could implement caching in the backend, however, which would make the wrapper more efficient and rely less on the main LitCal API Instance. I'm unsure how desirable that is in such a small project, but I could be pursued (especially if it's pressuring the main API, which I do not intend. I doubt this though since I don't expect anyone to use this wrapper besides the iCal use case, which would call the main API an equal amount).

Regarding component implementation - this could again be done since the filtering system is just a JS class, so I'd be willing to work on that if you desire it. Though it doesn't serve my purpose, I could see it being useful to others. If this is desirable for you, let me know, and I'll get on it!