From Ruby To Javascript

MVP Project Flatiron School

Falling in love with Ruby was easy but you Javascript oh we had our trials and tribulations but I think I am starting to fall for you…..maybe.

Transitioning from Ruby to Javascript is very interesting. For one, Ruby, more specifically Ruby on Rails, adopts a lot of conventions whereas Javascript seems to empower software engineers with a seemingly endless myriad of options at solving a problem. This paradigm proved to be the most challenging when it came to learning JS. For example, there is a multitude of ways on how one can start writing a function from arrow functions, declaration functions, expression functions, anonymous functions, IIFE functions…why? And to declare variables, apparently there are three different ways to do so with var, let, and const. Keep in mind, each of the aforementioned options carry varying degrees of functionality, such as scope for writing functions and persisting data with variable declarations, which must be taken into account when building any kind of JS app which is what I will be discussing below.

In hindsight…

I should’ve started my project with a design doc or some detailed planning formula. I already knew how I wanted the backend of my app to function, all I had to do was create a Rails API that provided at least two endpoints aka URLs. My API would feature a has many relationship between my two Models. The database would run on Postgresql a relational database that supports table inheritance and is necessary if deployment to Heroku is foreseeable. The Rails API would employ RESTful conventions and have seed data, data that is populated into the database when its created, that would feed into the front-end which renders it to a browser. As is typical within a project’s development lifecycle, there might be small changes to your original planning but one should keep it to just small changes to preserve the foundation that was already created. In my case, the small changes involved adding more actions to my controllers and validation error messages in my Models. Either way, the changes didn’t merit me throwing away the entire back-end and starting from scratch which may seem trivial to me later on but currently I am proud of at least planning out my back-end well enough.

There was no planning for the front-end

And I tremendously suffered ! They say failure/pain are life’s greatest lessons, well hence forth I will, at the very least, develop some measure of planning for a front-end framework. I knew what had to be accomplish, given the project requirements, but how to go about reaching them well I was nearly completely lost. I battled through understanding scope, promises, function declarations and which ones to use based on a certain scenario, for example, ES6 arrow functions can carry scope of this meanwhile nested declaration functions cannot….again why JS? Do I employ static methods or regular instance methods? The difference being static methods are “utility” methods that are called on the class aka an object that represents a real world thing so for instance my app features a bird and sighting classes however say I created a bird called Domino well in the programming world we call Domino not a class but an instance of that class and being that it is an instance we would develop “normal” instance methods who’s purpose is to perform some action on Domino. Get it? Deep breaths because I am about to attempt to explain Javascript’s asynchronous nature. In layman terms, asynchronous operations in JS enable you to see a webpage and interact with it while other elements of that webpage are being loaded. I guess to sharpen the perspective, the opposite of asynchronous operations are synchronous operations which would tell the webpage don’t load anything until everything works. And thats when I realized the power and beauty of JS. Some ongoing battles throughout the project involved understanding to a high degree how to query select DOM elements that had dynamic ID values, and, deciding where to place my event listeners. Also, for some reason near the end of my project, perhaps from exhaustion, its currently 5:12am, I forgot how to utilize breakpoints and the console to investigate if something is working the way I want it to work and if it isn’t then what is it returning and make a plan to fix it. To be frank, I personally think test drive development with pry in Ruby is so much more welcoming than the browser console but that is just my opinion. Nonetheless, after breaking apart my front-end several times attempting to fully understand what I wrote, I finally finished my project

Final thoughts…

Building my first full stack web app utilizing JS and an API was very challenging. But now I see an entire field of possibilities with this new skillset. I cannot wait to start on my next project. Next up….React!