Another Javascript Event Calendar?...

Connor Tangney — Tue, 01 Oct 2019 13:28:40 +0000

Yes. Another Javascript event calendar.

"But Couch3ater... Why?! There are hundreds, if not thousands, readily available for you to use on the internet!"

You're right. There sure are. That said, there are a couple reasons I decided that I wanted to go ahead and make yet another:

A lot of the event calendars that support the features I am looking for come with some sort of pay-to-play model, offering a few of the features for free while only offering the "premium" features after paying a one-time or subscription fee. I can't stand these types of "Freemium" models.
Many of the free event calendars that do offer all the features I am looking for do not support the ability to apply custom themes, or even make basic color changes. Not altogether useful when I'm trying to drop a free component into a white-label website!

Rationality aside, let's just jump into it. As with any problem that I am aim to solve, I try to break things down into their core elements. At its most basic, an event calendar really only needs a few things to work and look good (at least in this implementation 😅):

Data.
A list view.
A details view.

Let's start with the data.

At the end of the day, unless you connect your calendar to some data, it's not really going to be that useful. In my case, this calendar is likely going to be communicating with a JSON document store, so for the sake of example, I will just have a smattering of event data stored in an array.

const _EVENTS = [
  {
    id: 1,
    name: 'PARK EVENT 1',
    date: '2019/10/20',
    desc: 'Short description of the event here. Displays on event LISTING.',
    info: 'Longer, more verbose description of the event. Displays on event MODAL in the content body.',
    type: 'park',
    img: 'https://placehold.it/150x150'
  },
  ...
]

For the sake of brevity, I have only included one event object, but that should be enough to give you a good idea of how I have structured my data. I am on the fence about adding an additional field labeled "thumbnail" that would allow users to upload a separate image to be used as the thumbnail for the event listing. Right now, the "img" field is used as both the listing thumbnail and the modal header. Luckily, where I've spun this up myself, changing this is easily accomplished 😁

Now on to the looks.

With a rough layout for my data hammered down, it was time to move onto the more exciting part -- designing the actual calendar! As someone who has used event calendars in the past, I have formed some opinions on what I like to see from them, namely that I hate the standard "calendar" view. Nowadays, when I see a calendar interface, my mind immediately defaults to "Oh, this is a DatePicker," and I find myself trying to select a range of dates. This is just my personal experience, but I'd be lying if I said it didn't impact my design choice. After all, you're looking at a list view layout, now aren't you?

It was necessary to also inlude a secondary view for the calendar in order to display the expanded details about the event. For this, I just went with a pretty simple modal that opens when a user selects the Learn More button. Through some black-magic trickery (also read: regex), information from the event data is pulled from the array by index...

  const target = event.target;

  let eventId = target.closest('section.event-listing');
  eventId = eventId.getAttribute('data-event-id')
  eventId = eventId.match(/\d+/g)[0];

  const eventListing = _EVENTS[eventId - 1];

Then dumped into the modal. You'll notice I'm subtracting one from my eventId value. This is because my ID's are not zero-indexed. If I were to use this in a production setting, I would almost certainly normalize these indexes to reduce confusion, but for the time being, this footnote will have to be good enough to remind me! 😆

Tie it all together...

Once I had everything mostly planned out, I set out to writing the code to make it all work. As I had set the foundations nicely, all I really needed to do was loop through my events and append a new child to the DOM for each one. I made it a goal to not use innerHTML for anything because I mean, why should I be using that in the first place? Where I am not connecting this to an API for the moment, I won't go over how to fetch your data, nor will I go over any implementation of a "loading" state, but setting something like that up should be child's play if you comfortably read this far!

If there's any interest, I can certainly do a quick write up of how I went about plugging this in to my current project and tying it to backend data.

Thanks for reading!

So I made a website...

Connor Tangney — Fri, 24 May 2019 00:26:10 +0000

hey there!

I feel like I've been lurking around long enough. I've seen all these cool projects and have read all these cool articles and have decided -- "I want to do that too!"

Now that we've got that out of the way, I'm just going to get right to it. This is my first post, so forgive me if it's a little rough around the edges!

In sticking with the theme of beginnings, I felt that it would only be appropriate for me to share a little bit about the behind-the-scenes of my homepage. I don't really have any screenshots (the page can speak for itself), so I'll try to keep things mostly to-the-point.

main goal:

Place for me to easily share and write about my work while also keeping track of my accomplishments as a developer. In honesty, this website was a bit of a departure for me for two main reasons:

I have never published anything (literally, anything...) other than a digital resume...
I have never published anything built with technologies that weren't HTML and CSS...

That said, after lurking around here for a bit and seeing everyone talk about how important portfolio sites are, I figured I should probably have one too. But I didn't want to just stick something out there like, "Oh, hey, here's my stuff!"

I wanted to learn something from this. I wanted it to be an adventure, like all the best things in life!

When I sat down to think about the site, my main concerns were:

Easy updates. I did not want to spend time fiddling about with various web services, hosts, etc. My existing site was published to GitHub Pages, and I very much wanted to leverage this again. I was not really all that keen to set up a backend somewhere to host my posts, so I had to come up with another solution.
I wanted the site to be lightweight and performant across ~~all~~ most devices and on ~~all~~ most connections. I uploaded my mugshot up there in pretty high resolution, so the load time on that beast can be hit or miss. I've thought about compressing it down a bit but just... haven't? Hrmmm...

technologies:

I wanted to keep the tech stack pretty small in order to ensure that things didn't get too out of hand. I can get a little carried away sometimes! Heh...

I've outlined most everything I used to get this done below and have provided links so you can learn more if you're curious.

React: I think we all know about React 😊
Axios: This handles getting the data from the GitHub API
Showdown: This converts my Markdown to HTML
GitHub Pages: This is where my site lives

how it works (in a nutshell...)

In order to save myself the hassle (if you really want to call it that) of setting up a backend somewhere, I decided that I would just serve my posts as JSON directly out of the public directory. Take a look here to see what I mean. This would allow me the ability to serve posts directly out of the application. Neat.
Once the application was published, I was still going to need a way to connect to the GitHub API and download the raw data. Axios seemed the perfect tool for this!
After Axios gets the goods, it's all parsed out and passed off to various components so that I don't have to do any work to get a new page or card on my work listing. It all happens when the "post" is added to the public directory. Neat!
For the posts themselves, I simply store some Markdown right in the JSON file so that I don't have to muck about with any real layout. The whole process is not too unlike what I'm doing right now. Neat-o burrito!
Once I have everything all set in my public directory, I just push it all to my repo, and the changes happen automagically! Laziness prevails! Huzzah!

a note:

Posts load in random order cause I was too lazy to enforce any kind of order for the moment. This is something I may address at a later date, but for the moment, the number of projects that I have listed is low enough that I feel it is unwarranted.

closing thoughts:

So, I pretty much failed at keeping this short and sweet, but I feel like that's okay. If you've made it through my ramblings, I applaud you! I'd love to hear what you guys think about the layout of the site, what you think of my solution, and any areas that you feel I could improve in the future.

Cheers!

Forem: Connor Tangney