DEV Community: slj2222

MVC - Model View Controller

slj2222 — Wed, 20 Apr 2022 18:05:08 +0000

It is very important to know and understand what MVC, or the Model View Controller is when you are starting to learn Rails. MVC - Model View Controller is the architectural structure of Rails (and many other programming languages) projects that provides organization pattern, as well as an efficient means of separation of responsibilities. It is broken down into three parts, the model, the views, and the controllers. This blog will highlight what each part's role is and how they all work together.

Model
First, the model. Models are used to perform any business logic that is relevant to that specific model through ActiveRecord. Models communicate with the database to perform algorithms on the data (i.e. CRUD actions, create, read, update, delete). Most of the logic applied in the application will live in the model, including model relationships and validations. Models are classes that inherit from ApplicationRecord, which is a class that inherits from ActiveRecord::Base, which is what allows us to communicate to our database through the models.

Controller
Next, the controller. Controllers are the "middle man" in our application, which means they communicate between the data and the presentational parts of the application. They are responsible for determining how specific requests are handled. They will communicate with the model to retrieve data, then communicate that data with the view. Really, the controller is the engine behind the application that drives the experience between the web browser and our server. Each controller inherits from the ApplicationController, which is a class that inherits from ActionController::Base, which allows us to define actions that are associated with different routes in our application. For example, when our user makes a request at a particular route, our controller determines how to handle that request. Controllers will typically have a few different actions that are associated with an individual route. Each one of the actions will perform different behaviors by storing data inside an instance variable to be passed to the view.

View
Finally, the View. The views are strictly the presentational parts of the application and they only contain code that is specific to what the user should see. The views do not contain complex code, as there is no direct communication to the database or the models. Again, the views only have one responsibility, which provides a strong and dynamic webpage for the user.

Perhaps the most important part of the MVC is the naming convention. Here is a quick highlight of the naming conventions for each part of the MVC:

Model - should be singular, followed by ".rb"
(i.e. company.rb)

Controller - should be a plural representation of the model, followed by ".rb"
(i.e. company_controller.rb)

View - should match the action named in the controller to provide an implicit render.
(i.e. in the controller, there is a method called "show". The corresponding view should be called show.html.erb)

Hopefully this intro helps better your understanding on the MVC, each part's role and how they all work together.

Instance Methods vs. Class Methods: What's the Difference?

slj2222 — Wed, 30 Mar 2022 19:37:50 +0000

If you are starting your journey to becoming a software engineer, you will be introduced to Ruby at some point. If you find yourself struggling to differentiate between instances and class methods, this blog will hopefully help shed some light on the key differences between the two.

Fist, let me explain what a class is. Ruby is an object-oriented programming language, right? A class is a blueprint from which objects, or instances are created. For example, if you had a class called MLB_team (MLB = Major League Baseball), each MLB team would be an instance of that class. Here is a diagram to assist:

Each instance, or team would have their own set of data depending on what columns are set up in the table - a topic for a different day. Some column examples might look like this:

MLB_team instance -> team_name, team_manager, team_location, total_wins, total_losses, stadium_capacity, world_series_wins, world_series_losses, etc...

Now that we know what instances and classes are, now let me explain what methods are. A method is a set of expressions that return a value, very similar to a function in JavaScript.

The first key difference - syntax. Instance methods are called on the instances. Class methods are called on the class and declared using the "self" keyword, seen below.

Instance methods can be used to add, update and display information corresponding to the specific instance, whereas class methods can be used to query select information from all of the instances in the class.

In short, class methods are big-picture, looking at all the data in the class - every instance included. Instance methods are more specific, only looking at the specific instance.

React Components: Just Like Watching the News

slj2222 — Wed, 09 Mar 2022 21:15:49 +0000

Many ideas in React are hard for beginners to wrap their heads around. For me, I had trouble understanding how React components work, but more specifically, how they work together. This analogy is designed to help you understand the following:

1 - What are React components
2 - How do React components work together to build an app.

First, let me explain what React components are. React components are independent functions that accept inputs(i.e. props) and returns a React element that can be reused throughout your application. React applications use multiple components to ultimately give the app the look and functionality desired. There are parent components and children components, ultimately making up a React component tree, shown here:

All the components in this component tree work together to produce a wonderful application. Here is an image highlighting the different components on the Google homepage. Each highlighted component has its own functionality that adds a specific aspect of the page. When you bring all the components together, it gives you the desired look/functionality as a whole. After you have finished reading this blog, sketch out and send me what you think this component tree looks like.

The analogy is this. Everyone has watched a news broadcast like NBC Nightly News. No matter which station you're watching, the daily broadcast, or show that you watch each day is the application for this analogy - the end result. Each show has a head news anchor sitting at a desk and reporting to you. They also have a whole team of news anchors that are sent out to report on various stories all around the world. The news anchors are the components - the individuals who have a story to report on. The head news anchor acts as the parent component, essentially driving the show, where as the various news anchors who are reporting on specific stories are the child components. The child components are reusable in this case because for tomorrows broadcast, they will be covering a different story. When all the news anchors do their job, they work together bringing you the end result, which is an hour long program that is executed the way it was designed - just like the React components do to create the application.

Life without .addEventListener()

slj2222 — Wed, 16 Feb 2022 21:31:17 +0000

Can you imagine your life without .addEventListener()... probably not. Software Engineers/Developers know exactly what I'm talking about, but the general public has no idea how their lives would be effected if there were no event listeners.

For those of you who are reading this and thinking to yourself, "what the heck is an event listener"? An event listener is "An event listener is a procedure in JavaScript that waits for an event to occur. The simple example of an event is a user clicking the mouse or pressing a key on the keyboard...an inbuilt function in JavaScript which takes the event to listen for, and a second argument to be called whenever the described event gets fired." -according to GeeksforGeeks.

If you're still reading this and still thinking to yourself, "what the heck", let me further explain. Think about your most visited websites, apps on your phone, or you preferred social media platform (this list might be long). On your list, every one of the websites or apps is interactive, meaning there are places on the page that you can click on, either in the form of liking your friends photo, or something as boring as logging in to pay a bill. These features of your favorite websites/apps wouldn't be possible without event listeners.

Event listeners are written in the code to make your experience the best it can be when visiting the webpage/app. They sit silent in the background waiting for you to commit the certain action on your screen that will trigger their attached set of instructions. For instance, once you double-click that photo of your friends cute little puppy on Instagram, everyone knows you liked the photo. This is because the "feature", we'll call it, was sitting in the code not doing anything until you double-clicked the photo. Once you double-clicked the photo, the event listener (listening for the "double-click") fired off and executed a set of instructions. That set of instructions is a topic for another day.

There are so many different "features" that are built into websites/apps that we all interact with on a daily basis. Like I said before, they are there to enhance our experiences while on the web, and they stem from even listeners.

The important thing is, imaging your life without an event listener waiting for you to double-click your friend's photo. If that is hard to imagine, imagine a website/app that you couldn't click on. How boring would that be? In my opinion, life would be MUCH different, without event listeners but again, that is a topic for another day.