DEV Community: Corbin Callais

Promises

Corbin Callais — Mon, 27 Jul 2020 10:39:01 +0000

Introduction

Promises¹ are an object added to JavaScript for the sole purpose of asynchronous code creation that is not only cleaner, but much more convenient to dig through than async/await calls, especially when you begin to dig deeper into call chains.

A Promise works by making a call to retreive some data that it doesn't know yet, and it awaits a response. It can be responded to in one of two ways: with a resolve, meaning it was successful, or with a reject, meaning it failed with some form of error.

Promises are especially useful in server-side data handling, such as with Node.js² file system, fs.

Building a Promise

There isn't much more to talk about in the way of Promises themselves, so let's head right into building one. Let's say we have a database and we're using fs to access it. We want to use an asynchronous call, as synchronous calls in our case will error out code. Promise is perfect for async.

These examples assume you are on Node.js and have required all dependencies necessary.

// Start by defining a function to start the thing we want to do.
// Async functions always need a callback just in case there is a next action.
const returnFiles = function(filePath, next) {
  // We then return a new promise. So soon? Don't get your hopes up.
  // Make your promise like this.
  return new Promise((res, rej) => {
    // Fill out what you would want any other function to do. In this case, it's
    // read the files and bring them back to the callback.
    // Most of fs's callbacks get the error first, don't be confused between them!
    fs.readFile(filePath, (err, data) => {
      if (err) {
        // If this brought back an error, that should take priority. Another reason
        // we have errors as first param of a callback.
        next(err, null);
        rej();
      } else {
        // If there's no errors though, we're clear to do as we please with the data.
        // Whatever isn't being used, we pass in null as to tell the code this is
        // intentional.
        next(null, data);
        res();
      }
    });
  });
};

This is all fine and dandy, but of course not using the resolve/reject to their fullest extent means not using Promises as a whole the same way. We can pass in our gotten back data to our res/rej functions directly, without needing to rely on a callback for data handling.

That's where .then() and .catch() comes in.

`.then()` and `.catch()`

.then() and .catch() are a Promise's way of handling the resolve or reject, respectively. Each of these methods return another Promise themselves, which allows for chaining of thens to grab data from even multiple spots in memory.

Let's try an example, using .then() and .catch().

// Same setup as before, but with slightly different function.
const singularLineFiles = function(filePath, next) {
  return new Promise((res, rej) => {
    fs.readFile(filePath, (err, data) => {
      // This time we'll just pass in the data to our reject if it errors,
      // or resolve if it doesn't
      if (err) {
        // Slightly different here: we just pass in what is valid, no filler.
        rej(err);
      } else {
        res(data);
      }
    });
  })
  // From here you handle what it does once it gets the data back.
    .then(data => {
      const parsed = data.split('\n').join(" ");
      next(null, data);
    })
    .catch(err => {
      next(err, null);
    });
};

// You can even chain .thens to get all of the data you want before the next!
const singularLineFiles = function(filePath, next) {
  return new Promise((res, rej) => {
    fs.readFile(filePath, (err, data) => {
      if (err) {
        rej(err);
      } else {
        res(data);
      }
    });
  })
  // Of course, this example isn't a practical one, but you get the idea.
    .then(data => {
      const parsed = data.split('\n');
      next(null, data);
    })
    .then(data => {
      const parsed2 = data.join(" ");
    })
    .then(data => {
      next(null, data);
    })
    .catch(err => {
      next(err, null);
    });
};

Conclusion

Promises are a somewhat new thing in JavaScript that allows for the clean creation and management of asynchronous code. They're deceptively simple when you break them down, and are just as if not more powerful than async/await. Whenever you need data, but not, like, right away, you can just Promise your code you'll get it. It'll understand.

Superscript References

Databases and MySQL

Corbin Callais — Wed, 22 Jul 2020 14:51:33 +0000

Introduction

Databases are, simply put, places where data is stored and recalled in a non-volatile state. When we refer to a database, we typically mean a system to actually manage the stored data, called a DBMS (Data Base Management System).

The primary use of a database is storing data, but to do so to the fullest effect, the concepts of databases need to be fully understood. And those come in the form of an acronym called ACID (Atomicity, Consistency, Isolation, Durability). These will allow for the safe and proper storage and transferral of data. Without these ACID properties, everyday occurrences such as using computer systems to buy products would be difficult and the potential for inaccuracy would be huge. Imagine more than one person trying to buy the same size and color of a sweater at the same time -- a regular occurrence. The ACID properties make it possible for the merchant to keep these sweater purchasing transactions from overlapping each other -- saving the merchant from erroneous inventory and account balances.

ACID

Atomicity

If I were to use a single phrase to describe this word, it would be "all, or nothing". The word is based upon atoms, the supposedly smallest building blocks of the universe. Getting any smaller will become conceptual and irrelevant to whatever you're trying to do. And on a similar level, when you store data in a database, either all or none of the updates in a database should be available to the user(s) of whereever it is accessing. This includes adding, removing, or changing existing data.

Consistency

"Good musicians can play a piece well. Great musicians can do it again."

Among the same lines as the quote above, being consistent with your data is vital to storing it. This means that every instance of that data should and will be identical or else it is not worth the hassle. What good is storing data if it changes on you every time you boot up your computer?

Isolation

Isolation refers not to being able to manage data well internally, but rather to handling multiple external requests, such as multiple clients trying to add items to the database all at once. Isolating these separate calls to the database is a safeguard in any DBMS, to prevent the unintentional splicing and possible corruption of data.

Durability

Durability refers to the previous states of the database, in case something happens and data is corrupted or lost. Git does this extremely well; every committed change is stored in its history, and you can head back to any previously committed state at any point. It also should handle unintentional state loss, such as your application or disk crash, write or read failure, or even your entire computer crashing.

SQL

All of this talk about databases is fine, but we don't have any way to directly edit our database. Well, not without digging directly into our computers kernel¹, anyways. Which is why database languages exist. Today we'll be talking about SQL, short for Structured Query Language, which is a fairly old but still useful database language.

SQL has its own terminal, much like a bash terminal, where you can directly interact with your databases. To work with databases, we need to create one and "use" it, which is their way of scoping into a database to manage its data. We do this with CREATE DATABASE <name> and USE <name>.

From there we need to create what's called a table, which will define the structure of data stored within it. This is done with CREATE TABLE <name> (<clauses>);. More details on the (<clauses>) part in the code example below.

Queries

As said in its name, we use queries to manage data in SQL. We will primarily do this with SELECT/FROM clauses (the keywords for SQL are technically case insensitive, but it's customary to uppercase it).

CREATE DATABASE example; -- commands only end with a semi-colon, so you can write multi-line commands.

USE example; -- Scopes into database

CREATE TABLE items (
  id INTEGER PRIMARY KEY AUTO_INCREMENT, 
  -- An id property. This is universally useful in all SQL queries. INTEGER defines
  -- its datatype, PRIMARY KEY makes it so it must be a unique value and NOT NULL.
  -- AUTO_INCREMENT makes it so every new item added will have a unique id with no
  -- extra user input.

  itemname VARCHAR(25)
  -- The name of the item. VARCHAR() tells it to be a string, limited to the number in
  -- the parentheses, defaulted to 255.
);

SELECT * FROM items; -- This will pull all data from the items table.

This is a basic setup for a SQL database, but one glaring problem is that there is no data in this table yet. SQL has that covered, with INSERT INTO <table> (<columns>) VALUES (<values>);. Let's take the example above as our baseline.

CREATE DATABASE example;

USE example;

CREATE TABLE items (
  id INTEGER PRIMARY KEY AUTO_INCREMENT,
  itemname VARCHAR(25)
);

INSERT INTO items (item) VALUES ('Apple'); 
-- Inserts an Apple into items table. We don't need to mess with id because SQL does
-- that for us.

SELECT * FROM items;

And just like that, we should get something along the lines of:

id | itemname
-------------
1  | Apple

What if you want to delete items from the table? Well, that's where DELETE queries come in. A DELETE query looks like DELETE FROM <table> WHERE <conditional clause>.

CREATE DATABASE example;

USE example;

CREATE TABLE items (
  id INTEGER PRIMARY KEY AUTO_INCREMENT,
  itemname VARCHAR(25)
);

INSERT INTO items (item) VALUES ('Apple');
SELECT * FROM items;

DELETE FROM items WHERE itemname='Apple';
-- This deletes the apple from the items table.

Conclusion

Databases store data in non-volatile memory, using the ACID methods to keep the structure universal and to prevent data loss. We then use SQL to manage said database, using it to insert data, grab it for whatever we need, and even delete it, all in just a few lines.

Superscript References

Computer Kernels https://en.wikipedia.org/wiki/Kernel_(operating_system)

Rundown of React

Corbin Callais — Mon, 13 Jul 2020 08:31:26 +0000

Introduction

Building a webpage typically takes 3 different languages:

HTML, a markup language to give your page structure
CSS, a styling language to give your page...style
JS, a programming language to give your page functionality

Typically, when you want to do something to the DOM, it's a very long-winded process, and doing that for your entire webpage will take up far more code than the majority of people feel like writing.

The snippet below is a very simple example of grabbing a div tag, and editing its inner text to say something else.

// Grab the item
const testNode = document.getElementById('test');
// Change its text
testNode.innerHTML = 'This is some new text for the tag!';
// What about a child?
const childNode = testNode.childNodes[0];
childNode.innerHTML = "I'm the child of the item above!";

Granted, this is a small example. But when you scale up to a full-fledged webpage, it can get out of hand very quickly.

Usually, jQuery can handle shorthanding the functions to do more in the same amount of space.

// Same thing as above, but in jQuery
$('#test').text('This is some new text for the tag!');
// Grabbing the p tag elements in #text
$('#text > p').text("I'm the child of the item above!");

But that doesn't entirely fix issues with what we primarily use JavaScript for in webpages, and that is dynamic rendering and interaction. Of course, you can use jQuery to do it too, but it's much less intuitive than looking at raw HTML.

And that is where ReactJS¹ comes in.

ReactJS

ReactJS, or just React, is, as said in their hyperlink, "A JavaScript library for building user interfaces". React is quite a different beast from JavaScript, literally. It uses an entirely different extension called .jsx. Though, don't let that scare you, it's still just JavaScript, with a little bit of HTML thrown in there.

To get started in React, all you have to do is create an arrow function variable, and have your return statement return some HTML, wrapped in parentheses. This will create what they call a component.

// Define your function
const App = () => {
  // Return HTML. Keep in mind you can only return one "master" node at a time,
  // meaning it will error out if you try to, say, add a second div after the first
  // one closes.
  return (
    <div>
      <p>Hi there!</p>
    </div>
  );
};

See, looks really easy, doesn't it? Now, React doesn't actually add it to the DOM for you, you have to dictate where it gets added first. We do this using ReactDOM.render(), which takes two arguments: your component call, and where to place it. This can be done in standard JS, and is convention to do so.

KEEP IN MIND: when you call your component, instead of doing Component(), you do <Component />. It has to do with generic typing², primarily seen in Typescript, to keep the code unopinionated as they advertize.

<!-- app.html -->
<!DOCTYPE html>
<head></head>
<body>
  <div id="app"></div>
</body>

// App.jsx
const App = () => {
  return (
    <div>
      <p>Hi there!</p>
    </div>
  );
};

// index.js
ReactDOM.render(<App />, document.getElementById('app'));

And with this, you'll get a basic div that says Hi there!, right in the DOM. Now, this is a basic example, but we can get fairly insane with it, React doesn't care.

And you can also call other components within the component. Let's take the same example, but only the JSX.

const ShoppingList = () => {
  return (
    <div>
      <p>Grocery List:</p>
      <ul>
        <ListItemOne />
        <ListItemTwo />
      </ul>
    </div>
  );
},
ListItemOne = () => {
  return (
    <li>Kale</li>
  )
},
ListItemTwo = () => {
  return (
    <li>Cucumbers</li>
  )
};

This will print out as if you just put the <li>'s directly in ShoppingList. Funny how that works.

But seeing static examples probably will bring up the question of dynamics again. React's got that covered.

"props" and Templating

props, shot for properties, is the parameter in React that determines what can be passed down from parent to child, typically information and/or functions that we want specific parts of our webpage to have.

We pass in props when we call our React components, in the whitespace between the end of the name and the forward slash to end the call. This allows any and all items passed in to act like an object--you assign it a keyname when you pass it in, and that keyname will be in the props object, with the value you pass in. But you can't just use variable names by themselves, because of how JSX works. That's where templating comes in.

Templating is very similar to how string interpolation, using ${}, works, but you can do it with every datatype. And not just when passing down data; you can template anywhere within your JSX return statement.

// ShoppingList.jsx
const ShoppingList = (props) => {
  // You don't need to do this, but it's more convenient to destructure*, as React is
  // built primarily for ES6.
  // items is an array.
  const { items } = props;

  return (
    <div>
      {/* A good example of templating, you can comment in JSX returns like this! */}
      <ul>
      {/* And also map. */}
      {items.map((item, i) => {
        // When you map things in JSX, it will tell you to make sure each iterate has
        // a unique 'key' property. 'key' is a unique keyname and shouldn't be any 
        // other data's name.
        <ListItem key={i} item={item} />
      })}
      </ul>
    </div>
  );
},
ListItem = (props) => {
  const { item } = props;
  // Don't worry about the aforementioned key, React adds it for you.
  return (
    {/* And of course templating works for raw data. */}
    <li>{item}</li>
  );
}

Destructuring³

// index.js
const items = ['Kale', 'Cucumbers', 'Cheese'];
ReactDOM.render(<ShoppingList items={items} />, document.getElementById('app'));

And now we'll have a list that contains three bulleted items: Kale, Cucumbers, and Cheese.

Okay, but this is still not very dynamic. There aren't even any click handlers! Well, that's where Statefulness comes in.

Stateless and Stateful

What we've been doing up to this point were "stateless" components, components that aren't expected to be changing throughout the lifetime of the DOM. But what happens if we want, say, to be able to add items to our list as we make our rounds? Enter, stateful components.

Stateful components can explain themselves pretty well; they have an innate this.state property. Yes, this is here too. Because to create these components, we use ES6 pseudoclassical instantiation. We can use non-ES6, but that will involve using a separate file entirely, called 'create-react-class'.

When we create a stateful component, make sure to always extend from React.Component. This will give you all of the methods and such to help you create it.

This next example will get a fair bit more complicated, but I have comments all the way.

class ShoppingList extends React.Component {
  // Make our constructor, and have it call the super (React.Component)
  constructor(props) {
    super(props);
    // From here, define the state. State is always an object, keep that in mind.
    // props is also this.props in here, so keep that in mind too.
    this.state = {
      items: this.props.items
    };
  }
  // In the methods we define a render method. This is what React calls when the state
  // changes, or creating it for the first time.
  render() {
    const { items } = this.state;
    return (
      <div>
        {/* An input value and a button to add stuff. This shouldn't be in Shopping
            List, but this is just because it's lone enough already. */}

        {/* Click handlers should go in protector functions for the same reason 
            setTimeout calls need them; immediate calling can seriously mess up your 
            code. */}

        <input id="input" type="text" placeholder="Add an item..."/>
        <button type="button" onClick={() => this.addItem()}>Add</button>
        <ul>
        {items.map((item, i) => {
          <ListItem key={i} item={item} />
        })}
        </ul>
      </div>
    );
  }
  // Now we need a click handler for the button. We'll use a little bit of jQuery here,
  // so we can grab the value in the input.
  addItem() {
    // Here we want to reassign the value of state entirely, using a convenient
    // function called setState. Does exactly what you think it does.
    const item = $('#input').val(),
          listCopy = this.state.items.slice();

    // Unshift so it appears at the top.
    listCopy.unshift(item);
    this.setState({
      items: listCopy
    });

    // Quality of life optimization, clear the input field when done.
    $('#input').val('');
  }
}

// ListItem can do stateless, the item itself doesn't need to change.
const ListItem = (props) => {
  return (
    <li>{props.item}</li>
  );
}

Okay, that was a lot to take in. Let's break it down.

We start with our usual: define a ShoppingList, and ListItem, and fill them out with the basic necessities, i.e., the rendering function with relevant data.
We then add in two extra items to ShoppingList, an input and a button. We set the onClick (camelCased for React to be able to understand it) to ShoppingList's method of addItem, which takes the input's value and reinstates the state with that new item.
Behind the scenes, React then does its magic and rerenders the component, and all sub-components, to the DOM again, removing the last one, as that's outdated.

Compiling

Since React uses a separate extension, we can't just plug in the code and call it a day. We have to pre-compile the JSX into plain JS, and to do that, we have a separate file entirely, called Babel⁴. Babel, when installed, will take your JSX code and convert it into plain JS that a browser can understand. Just make sure the base HTML file you run off of takes the compiled versions, not the JSX.

Alternatively, you could just type out the entire thing in plain JS, without the need for a compiler, but that removes all of the syntactic sugar that is in-line HTML, and can seriously nest deep, depending on what you're making.

Conclusion

ReactJS is a JS library that makes creating a webpage far simpler than what it is without it. It seamlessly mixes HTML into JavaScript, which makes it far more readable in terms of its structure. You can handily pass in data to dynamically render it to the DOM, and you can even have stateful components that can change within the lifespan of the DOM.

Superscript References

ReactJS's homepage: https://reactjs.org/
Typescript Generic Typing: https://www.typescriptlang.org/docs/handbook/generics.html
Destructuring is a different beast than the topic at hand, but the basic idea is pulling keys from an object into their own separate variables, to avoid redundant typing.
Babel compiler: https://babeljs.io/

Polymorphism

Corbin Callais — Thu, 09 Jul 2020 05:51:26 +0000

Introduction

Polymorphism is a term used with constructor function instantiations to give multiple functions a tree of sorts, each sharing the previous's properties and methods.

It's primarily used to cut down on code in Object-Oriented Programming to make sure the working experience is streamlined, giving a "write less, do more" attitude if you will.

While it's a simple concept on the surface, it isn't uncommon to see a newer coder get stuck on the "coding magic" that is polymorphism, and even instantiation as a whole. This blog will, by the end of it, help you on your way to making all kinds of constructors for all kinds of things.

How does it work?

When we instantiate a constructor function, we primarily have two choices in syntax in JavaScript¹: ES5 and ES6. ES5 is more familiar to most coders, as it doesn't take away any of the syntax that has been since JavaScript's creation. ES6 is functionally identical, but it adds a lot of syntactic sugar to make it much more convenient to look at.

For the examples, we will be using ES5 syntax.

For ES5, when we want to call what's called the superclass, or its "parent" class, We do this with the conveniently-named .call(this). this is called for the context, as we want the constructor itself to be instantiated with the parent class. Also don't forget to pass in any relevant arguments your subclass needs defaulted by the superclass!

Also keep in mind that because we call the superclass on the subclass itself, that means the prototype is also copied. Make sure to copy that with Object.create(<superclass>.prototype) to the proper constructor name before you move on. Same goes with the prototype.constructor specifically. Remember, you copied the proto, so you should make sure all names are relevant to their context.

// Superclass declaration
const Auto = function(owner) {
  this.owner = owner;
};
Auto.prototype.drive = function() {
  /* {...} */
};

// Subclass declaration
const Car = function(make, model, owner) {
  // Calling the superclass, Auto, with .call(this), also passing in the owner param.
  Auto.call(this, owner);
  this.make = make;
  this.model = model;
};
// Copying the proto...
Car.prototype = Object.create(Auto.prototype);
// Changing the constructor function. This is important for when the call stack needs 
// to refer back to something. As with everything, you should ALWAYS keep information 
// relevant.
Car.prototype.constructor = Car;

ES6 however, doesn't need to do that whole Object.create() thing after the base function. In fact, because ES6 has completely different syntax, you do things just as differently. When you define your constructor() {}, you start by calling the superclass with the aptly named super() function, once again passing in the relevant parameters.

On top of that, instead of doing <superclass>.call(this, ...args), to define what the superclass is, you use yet another keyword that ES6 added in, that being extends. You place it after your class name, but before the code block.

// Superclass
class Auto {
  constructor(owner) {
    this.owner = owner;
  }
  drive() {
    /* {...} */
  }
}

// Subclass
// Notice how we add "extends Auto" after the normal naming.
class Car extends Auto {
  constructor(make, model, owner) {
    // super(owner) is basically <superclass>.call(this, owner). In this case,
    // <superclass> is Auto.
    super(owner);
  }
  // And we don't need anything else. "extends" does that jumble of mess below the
  // base for us.
}

And if you're feeling extra brave, know that subclasses can also have their own subclasses, same rules applied as before. This makes a "tree" of call chaining, calling the more and more general parent classes to get back all of the properties that should be owned by ALL subclasses, or to hardcode certain parameters, depending on what you're trying to do.

class Car extends Auto {
  constructor(make, model, owner) {
    super(owner);
    this.make = make;
    this.model = model;
  }
}

class FordCar extends Car {
  // Notice how the parameters for the constructor get shorter the more hardcoded things
  // you enter.
  constructor(model, owner) {
    super('Ford', model, owner);
    this.model = model;
  }
}

class FordFocus extends FordCar {
  constructor(owner) {
    super('Focus', owner);
  }
}
// This could go on for a while, but you get the idea.

/*
  And in case you need a bit more of a visual...
  FordFocus('James') is calling
  FordCar('Focus', 'James') which is calling
  Car('Ford', 'Focus', 'James').
*/

Conclusion

Polymorphism is a fairly simple concept primarily in Object-Oriented Programming used to create a "tree" of constructors, to cut down on the code required to write, which seems menial in small examples like these, but can be a lifesaver in much bigger projects. And understanding this concept thoroughly allows you to make your code cleaner, shorter, and with much less hassle than if you were to do it separately.

Superscript References

JavaScript is not a primarily Object-Oriented Programming language, and similarly, the term polymorphism is not reserved to it. It's a concept that's found in languages such as Python, C/#/++, and Java, who focus more heavily on OOP given their structure.

Methods of Instantiation

Corbin Callais — Sat, 27 Jun 2020 03:26:40 +0000

Instantiation is a term used when describing the declaration of a Constructor function, a function that, well, constructs. More specifically, it is a factory function that is used to generate instances of an object.

These kinds of functions are used primarily in Object-Oriented Programming (OOP) to generate objects that are essential to code without having to define each object individually. This also means they can have their own custom methods, which allow you to add, remove, locate, and otherwise do as you please with said objects, either individually or all at once.

Just like how there are multiple ways you can declare a function, you can instantiate constructors in multiple ways. There are 5 different ways: Functional, Functional-Shared, Prototypal, Pseudoclassical, and ES6 Pseudoclassical.

Functional

Functional is, as its name implies, instantiation that is no different than declaring any other function. All of the properties and methods are right there in the object you generate with this kind of constructor.

For sake of examples, let's say you want to make a constructor for mass-producing Car objects.

// First, you would define the function. It's customary to capitalize the first letter, unlike normal camelCase.
function Car(model, make, owner) {

    // Then, define an object. It's also customary to name the object we'll eventually return the same as the constructor.
    const car = {};

    // You can define the values inside or outside (with dot notation), it doesn't matter.
    car.model = model;
    car.make  = make;
    car.owner = owner;

    // We can also create custom methods the same way, but assigning functions.
    car.drive = function() {console.log('Vroom!');}

    // Don't forget to return the object when you're done.
    return car;
}

// And now, if we want to create an object, we simply call it.
const mikesChevySilverado = Car('Silverado', 'Chevrolet', 'Mike');

Upsides:

All of the properties are inside of the object for reference
By far the simplest/easiest method.
- We don't have to deal with mumbo jumbo that the later methods do. #### Downsides
The methods are inside the object alongside the properties. This can hurt situationally, such as finding how many keys there are in a single object.
Being the simplest method, it's also the least optimized to handle generation. Unless there's a specific reason to, or you're learning, it's almost always preferred to use a more optimized method.

Functional-Shared

Functional-Shared is functionally identical to Functional at the end of the day. The key difference between the two is that instead of defining methods inside of the object, you define them in a separate object and extend the constructed function.

Example:

// Same setup as before...
function Car(model, make, owner) {
    const car = {};
    car.model = model;
    car.make  = make;
    car.owner = owner;

    // ...Up to this point. Here we do an extend function, typically by either native or Underscore.JS.
    // The object we're extending car from is at the bottom.
    _.extend(car, carMethods);

    return car;
}

// Here is where we define the methods. This is the object we extend the constructor object with.
const carMethods = {
    drive: function() {
        console.log("Vroom!");
    },
    start: function() {
        /* [...] */
    },
    stop: function() {
        /* [...] */
    }
};

// And now the same as before to make one.
const joeysHondaAccord = Car('Accord', 'Honda', 'Joey');

Upsides

All of the methods are in one place, making it easier to change what they do for all instances.
Slightly splits up and cuts down on the code involved in making the constructor object, leaving a tidier workspace.
Minorly cuts down on memory used, as instead of every object having their own instance of a method, they all point to the original instead.

Downsides

As all of the methods are referencing to the original object, changing the method will effect all instances, not just one. This is not ideal for having special objects that have some sort of individuality (like more specific classes of cars).
The methods are still in the object, which poses the same related problems as with Functional.

Prototypal

Prototypal is the first of this list that doesn't have the methods in the object, but instead in its prototype, hence its name. The prototype is the hidden property all datatypes in JavaScript has that provides properties gained through inheritance. Inheritance is simply a way to give properties to instances of objects.

// From now on, we will use "const <name> = function() {}". It's a more "proper" way to declare functions as of ES6.

const Car = function(model, make, owner) {
    // This is the major change in Prototypal. We use Object.create(), a native Object object method that allows all arguments to go into the created object's prototype. How convenient.
    const car = Object.create(carMethods);
    car.model = model;
    car.make  = make;
    car.owner = owner;

    return car;
};

const carMethods = {
    drive: function() {
        console.log("Vroom!");
    },
    start: function() {
        /* [...] */
    },
    stop: function() {
        /* [...] */
    }
};

console.log(Car("Corolla", "Toyota", "James"));
// Logs {model: "Corolla", make: "Toyota", owner: "James"}. Note how if we were to use Functional or Functional-Shared, we'd also see the methods.

Upsides

The methods are out of the main object, preventing any mistakes stemming from such a problem.
Uses fancier code to cut down on what you need to write for the same purpose.

Downsides

The methods are still shared, only they have changed location. Changing one for any reason will affect them all.
Typically will require a deeper understanding of the native constructors, like Object in Object.create(), in order to use effectively.

Pseudoclassical

Pseudoclassical is considered the "de-facto" method for instantiation, for good reason. It's considered the most optimized more most cases, only being beaten out by ES6's syntactic sugar (it's still functionally identical, though).

Instead of defining the methods on the constructed object, they define them on the constuctor function's prototype, allowing all of the constructed objects to have them, with help with the new keyword.

Additionally, with the new keyword, we don't even need to define the object or return it. We just use this, applying all the applicable properties to it.

// Mostly the same setup, except...
const Car = function(model, make, owner) {
    // We don't even define an object, or return anything. It just knows that "this" is what we're generating.
    this.model = model;
    this.make  = make;
    this.owner = owner;
};

// And then we define the methods on the constructor's prototype. Don't worry too hard on how it works, the "new" keyword just knows.
Car.prototype.drive = function () {
    console.log("Vroom!");
};
Car.prototype.start = function () {
    /* [...] */
};
Car.prototype.stop  = function () {
    /* [...] */
};

// And now to define it.
const samsFordFocus = new Car("Focus", "Ford", "Sam");

Upsides

Much more visually friendly than the other two. I mean, the base function is only three lines.
Makes use of the word this, something that is typed faster than most all other names for objects, increasing work efficiency.

Downsides

Much more complex, would require a major amount of studying to obtain a deep understanding of.
Introduces the new keyword before calling the function. It trips up a lot more new people than one may think.

ES6 Pseudoclassical

By far my personal favorite, ES6 Pseudoclassical is the most user friendly, albeit looking entirely different than the other instantiation types.

It makes use of the new class keyword introduced in ES6, which does all the hard work for you. Inside of the class block, there is a constuctor() function you must define. Below that, however, still within the class block, you define your methods by simply putting their name, their parameters, and their code block.

// Entirely different setup. First, the class...
class Car {
    // Then the constructor. This allows the object generated to have properties.
    constructor(model, make, owner) {
        this.model = model;
        this.make  = make;
        this.owner = owner;
    }
    // Everything below it is put into its prototype. Like methods.
    drive() {
        console.log("Vroom!");
    }
    start() {
        /* [...] */
    }
    stop() {
        /* [...] */
    }
}

// To call it, it's the same as Pseudoclassical. Don't forget the "new" keyword.
const aaronsKiaSorento = new Car("Sorento", "Kia", "Aaron");

Upsides

Much simpler, more user friendly, and stands out more than any boring old function.
Does most of the heavy lifting for you.

Downsides

Being ES6, it requires specifications to allow it to run. Typically not a problem in this day and age, but older browsers don't understand ES6.
Also because ES6, it requires you to learn an entire new set of syntax to use and understand this. Now a problem for newer learners, but people coming from ES5 and earlier would have some issues getting used to it.

Conclusion

Each type of instantiation all does one core thing, that being generating instances of objects that have certain properties and methods to use in your code.

Functional and Functional-Shared are the most familiar to novice coders, since they're just functions and objects with minor differences between the two.

Prototypal Makes use of the prototype chain, making it slightly more complex just to not include the methods in the main object.

Pseudoclassical is the most optimized for the majority of cases, and ES6 Pseudoclassical is just the ES6 version of that, functionally identical but much easier on the eyes.

DEV Community: Corbin Callais

Promises

Introduction

Building a Promise

.then() and .catch()

Conclusion

Superscript References

Databases and MySQL

Introduction

ACID

Atomicity

Consistency

Isolation

Durability

SQL

Queries

Conclusion

Superscript References

Rundown of React

Introduction

ReactJS

"props" and Templating

Stateless and Stateful

Compiling

Conclusion

Superscript References

Polymorphism

Introduction

How does it work?

Conclusion

Superscript References

Methods of Instantiation

Functional

Upsides:

Functional-Shared

Upsides

Downsides

Prototypal

Upsides

Downsides

Pseudoclassical

Upsides

Downsides

ES6 Pseudoclassical

Upsides

Downsides

Conclusion

`.then()` and `.catch()`