Rendezvous — Events by the People, for the People

5 min readMar 12, 2021

rendezvous: to meet or come together at a particular time and place
-Merriam-Webster Dictionary

Rendezvous is a single-page application dedicated to crowdsourcing event information. Users can find upcoming events recommended by members of their community, as well as add their own. Rendezvous is people-driven — it works best when members are actively viewing, adding, and updating events.

Building Rendezvous’ Back-End — Using a Rails API

Before getting started with the front-end, it was important to get the back-end set up so that the front-end had something to reference and work with. To do so, I created an API using Rails. To keep things simple, I created my file with rails new event-list-backend --api to bring in a file structure appropriate for an API-only rails project (ie — no views).

From there, I utilized scaffolding to automatically build out my database/tables, routes, controller, and model for Meetings. This also automatically filled out most of the logic I needed in my controllers, which saved a ton of time. When scaffolding, I included a name, date, location, and description for each event as a column. I also wanted each meeting to have a host. However, I determined that a host should be its own model (with simply a name column) and that a host should have many meetings, and a meeting should belong to a host. I created these associations in my model files and in my database via foreign keys.

In the end, my schema looked like this:

Building Rendezvous’ Front-End — Using Object-Oriented JavaScript

For this project, I used Object-Oriented JavaScript and organized my code by splitting it up into classes. These classes were determined by the concern the code was handling — functions that handled the meetings were in a class called Meeting, while functions that accessed the API were in a class called Api. In addition to these two classes, I had a globals.js file that handled functions that would need to be accessed globally, and a file called index.js for other functions that did not appropriately fit in elsewhere.

globals.js

The globals.js file is the most simple and straightforward of them all. Here, using arrow functions, I put any functions that get elements by their ID.

meeting.js

Since the bulk of Rendezvous’ functionality is based around meetings, this is where most of the code lives. Since this file contains a class, unlike the index.js and global.js files, it was necessary to create a constructor. A constructor runs when you create a new instance of the object and provides the default attributes. Here, this should mimic the columns created in the back-end:

The rest of this class contains any and all functions whose main concern is centered around a meeting or meetings. This includes everything from rendering the forms for creating and editing, gathering and rendering the meetings, and the event listeners for submitting the forms.

api.js

The focus of the Api class is functions that access the API that was created to be our back-end — this is how we connect the two. Without these functions, we would just have a back-end that users could not access and a front-end that contains no info! To do this, I created the following asynchronous requests to fetch the data:

You’ll notice these functions (as well as many in the Meeting class) are all static — this is so that they can be called outside of the class. For example, in the below function (deleteMeeting(e), located in the Meeting class) we call Api.delete which tells the code to go to the delete request in the Api class. Similarly, Meeting.renderMeetings() tells it to run renderMeetings() function in the Meeting class.

index.js

The index.js file contains the few functions we need that don’t fit any of the above categories, including event listeners that handle events that need to load on DOMContentLoaded.

Implementing the JavaScript

To utilize the JavaScript we’ve written, it needs to be referenced in our index.html document. Since this is a single-page application, index.html is our only HTML file. Despite that, it appears sparse beyond the typical HTML setup:

That’s because JavaScript is doing most of the work — including rendering a lot of the HTML. In our index.html file, there are just a few tags with IDs for structural and CSS purposes that will remain on our screen no matter where the JavaScript takes us — things like the navigation bar, title, and content container. Then at the bottom of our <body> tag, we include our various JavaScript files. The order here matters — in order for the file to read something from another one, it must have already been loaded in. That’s why global.js is first (it is not dependent on another file being loaded to work, but other files are dependent on it) and index.js is last (nothing relies on it, but it relies on everything else).

Any HTML not seen here that ends up in the browser is created using JavaScript. For example, we can create a heading for our list of events using return and some HTML:

Or we can use JavaScript tools like document.createElement to create and then append said elements, like here where we render a meeting:

Utilizing CSS

At this point, if we were to leave our code alone it would technically work. However, it would look like this:

Not very user-friendly. So as a final step, we can write some custom CSS to address sizing, positioning, fonts, and colors, and make it look like this: