Lightbulb Moments
In general, there are few things more satisfying than having a lightbulb moment. That’s why learning programming has been such an enjoyable experience for me. While working through difficult coding labs, I’ve had multiple lightbulb moments that were like a drug that kept me coming back for more.
However, translating these lightbulb pieces of information into a functioning app is very challenging. I have all of this disconnected knowledge that I’ve recently been introduced to, and now I have to fit it all together in a way that produces a working webpage. Initially, all the pieces are just a random collection of cool code and I’m clueless on how to achieve my end result. But as I struggle through the process, I begin to grasp the logic of its flow. That’s when a project finally comes together for me.
I started this project by building my backend, a Rails API. I was already familiar with Rails and rendering web pages with the erb files found in the Views folder. So that setup went smoothly. I had to make one small change and then check to make sure that change setup correctly.
When creating my new Rails application, I had to add the — — api flag so that it would setup as an API only, and NOT have all the View functionality that’s automatically generated by Rails. Why? Because in my Controller actions, instead of sending my data to an internal Rails erb file to be rendered, I had to send the data externally to my JavaScript front end to be rendered. So…
I checked to ensure that the flag had replaced the code to send data (an instance variable) internally to an erb file: @posts = Post.all
with code to send data (a json object) externally back to my JavaScript front end: render json: posts
After that, my Rails API build was complete.
Next I had to begin my JavaScript build, and that’s when I had a major lightbulb moment, realizing what all the emphasis on front end and back end was truly about. Intellectually, it was easy to grasp that the front end was what the user sees in their browser and the backend was the data being delivered to their browser. But all the coding experience I’d had, kept the front and back end processes within a single framework.
Now, they were being split. My Rails API back end was only being used to receive and store information. My JavaScript front end presented the user with choices, took in their input, and delivered those instructions to my Rails API backend to handle creating and storing new data, then updating, revealing, or deleting data.
Once I understood the flow of the logic, mentally it was as if a room I’d been inside of all along suddenly became exposed, like the hidden image in an autostereogram finally coming into focus. (Note: autostereogram is better known through the popularity of Magic Eye optical illusions which were 2D patterns that contained hidden 3D images.)
Now that the room was in focus, I could navigate my way through the space.
In the first room, the index.js room, the lightbulb piece of using event listeners fell into place. By setting up an event listener on DOMContentLoaded, I was actually able to call functions that would prime the webpage for interactivity.
Class is another room in the JavaScript front end. It contains a constructor that builds instance objects based on the data the backend returns. It also contains methods that can be called on the instances to reveal them in the user’s browser organized in various ways.
In summary, this was a single page app, I only had one html page that used JavaScript to dynamically change the view in the user’s browser. How? Through function calls that receive user input, delivers those instructions to the Rails API backend, then receives a response back, and uses a Class to create instances of that response and reveals it in the user’s browser without having to refresh the page.
Overall, it’s an extremely bright idea!
