Hey all!
We have an app that we have built using Meteor/Svelte and all is working really realy well! Our app currently allows logged-in administrator/manager users to schedule and duplicate appointments; however, we have received many requests to add a function that would allow users to schedule the same appointment to recur weekly, monthly, quarterly, and annually.
This seemed like it would be a fairly simple update, but of course, I then began to really think about it and realized there are several pit-falls in my original plan. One is that it would essentially schedule these appointments out into infinite 
I was hoping that someone in the AWESOME Meteor community had run into this already, and might have some tips on how we might overcome it. I don’t think that using a 3rd party API such as Google Calendar etc will work for our customer base…but I am sure there is a reasonable solution to this. 
We have a school App where we set recurring timetables and school can set recurring events. We take input as start and end dates and recurrence. Then we calculate the recurrence dates using moment recur and show it. We do not allow infinite end date. For calendar we use fullcalendar to display.
2 Likes
@perumalkuk Thanks for the reply! One issue I am seeing with this is, do you allow people to see/change appointment details for future dates? If yes, and there is technically no DB entry for it…how are you handling this? Our app is an inspection app, and each inspection could have anywhere from 1 - 1000 different inspection sections and questions (each with its own DB entry that cross-references the inspection)…trying to think through a good solution for this. One idea was to simply generate the details/dependencies on the fly when they click into the inspection. Curious about your solution!
We do allow changing of dates at any time and recurrence at any time, for us it is just one record change. We do not have actions against the calendar entry so we do not need to store recurrence, but generate it on fly and show only for max four months. even if an action is there it should not be difficult as that will be independent of the calendar entry.
I think you can easily extend our solution, a bit of programming will be required. Technically you can store the derived/recurrence record, change it if master is changed and maybe have a logic to not disturb past records. of course a logic check if master or derived record is being changed will also need to be done.
1 Like
Yeah I like your idea of master and your thinking is also pretty much in line with our in regards to our thoughts on how to handle all of this data…lol crazy how complicated this really could get without a lot of forethought!
Ah, RRule… I think it was my first open-source contribution, almost 6 years ago - vazco:universe-autoform-scheduler (it’s definitely outdated!). All I can say about RRule is that it’s hard for users to understand. From my experience, most cases (definitely more than 90%) can be handled with a small subset of RRule: every day/week/month/day-of-month + ends at/after-N-occurrences. This can simplify your UI drastically.
However, a big problem with RRule is that you cannot query for occurrences in a given date range. Well, technically… You definitely shouldn’t do it. A common practice is to either reify (calculate and store) first N occurrences as a subfield or in a separate collection. Think of it like a cache-like approach.
When you additionally need an option to edit only one occurrence, then I saw two approaches:
- Split the repeating event into three: before that date, after that date, and this very one (not repeatable). This means you can no longer edit all of them in an easy way.
- Store all “overrides” separately, e.g. date and the differences. This approach is usually better, but may lead to a lot of duplicated data.
Additionally, in all cases, you have to remember to update these “cached” instances as well. Yep, recurring occurrences are hard. And let me stop before we get into timezones…
1 Like
I am glad I am not the only one that set forth to do this, and was a little intimidated by all that I found on my way down the rabbit hole!