Skip to main content
Building A Calendar Gem:

Open Source Vlog - Refactoring Events And Uploading Version 2.0

Episode 76 · July 13, 2015

Refactoring events in simple_calendar and uploading version 2.0



Earn a free month

What's up guys? This episode we're talking about simple calendar's meeting functionality, so we have all these calendars that we've got, and we just made a couple more, we added the week and the month calendar, and it's actually time for us to take care of that meetings or events that we're handling in our application, so example here has two events: Holiday and BBQ, and those are on July 4th and they show up on the calendar on that day, of course, so we actually need to be able to pass those in and then do the filtering and handle all of that inside of the gem rather than doing it with the instance variable that we have right now, so we actually need to dive into our calendar application to make that change first. If we go into views/meetings/index.html.erb right here we have SimpleCalendar::WeekCalendar, and that's it, there's nothing really magical here, except for later on, this @meetings things happens and we have all of these saved to an instance variable, but we are requiring this instance variable to exist and we want to actually be able to pass it along through inside of our calendar than like making everybody set an instance variable on any page, that would be annoying, and you couldn't use that name that you wanted, so what ideally we could do is have when you create a new week calendar you could pass in the events, and it would be as simple as this, and we would be able to take that events option and then render out those events. So let's go ahead and do that. Now I'm going to take this and we're going to do two things. First we're going to make a month calendar here on both of these, and we're going to have one without the events, and one with the events, and the reason why we want to do this is to make sure we write our code such that it supports both, because some people may just want a calendar to visualize it, and other people may want to actually pass in events, so this basically means that our hash here is going to have events inside of it at this point, so that means that we can do something in our locals when we cal render and we can just pass in events here, and that could be our options, and we could fetch out the events that we passed in, otherwise we could give it an empty array, that way we always have this default, and we're going to be able to run the exact same code as normal every single time. Now we'll have events and it will either be an ActiveRecord relation or an array, something that's numerable or acts like an array, and we'll always know that we have that so that we don't really have to write in code to transform things or anything, and if it breaks, you should pass in an array, and that's OK.

Now that we've made that change, that's all we really need in the ruby code, and then in our views, we can remove meetings and replace that with events, and we can do that in each of these, so we'll go into each of these and replace that, and we'll save it, and I'm going to restart our rails server sot that we get all those changes, and in theory, once we reload this page, we should get two month calendars and we do, and the first month calendar has no events, the second month calendar has events which is perfect, and then another interesting thing we could do to make sure that our code is functional is we could change these from @meetings to @events and make sure that we didn't write any code accessing that other variable, if we go into the meetings controller, we could set


def index 
    @events = Meeting.all 

I'm going to delete all of this code because we don't really need that anymore for the other template, the calendar that we experimented with doesn't need to be here anymore, so we'll save that, refresh our page, and it actually turns out that we're calling @meetings somewhere in our code, so it looks like we're still doing that in the index, and I did not delete all of this code as I thought I did. So here we go, we can refresh that, and we're back into where we were, so we have sort of a confirmed thing that we're not using the @meetings variable anywhere we're actually using the local variable that we set in the render partial call, so that's awesome, we've made some cool changes here, and we're passing meetings over just as we would expect, this is really really simple. That's really all we actually need to do from the meetings perspective, one last thing that we can do to make suer that we got all of those is we could say

grep -R "meetings" .

Anything we did find was in the README so it's just examples that's all we're seeing, and I'm finally going to commit all of this to the repository, so I'm going to push this up to GitHub finally so that you can take a look at this and we've really made a major update to simple_calendar, we have a couple things left, we want to be able to handle injecting this views into your rails apps so that you could override them, or to make sure that that works provide a generator for that, and then it would be nice to write some tests and what's awesome, is if you noticed our calendar method is so simple, that we really don't have much to test, we don't necessarily need to test the initialize method, we could but it's so simple it's kind of whatever, and render just really needs to make sure that we render out the correct partial and then locals get passed in and we just need to make sure that there's a start date, a date range and options, and that's really it. This is super duper easy to test whereas before we would have had to do all this stuff and it would have been really complex, now simple_calendar is super duper simple, it does exactly what you would expect and our tests can be simple as well, and we wouldn't have the giant mess that we would have if have had started writing tests back when we originally started, so I think we're making really good progress, there's a few other options that we'd like to add like multi-day events or something like that, but this is such good progress on the basics of simple calendar that it sets the foundation for us to make more complicated things in the future and make them much much cleaner and easier than they ever would have been before, so let's finish out making this commit and push it up to GitHub so you guys can check it out and then actually we might be able to release this version in just a day or two, what did we do here? I think the main thing is that we re factored all of the rendering for calendars, and if we break this down, we "Render a partial for each calendar type", "Have calendar types only define their date ranges", "Allow overwriting of calendar templates", "Customization happens inside the templates". This is most of what we did, this has turned out to be very very simple what we did, but at the same time very flexible, so this is cool. I'm going to say we'll leave it at that and push this up to GitHub, and that's it. If you're interested in taking a look at this and playing around with it and working on it with me, take a look at the 2.0 branch, it took me a lot longer to push this up to GitHub than I expected, but I wanted to have a strong foundation before we get a lot of pull requests and other things going, so take a look at that, someone definitely would be very welcome to update the README, we don't really have the same week calendar and month calendar helpers as we did before, we may or may not want to add those, I don't know that we really benefit from that too much, it definitely nice than saying SimpleCalendar::MonthCalendar.render and all that, it's a little too much to do this, but at the end of the day those helpers are really just abstracting this, so if you think it's useful, then discuss it in a GitHub issue and see if we want to do that or not, I don't know, I'll leave it up to you guys to start that discussion, so yeah, take a look, clone it, add it to your rails app, see if installing it makes sense to you and using this is as good as I hope and that's it for this episode, I think we will talk tomorrow about the next steps for this, but we're making huge strides and really only putting in a few minutes every day, so that's super duper fun, and I hope you enjoy this, give it a like, subscribe, leave a comment if you have some thoughts on what we could do next, give me your feedback and we'll make this better together. Peace

Transcript written by Miguel


Subscribe to the newsletter

Join 31,353+ developers who get early access to new screencasts, articles, guides, updates, and more.

    By clicking this button, you agree to the GoRails Terms of Service and Privacy Policy.

    More of a social being? We're also on Twitter and YouTube.