DEV Community: Konstantin Stanmeyer

Image Compression in JavaScript/TypeScript

Konstantin Stanmeyer — Thu, 30 Nov 2023 00:00:18 +0000

Introduction

The following approach allows for increased file compression, inherently lowering file size as well as an added ability to store images in Base64-encoded strings if desired.

Behind-the-Scenes (Base64)

To dive slightly deeper into what's involved in this process we can look at what a Base64 string actually is, and how we can use it within a canvas and img tag to create a new, usable version of an image.

When given an image file (PNG, JPG, JPEG, etc.), the binary information can be extracted into our new format, Base64, which is simply a string used to transport a sequence of 6-bit Base64 characters. These characters are utilized for many use-cases, mostly in web-pages and emails since HTML can easily rely on converting these text-assets to their visual equivalent.

Now, how exactly does our computer manage to convert these values to and from text? To not go into unnecessary detail, we can look at this conversion table:

Basically, the binary stream taken from an image file gets converted to its appropriate code points, and that information gets appended to the Base64 string.

Once we receive our new string from the computer our HTML code can interpret this data and display an image for us, in somewhat of a "URL". Here is an example url's first 50 characters:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAApEAA

NOTE: When storing images as a Base64 string, they will take up 1/3 more space within storage than the original file. "[This] causes an overhead of 33–37% (33% by the encoding itself; up to 4% more by the inserted line breaks)." -Wikipedia (MORE INFO)

Then, as you will see later on in this blog, that image can be used within a canvas tag, where HTML allows us to resize this by passing in a height and width variable, along with a "quality" parameter, where the image will be compressed.

The Process

There are many ways to initially approach this problem within a project, this will show my implementation in a recent TypeScript/React environment.

First, we must get the desired image via a form as so:



import { ChangeEvent, useState } from "react";

export default function ImagePage() {
   const [imageUrl, setImageUrl] = useState<string>("")

   async function handleFileUpload(e: ChangeEvent) {
      // not-so-pretty typescript handling
      const target = e.target as HTMLInputElement;
      const file: File = (target.files as FileList)[0];
   }

   return (
      <>
         <input 
            type="file"
            accept=".jpeg, .jpg, .png"
            onChange={(e: ChangeEvent) => handleFileUpload(e)}
         />
         <img src={imageUrl} />
      </>
   )
}

In the code above we are having an EventListener wait for an image file to be uploaded, then we are storing it inside our constant file.

Next, we have to convert this file to a Base64 string. Here, we can use an instance of FileReader to extract the data in the desired format.

This handler function is simple yet powerful:



export default function convertToBase64(file: File): Promise<string>{
   return new Promise((resolve, reject) => {
      const fileReader = new FileReader();

      // where the conversion occurs, handled by .readAsDataUrl(...) which will return us a Base64 string
      fileReader.readAsDataURL(file);

      fileReader.onload = (e: ProgressEvent<FileReader>) => {
         resolve(fileReader.result as string);
      }

      fileReader.onerror = (e) => reject(e);
   }
}

As we can see, most of the work is done for us. Now the remaining steps involve taking that value, figuring out how to pass the associated image into a canvas, and ensuring said canvas is displaying the information at our desired resolution/size.

We can go back to the ImagePage function, or more specifically our handleFileUpload function, where we can now add our Promise to get the desired value. Then, we will do a workaround to pass the rendered image into our canvas tag, which will draw the information at the quality we desire. Last, that newly drawn image will be the compressed file which we can display onto a new img tag to ensure it has been been successfully compressed. If this sounds confusing, the code will likely clear up any questions:



const WIDTH = 100;

async function handleFileUpload(e: ChangeEvent){
   try {
      const target = e.target as HTMLInputElement;
      const file: File = (target.files as FileList)[0];

      const imageString = await convertToBase64(file);

      let img = document.createElement("img");
      img.src = imageString;

      // we are waiting until the image has rendered by targeting its onload event, which is required when we'd like to get a height and width to use for the final output's length:width ratio
      img.onload = (e: any) => {
         // set a width value for the height of the produced image to depend on (i.e. WIDTH = 100 will be 100px)
         let canvas = document.createElement("canvas");
         let ratio = WIDTH / e.target.width;

         canvas.width = WIDTH;
         canvas.height = e.target.height * ratio;

         // context is where the canvas references to know what data to render
         const context = canvas.getContext("2d") as CanvasRenderingContext2D;

         // "compression" occurs below, where the new image is drawn onto the canvas based on the parameters we pass in
         // the second and third parameters tell the canvas where to place the image within its render, starting from the top left corner (i.e. a value greater than 0 will add whitespace from top-down, left-to-right
         // referencing https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/drawImage
         context.drawImage(img, 0, 0, canvas.width, canvas.height);

         // here we specify the quality, which is the second argument in .toDataUrl(...) | here the output should be 50% the quality of the original, lowering the detail and file size
         let newImageUrl = context.canvas.toDataURL("image/jpg", 50); // quality ranges 1-100
         // below is not necessary (used for testing)
         setImage(newImageUrl);
      }
   } catch (e: Error) console.log(e);
}

Converting Compressed Image to a Usable File

Now we have our new, compressed image within a canvas. We can then revert this new image to a Base64 string that JavaScript will know how to handle. To pseudocode this process it would look something like so:



(1) fetch the image content from the canvas tag

(2) convert the image's content to a Base64 string

(3) convert the Base64 string into a Blob object

(4) pass the Blob into a new File object, along with the desired file name and type

For the first two steps, they can be done like so using canvas's built-in .toUrlString() method:



// change the file type to whichever suits your use-case or dynamically handle different file types
// the second parameter is for "quality" again, in this case set to 90%
const compressedImageUrl = canvas.toDataUrl('image/jpg', 90);

For the final conversion steps, I am referencing a StackOverflow answer I found while searching for the simplest way to approach this, which you can find HERE. Bringing this code to life would look like so:



// takes the dataUrl from the previous step as an argument 
async function dataUrlToFile(dataUrl: string, fileName: string): Promise<File> {
   const res: Response = await fetch(dataUrl); // grabbing the image data
   const blob: Blob = await res.blob();
   return new File([blob], fileName, { type: 'image/jpg' });
}

Those steps should cover most use-cases, and allows us to compress files natively in JavaScript/TypeScript. Now you can pass in the new file object wherever you may please and it can be uploaded as a string or as an actual image.

Please leave any feedback or questions as I am always trying to improve these technical-oriented posts to leave less room for misinterpretation/misunderstanding.

Thank you for reading <3

Deploy Node.js to EC2

Konstantin Stanmeyer — Fri, 10 Feb 2023 19:15:34 +0000

Setting up an environment to use for both development and production on a cloud server can especially useful for remote teams and testing purposes.

This blog will explain how to initialize an Ubuntu instance within an EC2 virtual machine, with an end goal of creating somewhat of a "sandbox" to clone Github repositories. It will also allow us to open endpoints to this server and utilize running api's or applications.

First, here is some basic code for a test application to run within the deployed EC2 instance:

// ./app.js

import express from 'express';

const app = express();

app.get('/', (req, res) => res.json({ message: "App works!" }));

app.listen(3000, () => console.log("Server is running!"));

Now, with a working application, ensure that it is pushed to a Github repository, like so:

git init
git add .
git commit -m "first commit"
git remote add origin https://github.com/githubusername/example.git
git push -u origin main

Our next stop is to set up our EC2 instance. Assuming you have an AWS account set up, navigate to the EC2 dashboard.

IMPORTANT: Make sure you remember which region you are set within. For example, I set mine up to be hosted in Ohio so the small menu in the top-right of my page looks like so:

Here, the EC2 dashboard should display a menu like so:

Below that menu, select the "Launch Instance" button, which will bring you to a separate launch page.

Provide a name for your instance and select "Ubuntu" as the OS Image.

The outlined area shows the free tier option if you would like to run the server with no charges, but depending on your application you may prefer a different image.

Next, the security fields must be set up to SSH into our machine. Just below the tier options, create a new key-pair with the following options:

This will save a .pem file (or potentially .cer), which should be saved in an easy-to-remember folder within your computer. We will later navigate to the folder where this key resides to to SSH.

For simplicity I've allowed SSH traffic from any IP address, but this can allow specified access. The "Network Settings" section should look like so:

Keep the "Configure Storage" section as default, and select "Launch instance":

Navigate back to the EC2 dashboard, and select the instances option. Now, you should see your new Ubuntu machine running:

Select the instance's checkbox, and select the "Connect" option near the top right of the dashboard:

Make sure you're on the SSH tab, we will follow the steps listed:

Navigate to the folder where the access key was placed on our local computer. Within that folder, using a terminal, we must make sure our key is not "publically viewable" and run this command, from the third step(key is placed within my desktop folder for this example):

cd Desktop
chmod 400 example-ec2.pem

Which will return nothing, but we will then run the example SSH command:

Type "yes", and you will now be within your instance:

To allow us to run a Node application, we have to set up and install a few things. First, cURL will let us to download external packages and data:

sudo apt-get install curl

Node will be the next step, using setup code made from this open-source repository (can also choose a different version of Node/npm):

curl -sL https://deb.nodesource.com/setup_16.x | sudo -E bash -

Which will prompt us for a further command:

sudo apt-get install nodejs

One last package must be installed, being PM2, which will allow us to execute a command that keeps a defined process running, even after closing out of the SSH terminal. You can also use other tools like Screen if you'd prefer to avoid further downloads, built into Lunix.

sudo npm install -g pm2@latest

Clone your Github repository now:

git clone https://github.com/githubusername/example.git

Then run a pm2 command to start the process:

pm2 start example

It should be running within the machine now! You can monitor current processes within pm2 by typing:

pm2 list

With the application running, we need to allow our EC2 instance to expose the port the application is running on. We can navigate to the EC2 instance dashboard, and select the box for our current application. Below, now, we can see the security options like so:

Select the option below "Security Groups", bringing you to the group's page, and click the "Edit inbound rules" button:

There should be the existing rule for SSH traffic, but select "Add rule", and fill out a new rule for Custom TCP traffic, within a port range you set in your application (this example used port 3000), along with allowing all IPs to access the ports:

Now, with your server still running, you should be able to visit your public IP, which you can find in the your running instance's menu:

Put the port your application is currently on, and it should be fully functional, returning all the data and handling all the requests you need!

The processes can be monitored by SSH'ing into the EC2 instance, and running pm2 list to check what's still running. You can stop these applications by typing pm2 stop <application name>.

.env Variables

To create an env file, cd into your project while SSH'ed into your instance, then run:

sudo touch .env

Editing the file can be done by running:

sudo nano .env

Save your edited content with control + S and exit with control + x.

NGINX

When using a domain/IP, we'd like to avoid having to request the exact port the process is running on. NGINX gives us the ability to reverse-proxy requests to a process on port 3000, while requesting from PORT 80(HTTP-traffic).

From the root of your instance, enter this command to create and edit a configuration file:

sudo nano /etc/nginx/conf.d/my-app.conf

Then, within that file, we can define the port in which our application is running, as well as where we'd like our NGINX server to listen from.

server {
    listen 80;
    server_name 242.19.227.100;
    # w/ domain it would be www.example.com

    location / {
        proxy_pass http://127.0.0.1:3000/;
    }
}

control + S + control + x

Restart the service with our updated configuration:

sudo service nginx restart

Now, the address you sending requests to has a domain like this:

// before

242.19.227.100:3000/

// after 

242.19.227.100/

This setup allows you to push further changes to your Github repository, then update your running server with a simple SSH into it and pull command.

Thanks for reading!

Testing Code

Konstantin Stanmeyer — Fri, 06 Jan 2023 20:20:38 +0000

Why Test?

Writing test scripts allows us to check if data is flowing correctly even before running an application, determining received products meet out expectations. We can run desired conditions through our code, and prior to deployment, especially, we can ensure that even the most extreme use-cases will not result in an app-breaking bug. (We want to make sure getting any values or resources we don't want will ever happen, prior to deployment)

Overview

The flow should work as: You find something you wouldn't like to happen, so before a user can even let that happen, we must imitate how the values are sent or mutated, and ensure there are no hole in our code.

This setup will be using three separate packages to perform three different, but cohesively work to accomplish these:

Mocha: This executes any test code that we have defined, as well as returning information on whether the test(s) passed or failed.
Chai: The code that defines what passes or fails a test.
Sinon: Replaces some of our predefined functions (explained later)

NOTE: This will focus on a "unit test" (generally one function). What I will not cover is an "integration test", which is more complicated but can allow us to assess a flow of actions that work together. (e.g. check if route fires correctly, if the middleware functions, if controllers work properly, etc.)

Simple Testing:

First, set up package.json and install the dependencies to the developer environment:

npm init

npm i --save-dev mocha chai

We can take a look in our package.json file and see a test script with some useless code:

"scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
},

We can change that line to just "Mocha":

"scripts": {
    "test": "mocha"
},

The next step is to create an actual place for Mocha to reference, as well as where we will store the tests.

Create a new folder named "test" at the root of your project. Now create a .js file within it having any name.

The very cool part of writing tests is how natural they flow.

Tests start with a function given by Mocha:

// ./test/example.js

it('should equal 5', function(){
  ...
})

Which is given two parameters: We can define a message, as well as an anonymous function which will contain the actual conditions. This is meant to read like a normal sentence.

To define the success conditions, here is where we use Chai. It utilizes three key methods from the package, only slightly different in syntax but can accomplish identical results, leaving the choice up to your syntactical preference. Here are the official docs for more understanding:

That along with their docs are here .

In the same test file previously used (example.js), we can import the .expect() method from Chai, and an extremely basic, redundant test looks like so:

// ./test/example.js

const expect = require('chai')(expect);

it('should equal 5', function(){
  const num1 = 3
  const num2 = 2

  expect(num1 + num2).to.equal(5);
})

This syntax is crazy just how grammatically correct it is; It doesn't feel like coding. If we were to use the .assert() method instead of .expect(), it could look like this:

assert.equal(num1 + num2, 5); // second arg is the expected

To run theses tests we can type npm test in our terminal, which could return something like this if the test failed:

...

1) should equal 5

  AssertionError: expected 4 to equal 5
  + expected - actual

Dynamic Testing

99% of people using tests will not use hard-coded values like this last example, and we would like to dynamically test code written in other files.

Here, we will test to ensure an error WILL be thrown if we aren't signed in. This will not check anything else besides if when the "Authorization" header value is null. We are testing the behavior of the response The basic function we're testing looks like this:

// ./middleware/auth.js

module.exports = (req,res,next) => {
  const auth = req.get('Authorization');
  if (!auth){
    const error = new Error("Authentication Failed");
    throw error;
  }
  next(); 
}

How do we start with this new test? In a testing mindset we can think: How can I make the req.get() method's return value set to null, so we can check if our desired error is sent? We can redefine the method, solely for our test file for when the function runs.

Within a new, auth.js file inside our test folder, we can set a new .get() method for the request object, and add Chai's .expect() to see if we got the desired return value:

// ./test/example.js

const auth = require('../middleware/auth');
const expect = require('chai')(expect);

it('should have an authorization header present', function(){
  const req = {
    get: function() { // defining a new get method for the req object
      return null;
    }
  };
  expect(auth.bind((this, req, {}, () => {})).to.throw('Authentication Failed');
})

Sinon

Say, we were using JWT's, and we import the jwt object. If we wanted a method built into jwt to return null instead of its original function for one of our tests, this will alter the object across all files, which can cause tests to wrongfully fail in some cases.

Instead, we can use what's called a stub, which will save the object's original properties, then you'll execute the function with its new definition, and revert it to the original state at the end of a test.

This will by done with the Sinon package:

npm i --save-dev sinon

Then, in the auth.js file we can define conditions without mutating any of the JWT package:

// ./test/example.js

const jwt = require('jsonwebtoken');
const sinon = require('sinon');

it('...', function(){
  ...
  sinon.stub(jwt, 'sign'); // original sign method saved
  jwt.sign.returns({ hello: "world" });
  jwt.sign.restore(); // original method restored
})

Now, when our test runs the .sign() method built into jwt, it will be replaced to only return the { hello: "world" } object, but its original functionality will be returned immediately after the tests finish.

Organization

Say we want ten tests related to apples and ten related to bananas, how can we easily tell which is for which in a line of 20 tests? We can implement the describe() function from Chai to wrap our tests with a name for their group:

// ./test/example.js

describe('Authentication Middleware', function(){
  it('should equal 5', {
    ...
  })

  it('should not equal 6', {
    ...
  })
});

Now, when you run these tests it will be within a labeled group.

Before/After Keywords

We also get access to two additional function which will come in handy especially if we'd need to sign into a user before we do any defined tests, as well as sign them out after all the tests. Something like this can be done with the before(), which does not allow any code to execute until its own has finished, and after(), executing its code after every test has completed.

It would look like so:

// ./test/example.js

describe('Authentication Middleware', function(){
  before(function() { // executes all lines before any below
    ...
  })

  it('should equal 5', {
    ...
  })

  it('should not equal 6', {
    ...
  })

  after(function(){ // executes after all other code is done
    ...
  })
});

Asynchronous Code

Since JavaScript runs asynchronously, we must tell Mocha to wait for promises to finish or a test could be completed without all the needed information. For this, we can use the done keyword built into Mocha as a parameter for an it() function. This will tell Mocha to wait for the code within a function the done() is inside to execute before finishing the test.

Here is an example of logging into a user account with MongoDB, using the done():

// ./test/example.js

describe('...', function() {
  before(function(done) {
    mongoose
      .connect(
        'mongodb+srv://...'
      )
      .then(result => {
        const user = new User({
          email: 'example@example.com',
          password: 'example',
          name: 'Example',
          posts: [],
          _id: '...'
        });
        return user.save();
      })
      .then(() => {
        done();
      });
  }
}

Reset User Passwords

Konstantin Stanmeyer — Tue, 27 Dec 2022 16:37:11 +0000

Forgetting a password can always happen, and we must ensure a user can recover their information in a simple, secure way. Here, I will go through the basic steps to send OTPs(One-Time-Password) via email, which will be used to allow users to reset passwords:

Setup

To start, we can install the necessary packages:

npm i express nodemailer nodemailer-sendgrid-transport bcryptjs

nodemailer will be used to perform easier construction of emails and nodemailer-sendgrid-transport will allow us to utilize SendGrid's service to send them. bcrypt will come in at the end to encrypt a user's new password.

This will use Mongoose/MongoDB to interact with the user models/documents.

Sending an Email

I won't include the steps for setting up a SendGrid account, but use their website to create a free api key after setting a single sender(a real email).

To utilize SendGrid in our project, we must go into our controller and import the necessary packages, as well as implement our api key with the .createTransport() method:

// ./controllers/users.js

const nodemailer = require('nodemailer');
const sendgridTransport = require('nodemailer-sendgrid-transport');

const transporter = nodemailer.createTransport(
  sendgridTransport({
    auth: {
      api_key: '...'
    }
  })
);

Formatting the email is extremely simple. Fields like the subject and recipient's address must be provided, as well as the HTML you would like to have in the email. The basic code to send an email with our transporter is like so:

// ./controllers/users.js

transporter.sendMail({
  to: user.email,
  from: 'singlesender@email.com',
  subject: 'Test Email',
  html: '<h1>Hello World!</h1>'
});

You must use the email account you associated with your SendGrid single-sender to perform these actions or an error will arise. (must be from the existing email on record)

With the ability to send emails we can start adding the reset token(OTP) code. The general workflow will be like so:

A user will provide their existing email in the password form, which will then send a randomly generated token to the user's document in the database. This will also send them an email with a link that provides the token within the frontend url's params. The logic involves comparing the database value with the params value, as well as checking if the token has expired. Here is the basic user model to visualize:

// ./models/user.js

const mongoose = require('mongoose');

const Schema = mongoose.Schema;

const userSchema = new Schema({
  email: {
    type: String,
    required: true
  },
  password: {
    type: String,
    required: true
  },
  resetToken: String, // always null until token is created
  resetTokenExpiration: Date,
});

Creating Reset Token

To get a long, randomized value for our token, we can use the built-in crypto library for Node.js to produce a string:

const crypto = require('crypto');

crypto.randomBytes(32, (err, buffer) => {...}

The "buffer" will be the randomized string of 32 values returned if successful, and we will convert it to a hexadecimal value for easy use. Then, pass the desired values into the user instance to save the associated token and expiration to the database. Here is the final postReset function:

// ./controllers/users.js

const nodemailer = require('nodemailer');
const sendgridTransport = require('nodemailer-sendgrid-transport');

const transporter = nodemailer.createTransport(
  sendgridTransport({
    auth: {
      api_key: '...'
    }
  })
);

const User = require('../models/user');

exports.postReset = (req,res) => {
  crypto.randomBytes(32, (err, buffer) => {
    if (err) {
      console.log(err);
      return;
    } 
    const token = buffer.toString('hex');
    User.findOne({ email: '...' })
    .then(user => {
      user.resetToken = token;
      user.resetTokenExpiration = Date.now() + 3600000;
      return user.save();
    })
    .then(result => {
      transporter.sendMail({
        to: user.email,
        from: 'singlesender@email.com',
        subject: 'Test Email',
        html: `
          <p>Follow link to reset password</p>
          <a href="http://.../reset/${token}">Click here</a>
        `
    })
    .catch(err => {
      console.log(err);
    });
  });
}

After clicking the provided link, the user should be taken to a route with the token appended onto the url. This approach is extremely secure due to no user information ever being shown. The absolute only way to access this extremely hashed url/token is to have received the email directly.

Posting New Password

When a user loads onto their password reset page, the frontend url should now end with their token, the same url from the email received which should look somewhat like so:

http://example.com/reset/9052919d5d8805f58fb15581549d8aaa

// ./routes/user.js

const usersController = require('../controllers/users');

router.post('/new-password', usersController.postNewPassword);

When a user submits a password reset form, what information do we need? We will obviously need the new password, as the token from the frontend's routing params. Finally, we need an easy way to query the user's document in MongoDB, which will be done with their user_id value. With those we can use update their existing password, and delete the token along with its expiration date at the same time. My function to do so is this:

// ./controllers/users.js

const bcrypt = require('bcryptjs');

exports.postResetPassword = (req, res) => {
  const newPassword = req.body.password;
  const userId = req.body.userId; // grabbed from fetching user info on form-load
  const token = req.body.token;
  let resetUser;

  User.findOne({
    resetToken: token,
    resetTokenExpiration: { $gt: Date.now() },
    _id: userId
  }) // $gt adds a greater-than constraint
    .then(user => {
      resetUser = user;
      return bcrypt.hash(newPassword, 12);
    })
    .then(results => {
      resetUser.password = result;
      resetUser.resetToken = undefined;
      resetUser.resetTokenExpiration = undefined;
      return resetUser.save();
    })
    .then(result => {
      res.redirect('/login');
    })
    .catch(err => {
      console.log(err);
    });
};

We're done! The flow now works like this:

A user goes to a form to input their email for resetting a password
With that form data, if an associated account exists, we can find their account on the backend, and send them an email with a link to their own, secure new-password form which has their token in the url
Upon submitting the form, the token value along with the user's new password is sent to the backend
If the token is not expired and the password is valid, the user's token/expiration date will be deleted from the database, and their password will be updated.

Express Kickoff

Konstantin Stanmeyer — Mon, 19 Dec 2022 15:40:11 +0000

The switch to a JavaScript-only ecosystem has been extremely weird, but satisfying to see things I could do in ActiveRecord and ActiveStorage with Rails are possible, and sometimes easier with Express. The steps to perform SQL queries feel natural and simple, and with Sequelize doing almost all the work for you. If you are new to using JavaScript as a backend, this blog will introduce you to a basic API with full-CRUD, and show just how easy and familiar this process can be.

Here's my beginner experience building a basic application using Node/Express.js with Sequelize/MySQL to connect with the database. This is about the API-only!:

The packages below were used for this example

npm install body-parser express mysql2 nodemon sequelize

Create an app.js file in the root of the project.

Before defining any parts of the actual application within app.js, I needed to set up my Sequelize database. I'll skip this setup since it uses a third-party application(MySQL Workbench), but basically it creates a database I can find within my Node application, then connect to and query. To establish this connection, I created a util folder (holds helper functions) with a database.js file to hold this code. The file specifies key pieces of information to securely connect, including user info, the database's name, and the database type, which in my case is MySQL. The final file looks like so:

// ./util/database.js
const Sequelize = require('sequelize'); // using the sequelize package

const sequelize = new Sequelize('mysql-database', 'root', 'password...', {
  dialect: 'mysql',
  host: 'localhost'
});

module.exports = sequelize;

App.js will be where the basic application is defined, and also for implementing code to sync any latter changes you will make to the schema. Alongside all the necessary imports here is what the basic app.js file looks like:

// ./app.js
const express = require('express');
const bodyParser = require('body-parser');

const sequelize = require('./util/database');

const app = express();

app.use(bodyParser.json());

sequelize.sync()
.then(res => {
  app.listen(3000); // PORT 3000
})
.catch(err => {
  console.log(err);
});

BodyParser will come in handy later for post requests, otherwise we would receive undefined in the body of requests.

Then, the models may be defined. Like Rails, we can define a schema, this time within the model, not migrations. Changes will be noticed and applied when the server is restarted, via the sequelize.sync() method. Within a models folder, define a Product model like so:

// ./models/product.js
const Sequelize = require('sequelize');

const sequelize = require('../util/database');

const Product = sequelize.define('product', {
    id: {
        type: Sequelize.INTEGER,
        autoIncrement: true,
        allowNull: false,
        primaryKey: true
    },
    name: {
        type: Sequelize.STRING,
        allowNull: false,
    },
    price: {
        type: Sequelize.DOUBLE,
        allowNull: false,
    },
    imageUrl: {
        type: Sequelize.STRING,
        allowNull: false
    }
});

module.exports = Product;

This is where I think JavaScript starts to show a couple fallbacks compared to Rails (for this use-case), especially their syntax, and boiler-plate code. It feels like I'm going around hurdles to use a backend in a multi-purpose language, which makes sense and gives more possibility in the contrary, but maybe this is just me being spoiled with ActiveRecord while using Rails; Rails feels like it was built to make queries.

Since I wanted to be exposed to SQL relationships in JavaScript before my switch to NoSQL, I decided to create a second model used to add simple comments to products. The model define any relationships just two attributes: Id (which is also auto-applied), and description. After restarting the server, we can see the model's schema has synced within the database, but still without the foreign key we want, how do we define that? In app.js, like so:

// ./app.js
...
Comment.belongsTo(Product, { constraints: true, onDelete: 'CASCADE'});
Product.hasMany(Comment);
...

This also adds a dependency on comment instances, which will now automatically be also deleted if the product they're attached to gets deleted.

A cool feature we also get with relationships in Sequelize, in this case, we get methods like Product.createComment(), which will automatically assign a foreign key on the table, and create a comment instance.

However, after these changes, if the table already exists, they won't be noticed and we must drop the tables to force them. This change must only run once, too. To do so, change the .sync() method called in app.js like this:

// ./app.js
...
sequelize.sync({ force: true })
.then(res => {
    app.listen(4000);
})
.catch(err => {
    console.log(err);
});

Here, run npm run dev, start the server once, then revert that line of code to not contain { force: true }. Now the changes exist on the database and the comments have a product_id foreign key.

Next, create a routes folder within the root of your directory and add a product.js and comment.js file. Within these files is where we define the controllers, and which requests fire which ones. This felt almost identical to Rails where you'd also just define which route (params and some other features also work the same), and which method gets called in response, but with slightly more boiler-plate code as you can see:

// ./routes/product.js

const express = require('express');

const productsController = require('../controllers/products');

const router = express.Router();

router.get('/product/:id', productsController.getProduct);

router.get('/products', productsController.getProducts);

router.post('/product', productsController.addProduct);

router.post('/edit-product/:id', productsController.editProduct);

router.delete('/delete-product/:id', productsController.deleteProduct);

module.exports = router;

The code to set up for comments was done in the same way, but with only a get request for all comments for a specific post, and a request to post a comment to a specific post.

To implement these routes, we must add middleware in app.js:

// ./app.js
...
const productRoutes = require('./routes/product');

app.use(productRoutes);
...

Next is the actual controllers, which will be within a controllers folder, and named products.js and comments.js. Controllers work somewhat similarly to Rails, where there will be a method/function defined, usually taking in a request, then sending a response. The hardest part is just understanding promises and how Sequelize uses them. Everything done under the hood makes data-interaction very easy. Here is a function to grab all instances of Products:

// ./controllers/products.js
...
exports.getProducts = (req,res) => {
    Product.findAll()
    .then(prods => {
        res.json(prods);
    })
    .catch(err => {
        console.log(err);
    })
}
...

Here is what's happening. When a user requests '/products' as a get request, getProducts runs, then creating a fetch request, which is then resolved or caught if an error is thrown. If it is successful the products are sent in a response, as json.

This fetch would return something like:

[
    {
        "id": 1,
        "name": "Toothbrush",
        "price": 3,
        "imageUrl": "N/A",
        "createdAt": "...",
        "updatedAt": "..."
    },
    {
        "id": 2,
        "name": "Socks",
        "price": 6,
        "imageUrl": "N/A",
        "createdAt": "...",
        "updatedAt": "..."
    },
    {
        "id": 3,
        "name": "Napkins",
        "price": 4,
        "imageUrl": "N/A",
        "createdAt": "...",
        "updatedAt": "..."
    }
]

Sequelize makes these queries simple and sometimes just typing something you might think will work, may actually work. Here is the entire products controller to show full-CRUD and just how easy it is:

// ./controllers/products.js
const Product = require('../models/product');

exports.addProduct = (req,res) => {
    Product.create({
        name: req.body.name,
        price: req.body.price,
        imageUrl: req.body.imageUrl
    })
    .then(response => {
       res.json(response);
    })
    .catch(err => {
        console.log(err);
    })
}

exports.getProduct = (req,res) => {
    Product.findByPk(req.params.id)
    .then(prod => {
        res.json(prod.dataValues);
    })
    .catch(err => {
        console.log(err);
    });
}

exports.getProducts = (req,res) => {
    Product.findAll()
    .then(prods => {
        res.json(prods);
    })
    .catch(err => {
        console.log(err);
    })
}

exports.editProduct = (req, res) => {
    Product.findByPk(req.params.id)
    .then(product => {
        const updatedName = req.body.name;
        const updatedImage = req.body.imageUrl;
        const updatedPrice = req.body.price;
        product.name = updatedName;
        product.imageUrl = updatedImage;
        product.price = updatedPrice;
        return product.save();
    })
    .then(response => {
        res.json(response);
    })
    .catch(err => {
        console.log(err);
    })
}

exports.deleteProduct = (req,res) => {
    Product.findByPk(req.params.id)
    .then(prod => {
        return prod.destroy();
    })
    .then(res => {
        console.log(res);
    })
    .catch(err => {
        console.log(err);
    })
}

That's everything! Now there are full-CRUD capabilities.

Keyboard App (work in progress)

Konstantin Stanmeyer — Thu, 17 Nov 2022 01:12:26 +0000

After going from typing test to typing test aimlessly clicking away, I decided to create my own incorporating all the elements that would fall under my "perfect" website. This project also happened to be the ideal host to learn an assortment of new tech, which occupied the majority of the project's week-long build-time. This post will be a synopsis of the most difficult issues this Rails-React app threw at me and the solutions to fix them. Feel free to let me know where my code could be improved!

Core Mechanics

Words

What are the key factors for a typing speed test? The words, the timer, and the logic to handle input. To begin, the backbone of the project: The words. Originally, I tried to incorporate an external API to get a vast assortment of words, but this proved to involve multiple steps; It included doing things like creating a jumbled sentence of words from multiple returned paragraphs, and while attempting to use a free API this became a somewhat impossible move. I decided to switch to storing my words directly in my own API. Using rails as my backend, the most light-weight, fast option to me was storing an array of words in my Word.rb model. Then, after thinking about how many words a normal website uses for their random modes, it must only be around 75-100. This is due to the fact that more complex your words get, the more you deviate from the "average" typing speed with "average"-length words. To give my website its own personality I went out searching for my own, bland assortment of words, and after doing so, and storing them in a constant like such:

#./app/models/user.rb

class Word < ApplicationRecord

  WORDS = ["allow","else", ...]

end

Since I wanted my words to be returned in a string (you'll see why later), this was how I set up my controller and route to by dynamic:


#./app/controllers/word_controller.rb

def random_words
  @words = [""]
  params[:count].to_i.times { @words[0] << Word::WORDS.sample + " " }
  render json: @words
end

#./config/routes.rb

get '/random/:count', to: 'word#random_words'

The string being in an array is to send usable json, and this will also send a string ending with a space, which will easily be handled on the frontend. With this, my fetch route can request a string of any length, using the random assortment of words. E.X.

http://localhost:3000/words/50

This route would now return a randomized string with 50 characters.

The second difficulty with getting words became getting random quotes for my feature that incorporates sentences with punctuation, also including multiple languages. From the beginning I knew I wanted to use PaperQuotes as my AI for this task, but actually sending the request turned out to require some weird (at the time) syntax. A different API request for Bacon Ipsum I'm using looks like this:

#./app/controllers/word_controller.rb

require 'open-uri'

...

def fetch
  uri = URI.parse(URL)
  response = Net::HTTP.get_response(uri)
  @words = response.body
  render json: @words.split(' ')
end

However, with the PaperQuotes API and using the Net/Http gem to incorporate my API key, it would fail every time and return this:

<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>cloudflare</center>
</body>
</html>

This was beyond confusing to me and stack overflow was almost instantly checked. Luckily, an answer was there, and this was a common issue where an ssl configuration must be defined in the request. So, the updated, working request is like such:

def get_quote
  url = URI.parse("https://api.paperquotes.com/apiv1/quotes/?minlength=200&lang=#{params[:lang]}")
  req = Net::HTTP::Get.new(url)
  req["Authorization"] = "Token ----"
  response = Net::HTTP.start(url.host, url.port, use_ssl: true) do |http|
    http.request(req)
  end

  @quote = response.body
  render json: @quote, status: :ok
end

Coming Soon

Rails Run-Through

Konstantin Stanmeyer — Tue, 18 Oct 2022 21:50:06 +0000

VIEW Methods

soon

Relationships

soon

Validations

Validations live in the model, checks if one or many certain parameters are met, and returns the expected result if correct. Error handling is done in the case of a validation failing.

Here are some simple validations, including some ugly regex:

class Post < ApplicationRecord
  validates :title, presence: true
  validates :content, presence: true, length: { minimum: 50 }
  validates :category, inclusion: { in: ['Ruby', 'Rails'] }
  validates :capitalized?

  def capitalized?
    if title.split.first.match(/\A[A-Z]/)
      errors.add(:title, "first letter must be capitalized")
    end
  end
end

These validations do the following, in order:

Checks to see if your post has a title
Validates that the content exists, as well as it has at least a length of 50
Checks the post's category, making sure the value isn't empty, and includes either Ruby or Rails
CUSTOM VALIDATION: after defining the method below the validations, this now checks to see if the title begins with a capitol letter

If any one of these validations is not met, an error will be thrown by ActiveRecord, and the attempted task has failed.

Serializers

MAKE SURE SERIALIZER GEM IS INSTALLED
Customizes the json returned for a single model. This functions like an includes statement, where data associated with the object you're acting on gets returned along with it.

Built-in Serializers:

In this example for Students, I will walk through some reasonable use-cases for serializers:

With this, whenever we send json for any instance of Student, this serializer will innately apply to it. The key difference between this and custom options is passing a serializer in a fetch path; Built-in doesn't need to be written elsewhere besides the model, but custom serializers must. (example later for custom)

First, create the serializer for Students:

rails g serializer students

Examples:

1) A student object contains these eight values:

create_table "students", force: :cascade do |t|
    t.string "name"
    t.integer "age"
    t.string "race"
    t.integer "grade"
    t.string "best-friend"
    t.integer "teacher_id"
end

Now, say we don't want all of those values, and instead only want the student's name and age (we definitely don't need an id if this is a SHOW path, unless we're searching by a value other than id). With a serializer, we can pass those two values as attributes

class StudentSerializer < ActiveModel::Serializer
  attributes :name, :age

  has_many :books
  belongs_to :teacher
end

I also went a step further to include the relationships, which is another aspect of serializers, where they automatically, in pair with ActiveRecord, find associated values with foreign keys. Here, in a SHOW request for a specific student, we are grabbing all books that have the student's foreign key (owned by the student), as well as the one teacher the student belongs to, and returning them in the JSON response. A request as such would return something like this:

{
  "name": "Frederick",
  "age": 21,
  "books": [
    {
      "title": "East of Eden",
      "author": "John Steinbeck"
    },
    {
      "title": "The House Of Mirth",
      "author": "Edith Wharton"
    }
  ],
  "teacher": {
    "name": "Mr. Teacher",
    "class": "Math"
  }
}

Here, though, the returned json for Teacher and Books holds their entire object, what if we want to serialize it like we did with Student? We can! Adding a serializer to either class, the same as we did for student, will innately apply it to any instance of Teacher or Books, even when pulled with Student again. Here is an example serializer for books:

class BookSerializer < ActiveModel::Serializer
  attributes :title

  belongs_to :student
end

Now, if we do that same request for a single student, this will be returned:

{
  "name": "Frederick",
  "age": 21,
  "books": [
    {
      "title": "East of Eden"
    },
    {
      "title": "The House Of Mirth"
    }
  ],
  "teacher": {
    "name": "Mr. Teacher",
    "class": "Math"
  }
}

Custom Serializers:

Say we want the same return from a student, but we want the teacher to only include their name. We could technically do it this way:

class TeacherSerializer < ActiveModel::Serializer
  attributes :name

  has_many :students
end

But this isn't what we want. When we call an SHOW method on teacher itself now, it will only return this:

{
  "name": "Mr. Teacher"
}

But what if we wanted to return the whole teacher object? What if we want to only have the teacher return their name when we fetch a student, but continue returning the whole object when we just want to fetch a teacher? We can use a custom serializer, then pass is IN student, where the relationship lives.

First we generate the serializer:

rails g serializer student_teacher

Then, we can populate it with some code:

class StudentTeacherSerializer < ActiveModel::Serializer
  attributes :name

  has_many :students
end

Then, if we go to the SHOW method for Student we can add it:

def show
  render json: find_student, serializer: StudentTeacherSerializer
end

Now, without a serializer for teacher (no more TeacherSerializer), when we call a SHOW request on student we get this:

{
  "name": "Frederick",
  "age": 21,
  "books": [
    {
      "title": "East of Eden"
    },
    {
      "title": "The House Of Mirth"
    }
  ],
  "teacher": {
    "name": "Mr. Teacher"
  }
}

WOW. Only the teacher's name! Nice.

Error handling

Here, we will be using ActiveRecord's error-catching, and setting two general errors to handle, along with object-specific json returns, using the error object. There'll also be a custom error at the end.

First, we can look at what we need to error handle in the routes we've made for a model:

For SHOW or UPDATE, both of which are looking for instance of an object, we want to return an error when the search parameter doesn't match any existing instance. We can use ActiveRecord's rescue, or rescue_from method to access the "record" value within the error object when it's thrown. Starting with the RecordNotFound error, we can add handling at the top of the controller, and then define what's returned in our private methods:

class StudentsController < ApplicationController
  rescue_from ActiveRecord::RecordNotFound, with: :render_not_found_response
  #code...
  def show
    student = find_student
    render json: student
  end

  private

  def render_not_found_response
    render json: { error: "Student not found" }, status: :not_found
  end
  #code...
end

Now

Then, there is handling a RecordInvalid, which can be thrown when you are trying to pass an updated or new instance during a CREATE or UPDATE. Here is how that works:



def update
  post = post.create!(post_params)
  render json: post
end

Minimizing Code

soon

Whimsical Wonderland

Konstantin Stanmeyer — Mon, 10 Oct 2022 00:23:59 +0000

During my first two end-of-phase projects at Flatiron School, my contributions to my group's repository consisted of unorganized code, second-guessed, sloth-paced GitHub usage, and other unproductive habits, all of which I wanted to turn around during my Ruby unit.

To make sure I had the highest chances of reaching this goal, I decided to teach myself my way around Whimsical. This is a planning web-service that utilizes a 2D space to view realistic features on a web page, plan ideas with a team, and to generally create a visible workflow to help with the web-dev process. I initially thought this goal would be difficult, but it proved to be intuitive with the great tools provided by the website, and provided no real harm for my many many rounds of trial and error.

Now, a short synopsis of why this website lightened the process to make a full-stack, basic web application, and snippets of code to show the idea-to-product workflow from a more technical side:

The Back-End

To start, our first assigned deliverable for this project was to create a user story, as well as create the backend schema that our data will eventually be stored in. The basic premise of this website was to let the user select a food delivery service, then order dishes from any of the restaurants their specific service provided. The full user story can be found in the GitHub repository's README.md which will be linked at the bottom of this post. Here is the backend schema:

And here is how the schema turned out inside of our project:

create_table "deliveries", force: :cascade do |t|
    t.string "name"
  end

  create_table "dishes", force: :cascade do |t|
    t.string "name"
    t.string "ingredients"
    t.boolean "vegetarian?"
    t.boolean "appetizer?"
    t.boolean "entree?"
    t.boolean "sides?"
    t.boolean "dessert?"
    t.boolean "drinks?"
    t.string "image_url"
    t.string "price"
  end

  create_table "middles", force: :cascade do |t|
    t.integer "dish_id"
    t.integer "restaurant_id"
  end

  create_table "orders", force: :cascade do |t|
    t.string "restaurant_name"
    t.integer "price"
    t.string "image_url"
    t.string "dish_name"
  end

  create_table "ratings", force: :cascade do |t|
    t.string "name"
    t.string "description"
    t.integer "star_rating"
    t.integer "restaurant_id"
  end

  create_table "restaurants", force: :cascade do |t|
    t.string "name"
    t.string "category"
    t.integer "delivery_id"
    t.string "image_url"
  end

Next, I wanted my group wanted to have a complete visual set up, so that once we started creating the actual website, we could reference something instead of spending hours thinking. I'll begin with the home page, and go in order of the user experience, while also showing the contrast with the end result.

Home Page

This page was entirely done on the front end, and like all other components in this React project, was styled with vanilla CSS. The idea was the create a static page where the user could see all five delivery service options, and also have access to some other functionalities. This includes additional routing to the orders page (showing past orders), about page, and contact page. Here is the initial wireframe, as well as how to page ended up:

Before:

After:

Due to time constraints, and technical difficulties with gems and node packages, some features were taken out as you can see. In that one, for example, the zip-code slider, which would've taken ages to set up with somewhat intuitive logic. These slight differences are consistent throughout the wireframes, most of which were obvious overshots of goals.

Restaurants Page

Now, after the user has selected a delivery service, they are taken to the next page, which displays all of the restaurants provided by their choice. This is where the order bar is also introduced, and where the user is given the option to enter their address, which will then give them a randomized delivery fee. They also have the ability to search for a specific cuisine, but the search bar functions for restaurant names too. Here's this page's comparison:

Before:

After:

Dishes

Once the user decides which kind of cuisine they are in the mood for, they get taken to the dishes page, which shows them all the possible options provided at the restaurant. With this and the restaurants page, the Whimsical board made this entire process insanely fast, basically having all the visuals done and copying what we were looking at; Translating it. We knew where to put names, values, all of our flexboxes, div's; It just made pretty much everything more streamlined.

Before:

After:

After the user places an order, their dish of choice gets sent to the back-end, and used in our fetch request for the orders page:

There was actually no board made for this one, until after finishing the page to create a complete mind-map to always have reference to. It was somewhat of a last-second addition, barely finishing it just minutes before presenting our project. And, crazy enough, without a reference, this was one of the longest processes to style, even though the end result was quite simple. To me, and to say it again, the biggest advantage of using a service like Whimsical is to avoid the long, grueling though process sessions, just to think of a basic idea. That same process can be doe 10x faster on a platform besides your code editor and in your CSS file. Use it! Here is also the final, complete board, and our additional task-board used to keep track of tasks daily, especially who was doing what:

ooooooo look how empty and done all of those tasks are :)

Takeaways

I think that with an improved concept-to-product process under my belt (in terms of visuals), my room for improvement lies in my actual code, and the processes happening to produce those visuals. This project took a staggering 983 lines of CSS, which, alone shows there is a drastic need for improvement. Variables are probably the best option, and creating reusable classes to cut down on the repetition. But, the improvement isn't only needed on the front-end but the back-end too. A lot of fetch request issues occupied my time during this 5-day project phase, especially where "include" statements weren't returning data the way I wanted, and methods will most definitely help. Having started Rails this week, I already see ways my style is more adequate for the framework, and I'm increasingly excited the more I dive into the language. :)

Links

Project Partners:

https://github.com/ericahashert

https://github.com/edwarddickey

Repos:

Back-End: https://github.com/ericahashert/phase-3-sinatra-react-project

Front-End: https://github.com/ericahashert/Phase-3-Frontend

An Intro to useContext in React.js

Konstantin Stanmeyer — Mon, 19 Sep 2022 13:54:22 +0000

An aspect of React that I never like is the transfer of state values between components, and requiring props to be passed to both give values of state, as well as update them. The useContext hook can make this process a slight bit easier by allowing you to manage state globally, and for nested components especially, they have an easier time without the need to pass props.

How to Begin

The most conventional approach to using this hook is to initialize the context (global state value), and give it the ability to pass a value down to components. This first step to initialize UserContext as a variable is all done within its own file, for me, named CreateContext.js:

import { createContext } from "react";

export const UserContext = createContext();

This is all the required code in that file. Now we can go to our page, which in my case, my App.js is structured as so:

function App() {
  return (
    <Router>
      <div className="page">
        <div>
          <li>
            <Link to="/">Home</Link>
          </li>
          <li>
            <Link to="/results/">Results</Link>
          </li>
        </div>
        <Routes>
            <Route exact path="/" element={
            <Home />
            }/>
            <Route path="/results" element={
            <Results />
            }/>
        </Routes>
      </div>
    </Router>
  );
}

Here is what we're looking at:

Home

Results

For my simple example, the idea is to create an input from the input-box, set it to the global state value, then access it from our results page. Here is how to initialize that value, then wrap it around the components we want to access that information:

import React, { useState } from 'react';
import Home from './Home';
import { BrowserRouter as Router, Routes, Route, Link } from 'react-router-dom';
import Results from './Results';
import { UserContext } from './CreateContext';

function App() {
  const [value, setValue] = useState("default")

  return (
    <Router>
      <div className="page">
        <div>
          <li>
            <Link to="/">Home</Link>
          </li>
          <li>
            <Link to="/results/">Results</Link>
          </li>
        </div>
        <UserContext.Provider value={{ value, setValue }}>
          <Routes>
              <Route exact path="/" element={
                <Home />
              }/>
              <Route path="/results" element={
                <Results />
              }/>
          </Routes>
        </UserContext.Provider>
      </div>
    </Router>
  );
}

We are at the highest level of the application, and the highest place we want to access the information. We have passed along a value to the global state, which has been set to the variable "value", meaning it is initialized as "default".

Now, if we want to access that value, we can do it as such:

import { useContext } from "react";
import { UserContext } from './CreateContext';

export default function Results(){
    const { value } = useContext(UserContext)

    return(
        <div>
            <p>Results: {value}</p>
        </div>
    )
}

This is the results page, and it is using the useContext function to grab a value out of "UserContext", which it is then displaying:

Now, to update this value, I can go to my Home page, and change the input field, which has been set to the same global state value, "default".

Here is how I am grabbing that value:

import { useContext } from "react";
import { UserContext } from './CreateContext';

export default function Home(){
    const { value, setValue } = useContext(UserContext);

    return(
        <div>
            <p>Enter a value: </p>
            <input
                type="text"
                placeholder="enter value..."
                value={value}
                onChange={(e) => setValue(e.target.value)}
            />
        </div>
    )
}

We are also able to update it with this function, with the onChange utilizing the setter function. As you can see, this step looks almost identical to useState. We are using the hook function to grab a value, and de-structure it to allow us to both use what's stored, and set it by passing the setter function a new value.

Creating Pop-Ups

Konstantin Stanmeyer — Thu, 25 Aug 2022 02:31:00 +0000

While coding, pop-up windows seem like a norm to put into most websites, and it seemed like it would be a simple addition to anyone's CSS files. It's how you sign up for websites every day, zoom into pictures, as well as a long list of other situations where the focus is shifted onto something in the "foreground". Before beginning this learning process, the question stood to me: How would I even begin to add an element completely covering, as well as disabling the rest of the page's function? At first I thought layering, specifically on the "z" axis, would be the best course of action, but after reading into it one option seemed to be the most simple:

The Actual(short) Process

What do we actually want to show up on our DOM? The first layer begins with taking focus off of the "body" content by darkening it, to later give the pop-up more contrast.

<body>
   <div id="blur-cover">
      <div id="pop-up">

      </div>
   </div>
</body>

The HTML elements are not specific, just including a "div" for the blur effect, and another for the actual content; The window that will appear after clicking on an event listener.

The first styling to make the "div"s appear with a few qualities includes:

#blur-cover{
   width: 100%;
   height: 100%;
   background-color: rgba(0,0,0,0.7)
}
#pop-up{
   width: 500px;
   height: 300px;
   background-color: white;
}

These lines will create the background blur effect, which is now just a semi-transparent "div", darkening the "div"'s background within its margins as well as a solid white "div" that's an appropriate size, all overlayed on a filler-picture to see depth:

Then comes the additional styling to place the "div"s in the correct spots:

#blur-cover{   
   width: 100%;
   height: 100%;
   background-color: rgba(0,0,0,0.7);
   position: fixed;
   top: 0;
   justify-content: center;
   align-items: center;
   display: flex;
}
#pop-up{
   width: 500px;
   height: 300px;
   background-color: white;
   border-radius: 15px;
   position: absolute;
}

Now, the white box is in the center of the page, even while scrolling, as well as the background being a darkened version of the "body" elements. Note that the "background-color" of #blur-cover is set as "rgba" with an opacity value of 0.7. If you call the "background-color" as something like "black", then call an "opacity" of 0.7, which seems like it would work, it would then apply that transparency of 70% to all elements within its "div", including the pop-up, which we don't want.

To explain the CSS further, #blur-cover now has attributes for the following:

   top: 0;
   justify-content: center;
   align-items: center;
   display: flex;

"top", brings the the element to start from the top of the page, "justify-content: center" horizontally aligns the child "div" to the center of the page, "align-items: center" vertically aligns its child "div" into the middle of the page. "display: flex" works hand-in-hand with the the second and third lines to center "div"s, where we commonly see those three used in combination to center elements.

The added CSS to position the #pop-up "div" is quite simple and half-aesthetic, being "border-radius", to create softer edges around the white box, and "position: absolute" to make the box static even while scrolling.

Then, we have to assign a button with an event listener to actually make the pop-up appear when clicked, as well as a way to exit out of it.

Creating the X:

<div id="pop-up">
   <div id="close">+<div>
</div>

The "x" cannot be an actual "x" character, due to it not being symmetrical, so a "+" can be substituted, while also rotating it 45 degrees, and positioning it on the pop-up:

#close{
position: absolute;
top: 0;
cursor: pointer;
font-size: 40px;
transform: rotate(45deg);
right: 14px;
}

Before going any further, we have to make the pop-up not visible in the default DOM by setting one more attribute to "#blur-cover":

display: none;

This will be the premise of the event listener, where we will switch the "display" value depending on if we click the pop-up button, or the "x" button:

document.getElementById('btn').addEventListener('click', e => {
    e.preventDefault();
    document.querySelector('#blur-cover').style.display = 'flex';
})

document.querySelector('#close').addEventListener('click', e => {
    e.preventDefault();
    document.querySelector('#blur-cover').style.display = 'none';
})

After, we create the first couples lines of JavaScript to make any button functionally make the pop-up appear.

Closing

My main goal with learning this was to improve at CSS, and this question I solved had always been in the back of my mind. Doing this also improved how I handle CSS problems, realizing that I could have done this with prior experience and knowledge if I had only thought of how to apply it. Always room for improvement. Thanks for reading!