I have created a form that allow user to add their ical link. Now I want to read the ics file on that ical link and based on that need to show some information to the user. Can anyone suggest how to do this in wix.
Hey there,
After taking a look I found that there are multiple different ways of parsing iCal, but I felt ical.js by Mozilla was good enough. The ical.js library is pretty complex, letting you work with iCal data like a component, calling different methods to find data, but it can also just return a simple parsed version of the text. Here is the code I came up with:
const rp = require('request-promise');
const ical = require('ical.js');
function flattenEvent(e) {
let event = {};
for(let i=0;i<e[1].length;i++) {
let prop = e[1][i];
event[prop[0]] = prop[3];
//console.log('e',prop);
}
return event;
}
exports.main = (args) => {
return new Promise((resolve, reject) => {
rp(args.url).then((txt) => {
try {
let parsed = ical.parse(txt);
let events = parsed[2];
let result = [];
events.forEach(e => result.push(flattenEvent(e)));
resolve({events:result});
} catch(e) {
console.log(e);
reject(e.message);
}
})
.catch((e) => {
reject(e);
});
});
}
Basically - suck down the remote URL and parse using the library. As I said, there is a nice “object based” API that the library provides, but I found I could work with the initial data a bit easier. You can see where I just grab the third item in the array to get the actual events. I then “flatten” the data using flattenEvent. If your curious, the data is in a form called jCal, which has a specification: draft-ietf-jcardcal-jcal-10. My flattenEventfunction makes some assumptions that may not necessarily always work out well, but so far it’s done ok.
I tested it by asking for Louisiana holidays:
wsk action invoke ical/get --param url
https://raw.githubusercontent.com/gadael/icsdb/master/build/en-US/us-louisiana-nonworkingdays.ics
-r
And here are the top five results.
{
"class": "PUBLIC",
"created": "2014-01-09T00:47:56Z",
"description": "",
"dtend": "1970-01-02",
"dtstamp": "2017-06-23T13:53:48Z",
"dtstart": "1970-01-01",
"last-modified": "2017-06-23T13:53:48Z",
"rrule": {
"freq": "YEARLY"
},
"sequence": 0,
"status": "CONFIRMED",
"summary": "New Year's Day",
"transp": "TRANSPARENT",
"uid": "b901ca08-d924-43c3-9166-1d215c9453d6"
},
{
"class": "PUBLIC",
"created": "2014-01-09T00:47:56Z",
"description": "",
"dtend": "1983-01-02",
"dtstamp": "2017-06-23T13:53:48Z",
"dtstart": "1983-01-01",
"last-modified": "2017-06-23T13:53:48Z",
"rrule": {
"byday": "3MO",
"freq": "YEARLY"
},
"sequence": 0,
"status": "CONFIRMED",
"summary": "Marthin Luther King day/Robert E. Lee day",
"transp": "TRANSPARENT",
"uid": "0ae8128a-e360-492c-b2bd-52ed0d6d06fd"
},
{
"categories": "-New Mexico",
"class": "PUBLIC",
"created": "2014-01-09T00:47:56Z",
"description": "",
"dtend": "1970-02-01",
"dtstamp": "2017-06-23T13:53:48Z",
"dtstart": "1970-02-01",
"last-modified": "2017-06-23T13:53:48Z",
"rrule": {
"byday": "3MO",
"freq": "YEARLY"
},
"sequence": 0,
"status": "CONFIRMED",
"summary": "Presidents Day",
"transp": "TRANSPARENT",
"uid": "17425d41-9ed3-4088-adad-4693d1bd44c9"
},
{
"categories": "Louisiana",
"class": "PUBLIC",
"created": "2014-01-09T00:47:56Z",
"description": "",
"dtend": "1970-04-02",
"dtstamp": "2017-06-23T13:53:48Z",
"dtstart": "1970-04-01",
"last-modified": "2017-06-23T13:53:48Z",
"rdate": "1970-02-10",
"sequence": 0,
"status": "CONFIRMED",
"summary": "Mardi gras",
"transp": "TRANSPARENT",
"uid": "7ac45e93-a684-4061-a0c7-948a89e358b0"
},
{
"categories": "Connecticut",
"class": "PUBLIC",
"created": "2014-01-09T00:47:56Z",
"description": "",
"dtend": "1970-04-09",
"dtstamp": "2017-06-23T13:53:48Z",
"dtstart": "1970-04-08",
"last-modified": "2017-06-23T13:53:48Z",
"rdate": "1970-03-26",
"sequence": 0,
"status": "CONFIRMED",
"summary": "Good Friday",
"transp": "TRANSPARENT",
"uid": "3c46243f-00f8-418f-94cf-4eda72ae7cb2"
}
So… that’s some data. Cool. What would I do next? When I first started thinking about this data, my first thought is that it could be a useful API for web apps. I’m a web developer so everythinglooks like a web-related source for me. Of course, why would I need serverless for that? I could run the iCal library in the browser - the only issue I’d run into is CORS - maybe. And I could always copy the iCal files to the same server as the app. But that’s really limited thinking.
By creating this as a serverless action, I’ve opened it up to any event source, web or not. How about an example of something completely non-web based?
Imagine a support service where every day, my process gets a list of employees responsible for IT work in case of emergencies. I could imagine a process by which after getting a list of employees, I could check each one’s home state against a list of holidays for that state and determine if that person is off today. It’s the exact same code, but I’m simply using it in a different context.
And this is something important to keep in mind here. Serverless isn’t just about building NodeJS apps simpler. Instead I’m creating a resource that can be used in multiple situations, both direct (web app making a request) and indirect (a process run on a timed schedule)
Hope it helps, pretty easy actually let me know if you need any help
so by using ical.js I can directly parse ics file on Wix or do i still need to create API to use it?