DEV Community: Jose Aguilar

Creating a Rich Text Editor with TinyMCE and React

Jose Aguilar — Sun, 02 Jul 2023 00:14:21 +0000

Have you ever tried to build out a form that contains a field that requires a lot of text? For example a short bio for a user profile, or a cover letter field for a resume submission. You may want the text to be able to be styled and formatted as the user sees fit; multiple lines, paragraphs, perhaps even bullet points.

The first thing you'll notice is that, while you can format your text within the text field with multiple lines and paragraphs, the text is not rendered back in the same way it was formatted. The text is all together in a single line/paragraph.

Frustrating, isn't it? The reason for this is that when you submit text from a text area component, it is rendered in the DOM as a plain text element. In order to preserve formatting, we need a submit as rich text, and in order to do that we need a Rich Text Editor.

Luckily, implementing a basic text editor in your React application is a fairly straightforward process. In this article I will show you how to implement a rich text editor using TinyMCE.

This article assumes you've created your React app via create-react-app

Create a free TinyMCE account and receive an API key

Signup for a free TinyMCE account here.

In order to use TinyMCE, you'll need an API key. Once you've signed up for an account, your API key will be displayed in your dashboard.

Concealing your API key

If you're not familiar with how to conceal an API key, dotenv is the easiest and most popular solution. Follow the steps below:

Install dotenv via npm:
npm install dotenv --save
At the root of your app, create a file called .env
Inside .env, save your API key in the following format:
REACT_APP_TINYMCE_API = <Your API key>
Go to your .gitignore file and insert the path to your .env file at the bottom. For example:

# See https://help.github.com/articles/ignoring-files/ for more about ignoring files.

# dependencies
/node_modules
/.pnp
.pnp.js

# testing
/coverage

# production
/build

# misc
.DS_Store
.env.local
.env.development.local
.env.test.local
.env.production.local

npm-debug.log*
yarn-debug.log*
yarn-error.log*

#api
.env

Install and set up TinyMCE in your React project

In your React project install TinyMCE with the following command:
npm install --save @tinymce/tinymce-react

Once that's done, you'll need to set up your actual text editor component. In your src folder, create a file called TextEditor.js and insert the following code:

import { useRef } from "react";
import { Editor } from "@tinymce/tinymce-react"

export default function TextEditor() {
    const TINY_MCE_API_KEY = process.env.REACT_APPS_TINY_MCE_API
    const editorRef = useRef(null);

    function log() {
        const content = editorRef.current.getContent();
        console.log(content)
    }

    return (
      <>
        <Editor
          apiKey={TINY_MCE_API_KEY}
          onInit={(evt, editor) => editorRef.current = editor}
          initialValue="<p>This is the initial content...</p>"
          onEditorChange={log}
          init={{
            height: 300,
            menubar: false,
            plugins: [
              'advlist', 'autolink', 'lists', 'link', 'image', 'charmap', 'preview',
              'anchor', 'searchreplace', 'visualblocks', 'code', 'fullscreen',
              'insertdatetime', 'media', 'table', 'code', 'help', 'wordcount'
            ],
            toolbar: 'undo redo | blocks | ' +
              'bold italic forecolor | alignleft aligncenter ' +
              'alignright alignjustify | bullist numlist outdent indent | ' +
              'removeformat | help',
            content_style: 'body { font-family:Roboto,Helvetica,Arial,sans-serif; font-size:16px; line-height: 1; }'
          }}
        />
      </>
    );
  }

As you can see in the example code, the API key is accessed via process.env.REACT_APPS_TINYMCE_API. The content of the editor is being saved via the useRef() hook. We also have a function log() that will log the contents of the editor into the console via the onEditorChange prop.

Open up your console and start typing in the editor to see it in action:

As you may have already noticed, it's not just the text that's being logged into the console, but the corresponding HTML tags as well. This is important, as this will help us render the text properly in the end.

Rendering the editor content using html-react-parser

If we try to render the content as is, this is what we'll see:

Remember, even though the proper HTML tags are included. It's still just a regular string, so <p>hello world</p> is really "<p>hello world</p>".

In order to properly display this content, we need to convert our HTML string into one or more React elements. There are several tools for this, but my personal favorite is html-react-parser for its ease of use.

Install html-react-parser

npm install html-react-parser --save

Import the module

import parse from 'html-react-parser';

After that, it's just a matter of using the parse() function and passing an HTML string as an argument, for example parse('<h1>single</h1>'); or parse('<li>Item 1</li><li>Item 2</li>');. In this case, we want to pass the content of the editor as the argument.

Let's refactor our code a little to better see it in action.

import { useRef, useState } from "react";
import { Editor } from "@tinymce/tinymce-react"
import parse from 'html-react-parser';


export default function TextEditor() {
    const TINY_MCE_API_KEY = process.env.REACT_APPS_TINY_MCE_API
    const editorRef = useRef(null);
    const [textContent, setTextContent] = useState('')

    function log() {
        let content = editorRef.current.getContent();
        setTextContent(content)
    }

return (
      <>
        ...Editor component

        <button onClick={log}>Render Text</button>
        <br/>
        <div>
            {parse(textContent)}
        </div>
      </>
    );
  }

Now, we should be able to add rich text and have our styling and formatting preserved. Let's try copy/pasting some randomly generated text:

Much better!

Resources

Exception Handling and Validations in Rails, and how to display errors to users.

Jose Aguilar — Fri, 28 Apr 2023 15:00:19 +0000

Introduction

In this article we will go over exception handling and validation in Rails. Exception handling and validation are crucial for any web application, including those built with Rails; it's how we're able to display error messages that are useful not only to us as developers, but to our application users as well. How would you know if you entered the wrong username or password in an application without any validation or error handling?

First, a refresher(or introduction) on exceptions if you need it. Otherwise, skip ahead to the Validation section!

What is an exception?

You've already seen exceptions in action. For example, if you've ever made a typo in your code causing your program to crash with 'NoMethodError' or 'SyntaxError', you're seeing an exception being raised:

putss 'Hello World'
# => NoMethodError: undefined method 'putss' for main:Object
# => Did you mean? puts

An exception represents an error condition in a program. Exceptions are how Ruby deals with unexpected events, and they provide a mechanism for stopping the execution of a program. When an exception is raised, your program starts to shut down. If nothing halts that process, your program will eventually stop and print out an error message.

Exception Handling

Crashing programs are no bueno. Normally we want to stop the program from crashing and react to the error. This is called "handling" (also known as "rescuing" or "catching" an exception.

The basic syntax looks something like this:

#Imagine we write a function that would be called when an exception is raised.
def handle_exception
  puts "Got an exception, but I'm handling it!"
end

begin
  # Any exceptions in here...
rescue
  # ...will trigger this block of code
  handle_exception
end

# => "Got an exception, but I'm handling it!"

In this example, an exception is raised, but the program does not crash because it was "rescued". Instead of crashing, Ruby runs the code in the rescue block, which prints out a message. This is cool and all, but all this does is tell us that something went wrong, without telling us what went wrong.

Any information about what went wrong is going to be contained within an exception object.

Exception Objects

Exception objects (E.g. SyntaxError or ArgumentError) are regular Ruby objects(subclasses of the Exception Class). They contain information about "what went wrong" for the exception that was rescued.

To get an exception object, the rescue syntax is slightly different. In this example, we'll rescue from a ZeroDivisionError exception class.

#Rescues all errors, and assigns the exception object to an `error` variable
rescue => error

#Rescues only ZeroDivisionError and assigns the exception object to an `error` variable
rescue ZeroDivisionError => error

In the second example above, ZeroDivisionError is the class of the object in the error variable,ZeroDivisionError itself is a subclass of StandardError. The most standard error types in Ruby, such as ArgumentError and NameError are subclasses of StandardError. In fact, StandardError is the default exception for Ruby when an Exception subclass is not explicitly named.

begin
  do_something
rescue => error
  # This is the same as rescuing StandardError
  # and all of its subclasses
end

Now.. let's go back and take a closer look at the exception object for ZeroDivisionError

begin
  # Any exceptions in here...
  1 / 0
rescue ZeroDivisionError => error
  puts "Exception Class: #{error.class}"
  puts "Exception Message: #{error.message}"
end

# Exception Class: ZeroDivisionError
# Exception Message: divided by 0

Most Ruby exceptions contain a message detailing what went wrong.

Triggering Your Own Exceptions

You can also trigger your own exceptions! The process of raising your own exceptions is called.. well.. "raising". You do so by calling the raise method.

When raising your own exceptions, you choose which type of exception to use. You can also set your own error message.

begin
  #raises an ArgumentError with the message "You screwed up!"
  raise ArgumentError.new("You screwed up!")
rescue ArgumentError => error
  puts error.message
end

# => "You screwed up!"

Creating Custom Exceptions

Ruby's built-in exceptions are great, but they are still limited in scope and cannot cover every possible use case.

Suppose you're building a web app and want to raise an exception when a user tries to access a part of the site that they shouldn't have access to? None of Ruby's built-in exceptions really fit, so your best bet is to create a custom exception.

To create a custom exception, simply create a new class that inherits from StandardError.

class PermissionDeniedError < StandardError

  def initialize(message)
    # Call the parent's(StandardError) constructor to set the message
    super(message)
  end

end

# Then, when the user tries to do something they don't
# have permission to do, you might do something like this:
raise PermissionDeniedError.new("Permission Denied!!!")

The Exception Class Hierarchy

We made a custom exception by creating a subclass of StandardError, which itself is a subclass of Exception.
If you look at the class hierarchy, you'll see that everything subclasses Exception.

Don't worry, you don't need to memorize all of that. But it's important that you're familiar with class hierarchies in general for a very good reason.

Rescuing errors of a specific class will also rescue errors of its subclasses.

When you rescue StandardError, you not only rescue exceptions of StandardError but those of its children as well. If you look at the chart, you'll see that's a lot: ArgumentError, NameError, TypeError, etc.

Therefore, if you were to rescue Exception, you would rescue every single exception, which is a bad idea. Don't do this!

Ruby uses exceptions for things other than errors, so rescuing all errors will cause your program to break in weird ways. Always rescue specific exceptions. When in doubt, use StandardError.

Validation

Now that we have fair understanding of exceptions, let's look at validations and how it all ties in.

Many things that we do in our day to day lives can now be done online; whether it's shopping, banking, making dinner reservations, etc. But what's at the heart of all these processes? Data, it's all data.

Therefore, to ensure that everything runs smoothly, data integrity needs to be ensured. This is accomplished by validating the data that's provided before it can be saved to a database.

As you know, Rails is structured on the MVC architecture. The M, which is the model layer, is concerned with managing how objects are created and stored in a database. In Rails, this layer is run by Active Record by default, therefore, Active Record is concerned with handling the crucial task of data validation.

Validations are simply a set of rules that determine whether data is valid based on some criteria. Every model object contains an errors collection. In valid models, this collection contains no errors and is empty. When you declare validation rules on a certain model and it fails to pass, then an exception will be raised and that errors collection will contain errors consistent with the rules you've set, and this model will not be valid. A simple example is checking whether an online form has all the necessary data before it's submitted. If a field is left blank, an error message will be shown to the user so that they can fill it in.

Simple validations

Let's look at two basic validation methods.

Validating the presence and/or absence of attributes

This validation checks for the presence(or absence) of an attribute. In the example below, we're checking to see if the username attribute is not only present, but also unique. This helps you avoid having duplicate usernames within your application. You check these with the presence and uniqueness validation helpers respectively, using the validates keyword, followed by the attribute name:

class User < ApplicationRecord
   #validates presence and uniqueness of a username upon 
   #creation
   validates :username, presence: true, uniqueness: true
end

Validating character length on an attribute

For a password attribute, we can check if the password that we're trying to set meets our specified requirements. In this case, we're making sure that it has a minimum length of 8 characters with the length helper:

class User < ApplicationRecord
  validates :username, presence: true, uniqueness: true
  #validates minimum length of 8 characters
  validates :password, length: { minimum: 8 }
end

Working with Validation Errors

So how do you handle a validation error? As mentioned earlier, when a validation fails, an exception is raised and an errors collection is generated.

Let's see what happens when we try to create a user account with a password that is less than 8 characters:

class User < ApplicationRecord
  validates :username, presence: true, uniqueness: true
  validates :password, length: { minimum: 8 }
end

user = User.create(username: admin, password: "Welcome")

pp user

# => #<User:0x00007fd0cca748e8
# id: nil,
# username: "admin",
# password: "Welcome",
# created_at: nil,
# updated_at: nil>

We get back what appears to be a User instance, but upon closer inspection we see that the id attribute is nil, meaning the User instance wasn't saved to the database. Good to know, but we need to see why exactly this record is invalid. To raise an exception and see more details about the error, we need to append a bang(!) to our create method:

class User < ApplicationRecord
  validates :username, presence: true, uniqueness: true
  validates :password, length: { minimum: 8 }
end

user = User.create!(username: admin, password: "Welcome")

# => ActiveRecord::RecordInvalid (Validation failed: Password is # too short (minimum is 8 characters))

Here we get a RecordInvalid exception, one of many exception subclasses of ActiveRecordError, which itself is a subclass of StandardError. See the list of Active Record exceptions here.

RecordInvalid is raised when a record cannot be saved to the database due to a failed validation. In this case, our password was too short.

Remember I mentioned that an errors collection is also generated? Here's how to access it:

class User < ApplicationRecord
  validates :username, presence: true, uniqueness: true
  validates :password, length: { minimum: 8 }
end

user = User.create!(username: nil, password: "Welcome")
# => ActiveRecord::RecordInvalid (Validation failed: Username can't be blank, Password is too short (minimum is 8 characters))

#Accesses an array of error messages from the `errors` object.
user.errors.full_messages
# => ["Username can't be blank", "Password is too short (minimum is 8 characters)"]

Having an easily accessible array of validation errors is useful because we can communicate them to the frontend.

Going back to our User model, let's add a create method to create a new user account.

def create
    #remember to append a "!" to your create method
    user = User.create!(user_params)
    session[:user_id] = user.id
    render json: user, status: :created
end

private

def user_params
    params.permit(:username, :password, 
    :password_confirmation)
end

Now in the event of a failed validation, in this case a blank username and/or a short password, a RecordInvalid exception will be raised. You can now add some conditional logic to display errors back to the frontend, let's update our create method:

def create
  begin
    user = User.create!(user_params)
    session[:user_id] = user.id
    render json: user, status: :created
  rescue ActiveRecord::RecordInvalid => exception
    render json: {errors: 
    exception.record.errors.full_messages}, status: 
    :unprocessable_entity
  end
end

In our rescue block, we are passing in the exception as an argument and accessing our errors collection located at exception.record.errors.full_messages. Then we wrap it up in a nice JSON format so that it may be passed to the frontend, with a HTTP status code of 422 aka Unprocessable Entity using the status: method. You could also just type status: 422, but this is more readable.

Isn't there an easier way?

You can see how this can get repetitive fast, especially if you're working with multiple models and controllers. You'd have to have the same begin/rescue block in all create actions throughout your controllers just to handle this one exception. Thankfully there's a way to abstract away some of this logic and make your life easier.

In Rails, you'll notice each controller inherits from ApplicationController, and thus inherits all of its methods. We can take advantage of this by moving the logic for handling a RecordInvalid exception up to ApplicationController, but we'll do it a little differently this time:

class ApplicationController < ActionController::API
   #rescue_from takes an exception class, and an exception 
   #handler method
   rescue_from ActiveRecord::RecordInvalid, with: 
   :unprocessable_entity_response

   private

   def unprocessable_entity_response(exception)
     render json: {errors: 
     exception.record.errors.full_messages}, status: 
     :unprocessable_entity
   end
end

Instead of a begin/rescue block, we'll use the rescue_from method, which takes an exception class, and an exception handler specified by a trailing with: option containing the name of an exception handler method. In this case we created a private class method called unprocessable_entity_response. So, when the specified exception is raised, rescue_from will pass the exception object to the exception handler specified in the with: option.

On the frontend...

Displaying validation errors on the frontend is as simple as getting them through a fetch request and using conditional rendering to display them to a user when a validation error occurs.

This is an example from an account sign up form that I made previously using React:

function SignupForm() {
    const [username, setUsername] = useState("")
    const [password, setPassword] = useState("")
    const [passwordConfirmation, setPasswordConfirmation] = 
    useState("")

   //Any validation errors that are returned will be stored 
   in state...
    const [errors, setErrors] = useState([])

    async function handleSubmit(e) {
        e.preventDefault();

        const res = await fetch("/api/signup", {
            method: "POST",
            headers: {
                "Content-Type": "application/json"
            },
            body: JSON.stringify({
                username,
                password,
                password_confirmation: passwordConfirmation
            })
        })

        if (res.ok) {
            const user = await res.json()
            setUser(user)
        } else {
            //if the fetch request fails and returns an error 
            object, the errors will be stored in state using 
            setErrors
            const err = await res.json()
            setErrors(err.errors)
        }

    }

In the return statement, you can use conditional rendering to display the errors if they are present in the errors array in state:

return (
   {errors.map((err) => <Alert key={err} severity="error">{err}</Alert>)}
)

The result:

Resources

https://guides.rubyonrails.org/active_record_validations.html
http://www.railsstatuscodes.com/
https://www.rubydoc.info/docs/rails/4.1.7/ActiveRecord/ActiveRecordError
https://ruby-doc.org/core-2.5.1/Exception.html

The basics of Object-Oriented Programming in Ruby

Jose Aguilar — Wed, 09 Nov 2022 23:03:39 +0000

In this post I will be going over Object-Oriented Programming (OOP) and object-orientation in Ruby. If Ruby is your first OOP you may have come across this concept and perhaps found it a little tricky, well you're not alone! We'll go over what object-oriented programming is and its application in the Ruby language.

What is Object-Oriented Programming?

Wikipedia defines OOP as follows

Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects", which can contain data and code: data in the form of fields (often known as attributes or properties), and code, in the form of procedures (often known as methods).

In other words, the underlying concept of OOP is that everything is an object. Objects, as we know, contain data in the form of attributes (also known as properties) and functions that run some code (also known as methods). The most common form of OOP is class-based. In class-based OOP, objects are defined via classes, which act as an abstract, reusable template (or blueprint) for instances (objects) of that class. For example, an object(aka instance) named bob could belong to a class named Person, or an object named dog could belong to a class named Animal, and so on. A class can also define the names of attributes and/or methods an instance of said class should have, the instance will then inherit the attributes and methods of the parent class when it's created.

Let's look at an example:

Source: https://www.educative.io/blog/object-oriented-programming

In the above example, there is a class (Car) that contains attributes representing the color, brand, and model of a Car object. We can then instantiate 2 objects from the class Car (myCar and helensCar) that will inherit the attributes and methods of its parent class (Car).

Here's an example of what this looks like in Ruby:

#Classes in Ruby and other OOP languages follow the camel case rule; names must be uppercase and no spaces are allowed.
class Car
  def initialize(color, brand, model)
    @color = color
    @brand = brand
    @model = model
  end

#Instance methods are declared in the parent class and are available across all instances of the parent class.
  def repaint(new_color)
    @color = new_color
  end
end

#Instantiates a new object (charger) with the .new method
charger = Car.new('red', 'Dodge', 'Charger')

p charger 
# => #<Car:0x00000000012973d0 @color="red", @brand="Dodge", @model="Charger">

charger.repaint('blue')

p charger 
# => #<Car:0x00000000012973d0 @color="blue", @brand="Dodge", @model="Charger">

An object is instantiated by calling the .new method on a class followed by the arguments that will become the instance variables (attributes) of that instance. Any methods declared in the parent class will automatically be inherited. In order to create an object with the instance variables of the parent class, a special method is needed: initialize.

The Initialize method and instance variables/methods.

When instantiating an object, more often than not you will be passing one or more arguments to create instance variables for that object. In order to accomplish this, you will first need to declare a special Ruby method in the parent class, called initialize.

Lets look at that method from the previous example:

def initialize(color, brand, model)
    @color = color
    @brand = brand
    @model = model
end

If you've come across object-orientation in other languages, such as JavaScript, this is also known as a constructor method. It is a special method that is used for creating and initializing an instance object of a class.

You'll notice that within the method are variables being declared with a leading @ character. The @ character symbolizes an instance variable. Instance variables are variables that are available across all instances of a class. In the previous example, every object that's instantiated from the Car class with have the variables @color, @brand, and @model with their own given values. The repaint method is an instance method, and thus will also be available to all instances of that class.

Getter/Setter methods

In order to directly access object variables from outside of the class, i.e. to be able to call charger.color and have it return red, we need to implement getter methods. A getter method is simply a method that allows you to read the value of an instance variable.


class Car

  #...

  #Getter methods defined below
  def color
    @color
  end

  def brand
    @brand
  end 

  def model
    @model
  end
end

charger = Car.new('red', 'Dodge', 'Charger')

p charger.color 
# => "red"

p charger.brand 
# => "Dodge"

p charger.model 
# => "Charger"

We defined 3 getter methods named after an instance variable and simply had them return the value of that variable. Pretty straightforward!

If we didn't have a getter method for an instance variable, we would get an error when trying to read the variable:

charger.color 
# => undefined method `color' for #<Car:0x00000000012973d0> (NoMethodError)

Now what if we wanted to change the value of a variable? Since we can now access variables directly using getter methods, we should just as easily be able to change the values of said variables... right?

charger.color = 'blue'
# => undefined method `color=' for #<Car:0x0000000002616668> (NoMethodError)
#Did you mean?  color

Notice the part that reads undefined method 'color=', then the part that reads Did you mean? color. color is an already established getter method within our class, however color= is not currently an existing method, hence the error.

The trailing = character in a method name (such as color=) designates a method as a setter method, therefore color and color= are two totally separate methods.

Setter methods are set up like so:

class Car

#...

 #Setter methods defined below
  def color=(color)
    @color = color
  end

  def brand=(brand)
    @brand = brand
  end 

  def model=(model)
    @model = model
  end
end

Now, we're able to both read variable values as well as change them.

p charger.color
# => "red"

charger.color = 'blue'
p charger.color
# => "blue"

A little factoid: Since = symbolizes a setter method. We can also call our method like charger.color=(blue) and get the same result. Thankfully, thanks to syntax sugar we are able to write it as charger.color = 'blue' for better readability.

Accessor methods

Now if you're thinking that having to write getters and setters for every single variable is a lot of work, you thought right. A cornerstone of coding is the DRY principle, and writing repetitive code is not only time consuming but ugly to look at.

Thankfully, Ruby gives us an easy way to set up our getters and setters in one line of code! Enter accessor methods.

There are 3 accessor methods available to make our lives easier:

attr_reader: For creating getter methods
attr_writer: For creating setter methods
attr_accessor: For creating both getter and setter methods at once!!

attr_accessor allows us to create both getters and setters in a single line of code. Let's refactor our code to use this method.

class Car
#Accessor methods
  attr_accessor :color, :brand, :model

  def initialize(color, brand, model)
    @color = color
    @brand = brand
    @model = model
  end

  def repaint(new_color)
    @color = new_color
  end
end

We call attr_accessor and pass in our variable arguments as Symbols. This creates both attr_reader and attr_writer for each variable all in one line.. much better!

Everything is an object

Going back to the concept of everything is an object, does that mean that strings, arrays, numbers, etc are objects too? Yes, they are!

When you create an array or a string, you are creating an object from a built-in Ruby class!!

We can demonstrate this by calling the .class method, which shows us the class the object belongs to.

p [].class
# => Array

p "Hello World".class
# => String

p 123.class
# => Integer

Arrays, strings, and numbers belong to the Array, String, and Integer classes respectively. These are some of the built-in classes within Ruby with their own methods and variables. Think about when you're using the .capitalize or .reverse method on a string, those are instance methods belonging to the String class!

Conclusion

These are some of the basics of object-oriented programming in Ruby. With this knowledge you're ready for other OOP concepts such as self, class variables, and class methods. Good luck and have fun!

Sources

Separation of Concerns and Single Source of Truth — writing cleaner code.

Jose Aguilar — Wed, 07 Sep 2022 20:34:23 +0000

In this post I am going to explain the principle of Separation of Concerns (SoC). Applying Separation of Concerns and Single Source of Truth to your applications makes your code easier to debug (there's no escaping it, sorry) and easier to maintain in the future. So let's dive right in...

What is Separation of Concerns?

Wikipedia defines Separation of Concerns as follows:

In computer science, separation of concerns is a design principle for separating a computer program into distinct sections. Each section addresses a separate concern, a set of information that affects the code of a computer program.

Separation of Concerns refers to abstracting away parts of a computer program into modules that deal with a single feature or behavior. In other words – each module should be responsible for one thing, and one thing only.

A classic example of Separation of Concerns is a web page, which is typically built using a combination of HTML, CSS, and JavaScript.

Consider the following example:

<html>
<head>
<style>
 body {background-color: black;}
 h1 {color: white;}
 p {color: blue;}
</style>
</head>
<body>

 <h1>Hello World!</h1>
 <p>Here is a paragraph</p>

</body>
<script>
console.log("Hello World!")
</script>
</html>

This is perfectly working code that would give you a perfectly working page, but what if you need to add more code and your page grows in size? This is where things get messy, because our layers: page structure (HTML), styling (CSS) and behavior/logic (JavaScript) are all mixed in together in a single file. This makes scalability, maintainability, and debugging a lot messier down the line.

The right way to structure it would be something like this:

<!--index.html-->
<html>
 <head>
  <link rel="stylesheet" href="styles.css">
 </head>
 <body>

  <h1>Hello World!</h1>
  <p>Here is a paragraph</p>

 </body>
 <script src="logic.js"></script>
</html>

/* styles.css */
body {background-color: black;}
h1   {color: white;}
p    {color: blue;}

// logic.js
console.log("Hello World!")

The three layers have been separated into their own files, making this code a lot cleaner. Each language is designed to handle a different concern of a website, with minimal overlap.

Source: https://www.srinadimpalli.com/2015/08/unobtrusive-javascript-layering-and-separation-of-concerns/

We see the same principle applied in React, where a UI is separated out into different components, each responsible for rendering a distinct part of an interface.

Source: https://www.techdiagonal.com/reactjs_courses/beginner/understanding-reactjs-components/

Each component is responsible for, or concerned with, only one thing.

Cohesion

Naturally, separation of concerns is a consequence of writing cohesive code, especially in Object-Oriented Programming.

For instance, suppose you have two separate functions like this:

function drawSquare() {
 //code to draw a square
}

function drawCircle() {
 //code to draw a circle
}

These two functions are similar (or cohesive) enough that they can be grouped together under a single class, since they have a unifying purpose: to draw something.

class Draw {

  static drawSquare() {
    // code to draw a square
  }

  static drawCircle() {
    // code to draw a circle
  }
}

Draw.drawSquare() // draws a square
Draw.drawCircle() // draws a circle

Separation of concerns allows data and methods related to a single purpose to take place within a class, where they are not only easy to keep track of but are also kept separate from other classes. If you need to change something, it's easier to keep track of what needs to change, since concerns are separated into cohesive classes, where data and logic resides in one place. In the programming world, this is also known as the Single-responsibility principle (SRP).

Single Source of Truth

Speaking of cohesiveness, there's another similar but equally important principle: Single Source of Truth (SSoT).

In the business world, the Single Source of Truth principle states that data within an organization should be aggregated into a central location, so that all users get their information from a single source, and that data should not be replicated anywhere else.

This applies to programming as well. Data that needs to be available to other parts of your application should come from a single source, and any changes to that data are reflected within that single source and nowhere else. This ensures that the data available to other components of your application is reliable and up to date.

If you've been coding in React, this should sound familiar. You've likely implemented state for a particular set of data (such as one fetched from an API) to be a single source of data for most, if not all of your application.

For example:

function App() {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    const fetchUsers = async () => {
      const response = await fetch('https://jsonplaceholder.typicode.com/users'); //fetch data
      const userData = response.json();
      setPhotos(userData); // set state to fetched data
    }

    fetchUsers();
  })
}

Here we fetched user data from a mock API, and set it to state so that it's the single source of user data for the rest of your React application.

So when your app renders additional components that need access to that data, you can pass that data from that single source as props to the rest of your components that need it.

function App() {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    const fetchUsers = async () => {
      const response = await fetch('https://jsonplaceholder.typicode.com/users'); //fetch data
      const userData = response.json();
      setPhotos(userData); // set state to fetched data
    }

    fetchUsers();
  })

 return (
    <UsersContainer userData={users} />
  )
}

// UsersContainer.js

function UsersContainer({ userData }) {
  return {userData}
}

You get the idea.

This is also known as one way data binding. It means that there is only one place which represents state for this set of data, and your components listen to it. Any components that render data based on this state will only render different data if the data at the source is changed.

Another example is when you're dealing with forms. Suppose we want to build a form that gets data for its input fields from state, how would that be structured?

You could do this:

function Form() {
  // separate states for each input field
  const [name, setName] = useState("")
  const [address, setAddress] = useState("")
  const [phone, setPhone] = useState("")

  // set state for the name
  function handleName(event) {
    setName(event.target.value)
    };

  // set state for the address
  function handleAddress(event) {
    setAddress(event.target.value)
    };

  // set state for the phone number
  function handlePhone(event) {
    setPhone(event.target.value)
    };

   function handleSubmit(event) {
    //handle form submit logic here
  };

  return (
    <form onSubmit={handleSubmit}>
      <input
        type="text"
        name="name"
        onChange={handleName}
        value={address}
      />
      <input
        type="text"
        name="address"
        onChange={handleAddress}
        value={address}
      />
      <input
        type="text"
        name="phone"
        onChange={handlePhone}
        value={handlePhone}
      />
      <button type="submit">Submit</button>
    </form>
  );
}

Notice how each input field has its own state, and the input fields within the form set state for their respective inputs. That would work, but it's pretty messy. Do all input fields need to have their own state? Or is there a way to refactor this so that not only does it make our code cohesive, but it makes our form look to a single source of truth for our data, as opposed to three separate sources.

Going back to the topic of cohesion, our name, address, and phone number states all serve the same purpose: to store data for one form. Should each piece of data have it's own state? Or can we have all of them together under one state?

We can re-factor as follows:

function Form() {
  // one state, a single source, for our form data.
    const [formData, setFormData] = useState({
      name: "",
      address: "",
      phone: "",
    })

    function handleChange(event) {
      const {name, value} = event.target

      setFormData({
        ...formData,
        [name]: value
      })
    }

   function handleSubmit(event) {
    //handle form submit logic here
  };

  return (
    // a single function for our onChange event, not 3 separate ones
    <form onSubmit={handleSubmit}>
      <input
        type="text"
        name="name"
        onChange={handleChange}
        value={formData.name}
      />
      <input
        type="text"
        name="address"
        onChange={handleChange}
        value={formData.address}
      />
      <input
        type="text"
        name="phone"
        onChange={handleChange}
        value={formData.phone}
      />
      <button type="submit">Submit</button>
    </form>
  );
}

Now, we've not only trimmed our code significantly. We've implemented a single source of truth for our form and made our logic more cohesive overall.

Conclusion

I hope you've gained a better understanding for the principles of Separation of Concerns and Single Source of Truth. Having organized, modularized code will always make your life easier down the road, as well as the lives of your peers :)

References:

*http://anh.cs.luc.edu/170/mynotes/cohesion.html
*https://en.wikipedia.org/wiki/Separation_of_concerns
*https://en.wikipedia.org/wiki/Cohesion_(computer_science)

Deploying your first React app a with json-server backend on Heroku and Netlify

Jose Aguilar — Wed, 17 Aug 2022 21:01:36 +0000

So you've taken on a project and have written your first app in React(congrats btw!) and you're looking to put it up on the web for all to see. Fortunately, it's an easy and straightforward process! In this article, I'll be going over how to deploy a React app using Netlify and Heroku.

This article assumes that your app uses json-server as a fake REST API

What is Heroku? What is Netlify?

Heroku and Netlify are both services for used for hosting web applications. The main difference between the two is that Netlify is more geared toward front-end development, while Heroku is geared towards the back-end. One could host a full stack web application on Heroku. However, Netlify can only host serverless web apps and static web pages.

It's considered good practice to keep your front-end and back-end separate, one major reason being that debugging becomes easier. If something goes wrong in your app, you'll easily be able to tell if the problem is in the front-end or the back-end.

Deploying your API on Heroku

There is an excellent guide on deploying a json-server backend by Jesper Orb at https://github.com/jesperorb/json-server-heroku which we'll be using for this portion of the guide.

Creating your database

First, you'll need to create your database. Click on the following link: https://github.com/jesperorb/json-server-heroku/generate to create a repository with the necessary files needed to deploy. Give your repository a name, then click Create repository from template at the bottom.

Once the repository is created, clone the newly created repository to your computer.
Go to the db.json file in that repository, you should see some example code like this:

{
  "posts":[
    {
      "id" : 0,
      "title": "First post!",
      "content" : "My first content!"
    }
  ],
  "comments" : [
    {
      "id": 0,
      "content": "Wow such content!",
      "username": "zero_cool"
    }
  ]
}

This example would create a /posts and a /comments route for GET and POST requests. It's an example of what your own data structure should ideally look like.

Replace the contents of db.json with your own data. Then commit and push your changes to GitHub.

If your id property has a name other than id, it's a good idea to rename it to avoid issues (I found this out the hard way). If you have a rather large JSON file with a lot of data and are using VS Code, you can select the property you want to edit with your cursor, then press Command + Shift + L on Mac or CTRL + Shift + L on Windows to add a cursor to all instances of that property name, then simply type the new name to update all of the property names at once.

Deploying to Heroku

First, create a free Heroku account at https://heroku.com/
Install the Heroku command line tool on your computer.
- If you have Homebrew installed, run the following command (this is the preferred installation method):

 $ brew tap heroku/brew && brew install heroku

Otherwise, you can install via NPM with the following command:

  $ npm install -g heroku

If installing via NPM, just be aware of the following warning from Heroku:

You can then verify that the installation by running heroku --version

Log in by running the heroku login command. When prompted, press any key to open your browser and log in with your credentials.

$ heroku login

heroku: Press any key to open up the browser to login or q to exit
 ›   Warning: If browser does not open, visit
 ›   https://cli-auth.heroku.com/auth/browser/***
heroku: Waiting for login...
Logging in... done
Logged in as me@example.com

Once you're logged in, cd to the repo you cloned earlier and run the following command:

$ heroku create

$ heroku create <your-app-name>

$ heroku create

 Creating sharp-rain-871... done, stack is heroku-18
 http://sharp-rain-871.herokuapp.com/ | 
 https://git.heroku.com/sharp-rain-871.git
 Git remote heroku added

Push your app to Heroku:

$ git push heroku master

Open your newly created Heroku app, you should see your live API:

$ heroku open

Note: At this point, you should update the fetch requests in your React code to point to your Heroku app i.e. change your endpoint from http://localhost:3000/<resource> to http://<your-app-name>.herokuapp.com/<resource>

Deploying your React app on Netlify

Now, you'll be deploying your front-end code on Netlify. First, create your free Netlify account at https://www.netlify.com/

Creating a production ready build of your app

Before doing anything, you'll need to create a production build of your app. In your terminal, type npm run build. This command will create a build directory at the root of your project with a production build of your app.

Configuring redirects

If you're deploying an app that uses a router (such as React Router), you'll need to configure redirect rules for your URLs. Otherwise, when you click on a navigation link to go to another page and then refresh, you will get a 404 error page.

In your build folder, create a file named _redirects. Inside the file, add the following rule:

/*    /index.html  200

Now, no matter what URL the browser requests, the user will be served an index.html file. No more refresh errors.

See more info about redirects and rewrites here: https://docs.netlify.com/routing/redirects/

Now.. you're ready to deploy your app!

Method A: Drag and Drop (fastest way)

This is by far the fastest and easiest way to deploy your app.

In your Netlify dashboard, click on Add new site then select Deploy manually
Find the build folder in your project directory, then simply drag and drop the folder into Netlify.

Your app will be given a randomly generated name, you can change this name later.
Depending on the size of your project, it may take some time for the app to upload.
Once the site is deployed, click on your app URL to see your live app.

Method B: Netlify CLI

Netlify also provides a command line tool to deploy your app straight from your terminal.

Install the Netlify CLI with the following command:

$ npm install netlify-cli -g

Once it's installed, make sure you're in your project directory first, then run the following command:

$ netlify deploy

You'll get a pop-up browser window asking you to log in with your Netlify credentials and grant access to the Netlify CLI.
In your terminal, you'll see a prompt saying This folder isn't linked to a site yet. What would you like to do?
Since we're deploying a new site, select Create & configure a new site

Choose a name for your site, or leave it blank to get a randomly generated name (you can change the name later).

Provide the publish directory. This is the build directory you created earlier when you ran npm run build
Simply type build and press enter
You'll see a Website Draft URL, which you can copy/paste into your browser. This is essentially a preview of what the live app will look like.

If everything looks good on your draft URL, deploy your app into production with the following command:

$ netlify deploy --prod

You will once again be asked to provide the publish directory, type build again and hit enter.
Your site will be deployed. You'll see two URLs, a Unique Deploy URL and the actual Website URL. The Unique Deploy URL represents the unique URL for that specific deployment. Each time you update your app and deploy a new version, you're going to get a unique URL for that deployment, which means it's possible to see previous versions of your app by going to their corresponding unique URL.

I hope you've found this article to be helpful. If there are any errors or if you think there's some extra info I should add, please let me know!

The power of destructuring in JavaScript

Jose Aguilar — Sat, 18 Jun 2022 19:40:59 +0000

Hello! My name is Jose and this is my very first DEV post! I am currently a Software Engineering student at Flatiron School, or in other words a newbie. My journey thus far has been quite challenging but rewarding and honestly, also fun!

Perhaps you're a beginner as well and are looking to pick up some a trick or two, well you've found the right place! One of the things I love as I continue to learn JavaScript is coming across cool shorthand techniques that help you achieve your goals with more concise code. In this post I will talking about one of my favorites, destructuring.

What is destructuring?

The MDN defines destructuring assignment as follows:

The destructuring assignment syntax is a JavaScript expression that makes it possible to unpack values from arrays, or properties from objects, into distinct variables.

Let's explore this with some examples...

Object destructuring

You're probably already familiar with objects and how we can save property values in variables.

Consider the following example:

const employee = {
  firstName: "Peter",
  lastName: "Gibbons",
  jobTitle: "Programmer",
  programmingLanguage: "JavaScript"
};

const firstName = employee.firstName;
const lastName = employee.lastName;
const jobTitle = employee.jobTitle;
const programmingLanguage = employee.programmingLanguage;

console.log(firstName); //LOG: "Peter"
console.log(lastName); //LOG: "Gibbons"
console.log(jobTitle); //LOG: "Programmer"
console.log(programmingLanguage); //LOG: "JavaScript"

This works perfectly fine and achieves what we want to do, but that's a lot of typing... We have to explicitly name each property with the employee object in dot . notation, then declare variables accordingly.

But there's a better way, a way that's more concise and just.. cooler looking.

const employee = {
  firstName: "Peter",
  lastName: "Gibbons",
  jobTitle: "Programmer",
  programmingLanguage: "JavaScript"
};


const { firstName, lastName, jobTitle, programmingLanguage } = employee;


console.log(firstName); //LOG: "Peter"
console.log(lastName); //LOG: "Gibbons"
console.log(jobTitle); //LOG: "Programmer"
console.log(programmingLanguage); //LOG: "JavaScript"

The left side of the expression contains variables that correspond to the properties of the object that we're working with, wrapped in curly braces { }. The right side of the expression is the object itself.

Source: https://www.educative.io/answers/what-is-object-destructuring-in-javascript

Pretty cool isn't it? We're able to define multiple variables each corresponding to an object property, all in one line of code.

Now, imagine a scenario where you wanted to declare a variable in advance without initializing it. What would happen if we tried to use destructuring assignment to assign a property value to our variable without using let or const?

let firstName;

const employee = {
  firstName: "Peter",
  lastName: "Gibbons",
  jobTitle: "Programmer",
  programmingLanguage: "JavaScript"
};

{ firstName } = employee;

console.log(firstName); //Uncaught SyntaxError: expected expression, got '='

The let and const keywords are essential to destructuring assignments. Because neither were used, JavaScript tried to interpret what was within our curly braces { } as a block of code.

In this scenario, the correct syntax would be to encase the destructuring expression in parentheses ( )

({ firstName } = employee)

console.log(firstName) //LOG: "Peter"

Creating aliases

Now, what if we want to define some variables with names of our own choosing? Luckily we can do that:

const employee = {
  firstName: "Peter",
  lastName: "Gibbons",
  jobTitle: "Programmer",
  programmingLanguage: "JavaScript"
};


const { jobTitle: title, programmingLanguage: language } = employee;


console.log(title); //LOG: "Programmer"
console.log(language); //LOG: "JavaScript"

So, as you can see, the syntax is { propertyName: alias }
Note that attempting to access either jobTitle or programmingLanguage would result in an error.

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

Array destructuring

Destructuring is also possible with arrays, and it makes extracting data from an array much more simple.

Fortunately, unlike destructuring assignments with objects, our variable names do not need to match the name of each item:

const animals = ["dog", "cat", "bird"];
const [animal1, animal2, animal3] = animals;

console.log(animal1); //LOG: "dog"
console.log(animal2); //LOG: "cat"
console.log(animal3); //LOG: "bird"

With array destructuring assignment, we encase our variable(s) in an array literal [ ], each variable maps to the exact position of the array element.

If the number of variables exceed the number of elements in the array, the last variable will simply return undefined.

const animals = ["dog", "cat", "bird"];
const [animal1, animal2, animal3, animal4] = animals;

console.log(animal4) //LOG: undefined

Also unlike object destructuring, with arrays we can declare variables in advance and initialize later, without the need to wrap our assignment in parentheses:

let a, b, c;
const arr = [1, 2, 3];

[a, b, c] = arr

console.log(a) //LOG: 1
console.log(b) //LOG: 2
console.log(c) //LOG: 3

Working with an array returned from a function

Destructuring with an array return value makes syntax more concise:

function returnArray() {
   return [1, 2, 3];
}

let a, b, c;
[a, b, c] = returnArray();

console.log(a) //LOG: 1
console.log(b) //LOG: 2
console.log(c) //LOG: 3

Rest parameters

Instead of having to create a variable for every element in an array, rest parameters allow you to work with arrays with an indefinite number of elements. The syntax is similar to that of the spread operator. The elements that are 'left over' are collected into another array:

let a, b, rest;

[a, b, ...rest] = [10, 20, 30, 40, 50]

console.log(a) //LOG: 10
console.log(b) //LOG: 20
console.log(rest) //LOG: Array [30, 40, 50]

There you have it. Go ahead and use these in your next project; make your code more concise, and your life easier!