Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: A function that returns true or false if the ICal data is parseable #580

Closed
alishaz-polymath opened this issue Mar 24, 2023 · 2 comments

Comments

@alishaz-polymath
Copy link

Hi there, first of all, amazing product.
I was wondering if here:
https://github.com/kewisch/ical.js/blob/main/lib/ical/parse.js#LL44
We could maybe not break the flow entirely by throwing an error (at least as an opt in).

Here's the scenario where this is a bit of a pain:
In the getAvailability() function in calcom (REF: https://github.com/calcom/cal.com/blob/main/packages/lib/CalendarService.ts#L297)

We go through an array of Calendar Objects and the parse the ICal data one by one. Now, if even one of them fails due to bad ICal body, the function basically just breaks and nothing else works. Essentially, instead of skipping that specific item, it breaks the entire loop and even more (if users have a google calendar for example, which is checked for freebusy data in a different file).

So, perhaps the addition of a function that allows us to know if the ICal data is parseable in the first place, and that doesn't really throw an error but returns true or false, that could be the ideal solution for such cases.

Once again, really appreciate your help here 🙏

@alishaz-polymath alishaz-polymath changed the title Feature request: Can we opt in to the throwing parse failure in poorly constructed ICal Feature request: A function that returns true or false if the ICal data is parseable Mar 24, 2023
@kewisch
Copy link
Owner

kewisch commented Apr 1, 2024

@alishaz-polymath I'm not quite sure I understand, couldn't you just try/catch to find out if it is parseable?

@kewisch kewisch added the needinfo More information has been requested label Apr 1, 2024
@github-actions github-actions bot removed the needinfo More information has been requested label Apr 6, 2024
@alishaz-polymath
Copy link
Author

You're right, that should do it as well, just thought it might make sense to have this functionality built-in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants