DEV Community: Ronnie

The State of Taking Props to School

Ronnie — Sat, 18 Sep 2021 11:41:03 +0000

From my experience as an instructor state and props can really throw React beginners for a loop. The good news is that loop doesn't need to be endless (😅).

State & Props: What Are They?

props (short for “properties”) and state are both plain JavaScript objects. While both hold information that influences the output of render, they are different in one important way: props get passed to the component (similar to function parameters) whereas state is managed within the component (similar to variables declared within a function).

Reactjs.com - Component State

Uh, yeah, okay... but what does that mean? Well, let's take a look at a real world example. Think way back to your grade school days. Remember field trips? And permission slips?

Your mom, dad or parental guardian had to sign a permission slip in order for you to go on a field trip. You brought that permission slip to your teacher and showed it to them to prove that you were allowed to go. This is a great way to think about state and props.

I'm going to use hooks and functional components in these examples, but class components will work, too.

Starting out, the browser looks like this:

The Parent component is rendered in App.js. Here is the starting code for both Parent and Child:

import Child from './Child';

const Parent = () => {

  return (
    <div className="container">
      <div className="parent">
        <h2>I am the parent.</h2>
      </div>
      <div className="child">
        <Child />
      </div>

    </div>
  );
};

export default Parent;

and here is the starting code for Child:

const Child = () => {

  return (
    <div className="child-component">
      <h3>I am the child.</h3>
    </div>
  );
};

export default Child;

The first thing we're going to do is set up state in our Parent component.

const [isSigned, setIsSigned] = useState(false);
const location = "the science museum";

The permission slip for the science museum begins in an unsigned state. Now we need to set up some way for our Parent to sign the permission slip for their child. We'll stick to a simple click event on a button. The button will also render conditionally, based on the value of our isSigned state.

const handleClick = () => {
  isSigned ? setIsSigned(false) : setIsSigned(true);
};

const renderButton = () => {
    return !isSigned ? <button onClick={handleClick}>Sign Permission Slip</button> : <button onClick={handleClick}>You're Grounded!</button>
};

We now want to invoke renderButton right under our h2 tag in the Parent component. This is what we see in the browser now:

In order to make sure our button actually works, we're going to add {console.log(isSigned)} inside of our Parent component. Our code should look something like this:

const Parent = () => {
  const [isSigned, setIsSigned] = useState(false);
  const location = "the science museum";


  const handleClick = () => {
    isSigned ? setIsSigned(false) : setIsSigned(true);
  };

  const renderButton = () => {
    return !isSigned ? <button onClick={handleClick}>Sign Permission Slip</button> : <button onClick={handleClick}>You're Grounded!</button>
  };

  return (
    <div className="container">
      {console.log(isSigned)}
      <div className="parent">
        <h2>I am the parent.</h2>
        {renderButton()}
      </div>
      <div className="child">
        <Child />
      </div>

    </div>
  );
};

This is what we should see after our first button click:

and if we click one more time:

Now that we know everything is working correctly in our Parent component, we can start thinking about props! Our Child needs some way to tell their teacher whether they can or cannot go on the field trip. We need to pass this information down to our Child.

<div className="child">
  <Child location={location} isSigned={isSigned} />
</div>

This is how we pass information from parent to child. In our Child component, we pass the props in as an argument.

const Child = (props) => {
  console.log(props)
  return (
    <div className="child-component">
      <h3>I am the child.</h3>
    </div>
  );
};

With that console.log, we'll see this in browser console:

We can make things a little cleaner here by using destructuring!

const Child = ({ location, isSigned }) => {
  console.log(location)
  console.log(isSigned)

  return (
    <div className="child-component">
      <h3>I am the child.</h3>
    </div>
  );
};

export default Child;

Now that we have access to that data in our Child component, we can display that data!

In the Child component, we now have a function called renderPermission, which renders text conditionally based on the value of isSigned.

const Child = ({ location, isSigned }) => {

  const renderPermission = () => {
    if (isSigned) {
      return `I can go on the field trip to the ${location}!`
    } else {
      return `I'm not allowed to go on the field trip to the ${location}.`
    };
  };

  return (
    <div className="child-component">
      <h3>I am the child.</h3>
      {renderPermission()}
    </div>
  );
};

export default Child;

Remember that we can't change props! A kid can't forge their parent/guardians signature! Let's try it out.

  const forgePermission = () => {
    console.log('Clicked')
    isSigned = true;
  };

  return (
    <div className="child-component">
      <h3>I am the child.</h3>

      <button onClick={forgePermission}>Forge Signature</button> <br />

      {renderPermission()}
    </div>
  );

We're including a console.log so that we can be sure that our event listener is working.

We can't do it! They're not changing! Our Child component is not re-rendering. Our parent component is in charge of the data and changing it (with state!) and our child component only has the ability to display that data (they're props!).

Here is a look at our finished code:

import { useState } from 'react';
import Child from './Child';

const Parent = () => {
  const [isSigned, setIsSigned] = useState(false);
  const location = "the science museum";


  const handleClick = () => {
    isSigned ? setIsSigned(false) : setIsSigned(true);
  };

  const renderButton = () => {
    return !isSigned ? <button onClick={handleClick}>Sign Permission Slip</button> : <button onClick={handleClick}>You're Grounded!</button>
  };

  return (
    <div className="container">

      <div className="parent">
        <h2>I am the parent.</h2>
        {renderButton()}
      </div>
      <div className="child">
        <Child location={location} isSigned={isSigned} />
      </div>

    </div>
  );
};

export default Parent;

const Child = ({ location, isSigned }) => {

  const renderPermission = () => {
    if (isSigned) {
      return `I can go on the field trip to the ${location}!`
    } else {
      return `I'm not allowed to go on the field trip to the ${location}.`
    };
  };

  const forgePermission = () => {
    console.log('Clicked')
    isSigned = true;
  };

  return (
    <div className="child-component">
      <h3>I am the child.</h3>

      <button onClick={forgePermission}>Forge Signature</button> <br />

      {renderPermission()}
    </div>
  );
};

export default Child;

That's it! That's state and props in React. It's as simple as that.

Cover image from Austin Pacheco on Unsplash

To the VSCode Extensions I Love the Most

Ronnie — Sun, 12 Sep 2021 15:29:13 +0000

This certainly isn't the first time someone's made a list of their favorite VSCode extensions and it won't be the last, but these are mine! I'll start with some of my favorite JS related extensions and then we'll jump into HTML/CSS helpers.

I'm starting with the holy grail of all extensions. This one, I swear, has saved my life.

JS & Friends

Bracket Pair Colorizer

This extension does exactly what it's name says. It might not seem like anything life changing, but think about working with some deeply nested code, or a huge file.

Life WITHOUT Bracket Pair Colorizer:

Life WITH Bracket Pair Colorizer:

Each pair of brackets, curly brackets and parentheses has its own color, which makes it very easy to identify where you might have an 'oops'.

Wow, this already seems AWESOME, but WAIT-- there's more. Moving your cursor to the inside of the first bracket draws a line (in the same color) to its partner.

Simple React Snippets / Next.js Snippets

Writing boilerplate code takes FOREVER. It's ANNOYING. Simple React Snippets and Next.js Snippets ease that boilerplate pain.

Functional Components & Hooks with Simple React Snippets

Next.js Snippets

Both of these extensions have a ton of snippets, but I don't have the time to make that many gifs!

JavaScript (ES6) Code Snippets
This one is very similar to Simple React Snippets, but applies to plain 'ole, vanilla JavaScript.

These are the ones I use most often, but there are a ton more. Notable mentions include:

sti for a setInterval setup
thenc to add .then() and .catch() to a promise.
clg for a console.log()

Template String Converter

This one is small but mighty (helpful). Anytime you type ${} within a set of single or double quotes, this extension automatically converts them to backticks.

HTML & CSS

VSCode is pretty great with HTML & CSS all on its own. * You can use html:5 to get some solid HTML boilerplate.

Typing a will give you opening and closing link tags.
Typing div will give you opening and closing link tags.
VSCode auto-completes CSS attributes for you.
The newest VSCode update allows you to edit an opening and closing tag at the same time (😍).

There are a few good helpers out there though!

HTML Tag Wrapper

Wrapping already written code in a new tag has been driving me insane for as long as I can remember, but now there's an answer. Highlight, ctrl + i and the nightmare is over.

CSS Snippets

Yes, yes, more snippets! What developer doesn't love writing less code?

The length of this list of snippets is rivaled only by a Game of Thrones book.

Live Sass Compiler

Last but not least, Live Sass Compiler! Sure, sure, you can just get this up and running in your terminal with a command or two, OR you could just click this:

Totally up to you, but I know what I'd rather do.

That's it for my favorite extensions list (for now). Feel free to drop your favorites in the comments! I'm always looking for new gems in my extension treasure collection.

JavaScript and Hoisting

Ronnie — Wed, 13 Jan 2021 16:56:39 +0000

Hoisting can be a difficult concept for people just starting out with JavaScript. Before we get into the how's and why's of hoisting, let's go over what hoisting actually is. In the simplest terms:

Hoisting is JavaScript's default behavior of moving all declarations to the top of their scope before the code is executed.

Hoisting was originally written into JavaScript to allow functions to be used before declaration and the hoisting of variables was simply a byproduct of that feature.

Why would we even need to use functions before they are declared?

It's necessary for things like mutual recursion, which is a subject for another day.
Some people think code looks cleaner when written this way. (I agree!)

A lot of people think that hoisting actually moves your code around, but JavaScript just reads your code before executing. This step is called compilation. JavaScript takes into account every declaration in your code and is then aware of those declarations prior to execution.

var

var is function scoped When we define variables using var, they are lifted to the top of their scope during compilation, no matter where the variable has been declared. When we talk about the scope of var it's important to mention that the scope is either global or the top of the function in which they were defined. Even if that variable is declared inside of a conditional or a loop. However this applies only to the declaration, not the assignment. Here's an example:

console.log(yearBorn)
var yearBorn = 1990

What do you think this code would log to the console?

If you guessed undefined, you'd be correct! This is because JavaScript only hoists the declaration, not the assignment. This isn't a helpful error. It can make bugs difficult to find and remedy.

Thankfully, JavaScript gave us let and const with ES6! The errors we get using let and const are significantly more helpful than just a plain ole undefined.

const

const means that the identifier can't be reassigned. They keep constant values that cannot be updated or re-declared. As an example, let's say you planned on making a really nice dinner when you get home from work. It turns out you had to stay late today and don't really have the time or energy to make your special dinner.

const dinner = "Beef Wellington"
dinner = "Frozen Pizza"
console.log(dinner)
// Uncaught TypeError: Assignment to constant variable.

Doing something like this will cause us problems as well:

const dinner = "Beef Wellington"
const dinner = "Frozen Pizza"
console.log(dinner)
// Uncaught SyntaxError: Identifier 'dinner' has already been declared

This doesn't mean const is a bad thing! We may have important values in our that we want to make sure can't be re-assigned or re-declared. Specific formulas or numbers as just a couple examples. Something else of note about const: If the value of our variable declared with const is an array or object, the properties within them can be updated. It's best practice to use const unless you know the declared variable will be re-defined at some point. That brings us to let!

let

Let's go back to our dinner example.

let dinner = "Beef Wellington"
dinner = "Frozen Pizza"
console.log(dinner)
// Frozen Pizza

let, const and Hoisting

Now that we know what let and const are and what they do, we can talk about them in the context of scope and hoisting. let and const are both block scoped, mean they exist only in the block where they were declared. This differs from var in that if a variable is declared with let or const it is hoisted to the top of its scope which could be global, a function or inside of a code block like a conditional or loop.

let ingredients = ["Spaghetti", "Meatballs", "Garlic Bread"]

function makeDinner(ingredients) {
  let firstIngredient = ingredients[0]
   if (firstIngredient.length > 5) {
     let longIngredient = true
   } 
   return longIngredient;
}

console.log(makeDinner(ingredients))
// Uncaught ReferenceError: longIngredient is not defined

console.log(firstIngredient)
// Uncaught ReferenceError: firstIngredient is not defined

Let's forget about the code we've written up above and say we forget to gather our ingredients before making dinner.

function makeDinner(ingredients) {
  var firstIngredient = ingredients[0]
   if (firstIngredient.length > 5) {
     var longIngredient = true
   } 
   return longIngredient;
}

console.log(makeDinner(ingredients))
let ingredients = ["Spaghetti", "Meatballs", "Garlic Bread"]
// Uncaught ReferenceError: Cannot access 'ingredients'
 before initialization

And with var:

...
console.log(makeDinner(ingredients))
var ingredients = ["Spaghetti", "Meatballs", "Garlic Bread"]
// Uncaught TypeError: Cannot read property '0' of undefined

In short, forget about var and welcome let and const into your code with open arms.

Here is a little hoisting cheat sheet:

var

Hoisted? yes
Initial Value: undefined
Scope: function

let & const

Hoisted? no (technically yes, but not in practice)
Initial Value: **
Scope: block

Function Declarations

Hoisted? yes
Initial Value: the actual function
Scope: block (this is only true when using 'strict' mode, which you should be!)

Function Expressions and Arrow Functions

In this case, it depends on whether they were declared using var, let or const. They will behave the same way variables do with those declarations.

That's a pretty broad and simple explanation of hoisting. I hope it helps!

Get Some REST: Server Responses

Ronnie — Thu, 07 Jan 2021 01:26:32 +0000

Last week I covered the basics of RESTful architecture on the client side. This week I'll be talking about the server side.

When a client sends a request to the server, content types are included in the request header. When the server is returning a data payload, it needs to include a content type in the header of its response.

A client trying to access a resource could look like this:

GET /posts/19 HTTP/1.1
Accept: application/json, text/html

And the server response might look something like this:

HTTP/1.1 200 (OK)
Content-Type: application/json

That brings us to response codes! When a server returns a response it includes a status code that lets the client know whether or not the request was successful. There are a lot of different status codes, too many to remember but here are the most common ones:

200 (OK) - Response to a successful HTTP request
201 (CREATED) - Response to an HTTP that successfully created an item.
204 (NO CONTENT) - Response to a successful HTTP request where nothing is being returned in the response.
400 (BAD REQUEST) - Response failed due to improper syntax, excessive size or some other error coming from the client side.
403 (FORBIDDEN) - The client doesn't have permission to access the resource.
404 (NOT FOUND) - The one most people see most frequently. This response says that the server wasn't able to find this resource.
500 (INTERNAL SERVER ERROR) - Blanket error for unexpected failures when more information isn't available.

All HTTP verbs have an expected status code when the request is carried out successfully:

GET - 200 (OK)
POST - 201 (CREATED)
PATCH - 200 (OK)
DELETE - 204 (NO CONTENT)

and that concludes our high-level overview of REST!

Get Some REST: Client Side

Ronnie — Sat, 02 Jan 2021 18:06:47 +0000

REST, or REpresentational State Transfer, is an architectural design system thought up by Roy Thomas Fielding in 2000 after being frustrated with the lack of standardization in structuring URLs. RESTful systems are (stateless)[https://restfulapi.net/statelessness/] and separate the concerns of the client and server.

Santa's Regex to Town

Ronnie — Sat, 02 Jan 2021 18:06:40 +0000

To the bewilderment of my friends and co-workers, regex (or regular expression)is one of my favorite things in the world. Not only is writing them fun (think ciphers!), but they can be extremely useful as well! Today we're going to see how we can use it to help out our pal Santa Clause.

Here is a brief rundown on regular expressions before we get started:

-- What is it?: a sequence of characters that define a search pattern.

Santa's Regex to Town

Ronnie — Sat, 26 Dec 2020 00:54:59 +0000

Before we get started... What is regex?: a sequence of characters that define a search pattern. A lot of programming languages either have regex built in or usable through libraries. Today we're going to use Ruby!

Why is it useful?: When we use regex to define a search pattern, we can save ourselves a ton of time. It's efficient to write and efficient to run.

We all know that Santa Clause is an incredibly busy man. His eyesight isn't what it used to be though. (He still knows who has been behaving though!) This year the elves forgot to split the list into two, one for nice children and one for naughty. Santa needs our help to see who all of the good children are before he heads out to deliver toys.

Let's say this is our list of children:
all_kids = "Ronnie - Nice, Candice - Nice, Michael - Naughty, Elsa - Naughty, Blake - Nice, Jer - Nice, Helen - Naughty, Anthony - Nice, Nicholas - Naughty, Joseph - Naughty"

Santa would like to know how many nice children are on the list this year so he can make sure that he's got enough time to get to everyone.

We can use Ruby's .scan method for this one. It will return an array of each occurrence of our search pattern.

def nice_length(kids) 
  kids.scan(/\b(nice)/i).length
end

nice_length(all_kids) would return 5. Neat!

Santa asks us to give him a list of only the nice children so that he can make sure all of the gift tags are correct.
all_kids = ["Ronnie - Nice", "Candice - Nice", "Michael - Naughty", "Elsa - Naughty", "Blake - Nice", "Jer - Nice", "Helen - Naughty", "Anthony - Nice", "Nicholas - Naughty", "Joseph - Naughty"]

def nice_list(kids)
  kids.map{|kid| kid if kid.match(/\b(nice)/i)}
end

Running this method returns this array: ["Ronnie - Nice", "Candice - Nice", "Blake - Nice", "Jer - Nice", "Anthony - Nice"]

Awesome! We just made Santa's job way easier. Hopefully this keeps us on the nice list for next year!

Here are two great resources for practicing regex: Rubular.com and Regular-Expressions.info.

bind(), apply() and call() me maybe: Pt. 3

Ronnie — Fri, 18 Dec 2020 21:03:31 +0000

This is the third and final post of my three part series on JavaScript's bind(), apply() and call().

Here is the JavaScript MDN explanation of call():

The call() method calls a function with 
a given this value and arguments provided individually.

apply() and call() are relatively similar. Both immediately invoke a function (with a specified context for this), where bind() does not. The difference lies in the arguments. apply() allows for arguments to be passed in as an array and call() needs arguments to be passed in one by one.

As we learned in the previous parts of this series and by brushing up on this, using the this keyword without context results in undefined.

const snowPerson = {
  top: "small snowball",
  middle: "medium snowball",
  bottom: "large snowball",
  accessories: "sticks, coal, scarf, hat and a carrot"
}

function buildSnowPerson() {
  return `Stack ${this.middle} on top of ${this.bottom} 
and stack ${this.top} on ${this.middle}. 
Use ${this. accessories} to finish your snow person!`
}

If we invoke buildSnowPerson(), it will return:
Stack undefined on top of undefined and stack undefined on undefined. Use undefined to finish your snow person!

Yikes. Looks more like a government document than it does instructions to build a snow person!

But, if we use call(), buildSnowPerson.call(snowPerson) we'll get some pretty good directions to build a snow person!
Stack medium snowball on top of big snowball and stack small snowball on medium snowball. Use sticks, coal, scarf, hat and a carrot to finish your snow person!

When we're using call(), the snowPerson object used as the argument becomes our this.

Here's an example of using additional arguments with call():

function snowPersonSeason(hot, cold) {
  return `If it's ${cold}, you can build a snow person like this: 
Stack ${this.middle} on top of ${this.bottom} 
and stack ${this.top} on ${this.middle}. 
Use ${this. accessories} to finish your snow person! 
This won't work if it's ${hot} time! `
}

Can you guess what snowPersonSeason.call('Summer', 'Winter') will return?

If it's Winter, you can build a snow person like this: 
Stack medium snowball on top of big snowball 
and stack small snowball on medium snowball. 
Use sticks, coal, scarf, hat and a carrot to 
finish your snow person!

This won't work if it's Summer time!

Those are the basics of call()!

bind(), apply() and call() me maybe: Pt. 2

Ronnie — Mon, 07 Dec 2020 19:50:55 +0000

Last week, I covered bind() and this week I'll be going over apply().

First thing, this is how JavaScript's MDN describes apply():

The apply() method calls a function with a given this value, and arguments provided as an array (or an array-like object).

Let's say you just got a new job. There are a lot of new people to meet, so let's write some code that will make introducing yourself to everyone a little bit easier:

let aboutMe = {
  firstName: "Joe",
  lastName: "Coder",
  job: "web developer"
}

function sayHello(greeting, message) {
  return `${greeting}. I'm ${this.firstName} and I'm a 
  ${this.job}. ${message}`
}

let introduction = sayHello.apply(aboutMe, ["Hello!", "It's nice to meet you!"])

console.log(introduction)
// returns "Hello! I'm Joe and I'm a web developer. It's nice to meet you!"

Can you guess what happens without apply?

let introduction = sayHello(aboutMe, ["Hello!", "It's nice to meet you!"])

console.log(introduction)

// returns [object Object]. I'm undefined and I'm a undefined. Hello!,It's nice to meet you!

It's a good thing we remembered to use apply() or that would have been embarrassing.

That sounds pretty similar to bind(), but remember: bind() creates a new function and apply() does not. If we were to try: console.log(introduction()) we would get an error that looks something like this: TypeError: introduction is not a function

apply() is similar to call(), which we'll be covering next week!

bind(), apply() and call() me maybe: Pt. 1

Ronnie — Fri, 04 Dec 2020 20:24:07 +0000

This is part one of a three part series on JavaScript's bind(), apply() and call(). These three methods are pretty closely related, but I think that each one deserves its own post! These concepts can be a little difficult to grasp, at least they were for me, so focusing on one at a time will be helpful!

The this keyword:

This tutorial covers just about everything you need to know about this.

First, let's take a look at the docs on bind() from JavaScript MDN:

The bind() method creates a new function that, when called, has its this keyword set to the provided value, with a given sequence of arguments preceding any provided when the new function is called.

That explanation is a little rough, especially if you're new to JavaScript. Let's break it down!

bind() returns a new function that has a specific value of this bound to it when invoked.
The parameter passed into bind() will become this.
You can add extra parameters to bind() after this initial this.
Use bind() when you want to call a function later on and with a specific context.

Here's an example without bind():

let meal = {
  snack: "apple"
}

let eat = function(){
  console.log(this.snack)
} 

eat();
// will return undefined

Here is where bind() comes in to save the day!

let boundEat = eat.bind(meal)

boundEat();
// returns "apple"

Now, let's see how we can add in those extra arguments!

let meal = {
  type: "dinner",
  consistsOf: "spaghetti and meatballs"
  chef: function(name) {
    return `Chef ${name} says: "We're having 
    ${this.consistsOf} for ${this.meal}."`
  }
}

let chefSays = meal.chef.bind(meal, "Remy")

// returns Chef Remy says: "We're having spaghetti and meatballs for dinner."

That's bind() simplified!

Taking a Load Off with ActiveRecord

Ronnie — Sat, 28 Nov 2020 01:49:49 +0000

ActiveRecord is the ORM layer Ruby on Rails supplies to an application. Most simply put, ActiveRecord is the 'M' in MVC. Models are the system responsible for representing the application's logic. ActiveRecord saves us a lot of time that could be spent writing database query commands, think SQLite, Postgres, MySQL...

ActiveRecord maps a table to a database making each row of data and instance of a class and makes all of our database queries simple, neat and quick (ORM).

Let's see the difference between adding a row to a database table and finding that row or instance in the table with an SQL query:

INSERT INTO Users (name)
VALUES ("Joe Everyone")

SELECT * FROM Users
WHERE name="Joe Everyone"

and with ActiveRecord:

User.create(name: "Joe Everyone")
User.find_by(name: "Joe Everyone")

This isn't saving us TOO much time, but what happens when we have a lot more parameters for an instance of the User class, name, DOB, location, do they have a premium account?...

The real magic happens when we get into the relationships and associations between models.

User model and migration table:

class User < ActiveRecord::Base
  has_many :posts
end

class CreateUsers < ActiveRecord::Migration[5.2]
  def change
    create_table :users do |t|
      t.string :name
      t.string :email
      t.string :avatar_url
      t.integer :post_ids
    end
  end
end

Let's say these users are blogging, so we'll create a Post class and migration table as well:

class Post < ActiveRecord::Base
  belongs_to :user
end

class CreatePosts < ActiveRecord::Migration[5.2]
  def change
    create_table :posts do |t|
      t.string :title
      t.text :content
      t.date :post_date
      t.integer :user_id
    end
  end
end

Let's see what writing these tables would look like as SQL queries:

CREATE TABLE User
(
Pk_User_Id INT PRIMARY KEY,
Name VARCHAR(20),
Email VARCHAR(20),
Avatar_Url VARCHAR(20)
);

CREATE TABLE Post
(
Pk_Post_Id INT PRIMARY KEY
Title VARCHAR(50),
Content TEXT,
Post_date DATE,
Fk_User_Id INT FOREIGN KEY REFERENCES User(Pk_User_Id)
);

Starting to look like some heavy lifting on the SQL side. Now, let's say we want to see all of the posts from a certain User

With SQL, we'll need write an Inner Join:

SELECT *
FROM Users
INNER JOIN Posts
WHERE User.Pk_User_Id = Post.Fk_User_id

With ActiveRecord we can very simply write:

user = User.find_by(id: params[:id])
user.posts

This gets increasingly more complicated as we start adding more models and relationships.

Additionally, ActiveRecord automatically creates methods to make using CRUD verbs simple and intuitive. We can also use ActiveRecord to validate a model before an instance is persisted to the database. We wouldn't want two users to have the same email address, or a post to have no content!

ActiveRecord is not only a powerful tool, but pretty fun to use! Happy persisting!

Photo by Ales Me on Unsplash

MVC - What is it?

Ronnie — Sat, 21 Nov 2020 01:29:38 +0000

Model. View. Controller.
What are those?

Model: They represent the data. That's it! They don't depend on controllers, but they can communicate with them.

View: They display the models data, by way of the controller and send user actions back to the controller.

Controller: They send model data to the view and interpret user actions.

What's the big deal?
MVC helps keep our concerns separated. We have three moving parts: data, display of data and communication between the two. Keeping these jobs separate makes creating simple and less buggy code a lot easier. If we had all that code in one file, we'd be pulling all of our hair out pretty quickly.

Real Life Example:
Let's think about it like we're going out to eat. You (a user) sit down at your table and take a look at a menu (sounds like a view to me). After a few minutes, you decide what you'd like to eat (a user request). Your server (controller) takes that order back to the kitchen (the model). After your server brings your order to the kitchen, the cooks start preparing it. If all goes according to plan, your server should be bringing the food you ordered back to your table in a reasonable amount of time. There is now a nice looking plate of food sitting in front of you, which may be the best kind of updated view there is!