DEV Community: Jason

Let's get Sassy 💅

Jason — Mon, 07 Dec 2020 07:34:14 +0000

What is Sass?

Sass or syntactically awesome stylesheets is a preprocessor for CSS that fixes many of the pain points most developers have with CSS.

There are two types of Sass

SCSS (.scss) → "sassy css"
Sass (.sass) → "syntactically awesome stylesheets"

Here we are going to focus on .scss version of Sass since most the syntax for .scss is nearly the same as traditional .css files, and will be more useful to most developers than learning an entirely new syntax. Along the same vein, comparing .scss with .css files will be easier than .sass files since they look more python-like in their syntax.

What's wrong with CSS? 😑

Since Sass is a preprocessor of CSS, you could write .scss files in vanilla CSS, but you'd be missing out on all the awesome features that the Sass preprocessor provides. The core of those features really aim to address the scalability and maintainability of CSS in modern web applications.

With sassy css, you have all the power of CSS... plus

variables (_technically you can use variables in .css files, but its just better with sass)
nesting
mixins
inheritance

Getting Started 🏁

So before you can do anything, you've need to get the Sass compiler installed. For the latest instruction, check out the sass install documentation, but for the tl;dr; version you can get the Sass compiler setup globally using Node.js/NPM using the sass module.

npm install -g sass

You can also install the Sass preprocessor using homebrew.

brew install sass/sass/sass

this installs the Node sass implementation of the pre-processor which is currently deprecated - while the sassy engineering team has said that this package will continue to receive updates the most up-to-date version is dart sass

Once its installed, you can compile .scss files (or .sass files) using sass <source-file> <output-file> like so

sass source/stylesheets/index.scss build/stylesheets/index.css

With the compiler installed, lets get sassy!

Sass Selectors 💃

As mentioned previously, files written in .css are 100% valid as .scss files. So comments and selecting html elements can be done in the same syntax:

comments
- single line comments can be made using a double slash (//)
- multi-line comments can be denoted slash-start (/*) and star-slash (*/) , with the /* denoting the start of the multi-line comment and the */ denoting the end of the multi-line comment
selectors
- tags
  - tags are selected simply by placing the tag name
  - header selects <header> element
- classes
  - select classes using . followed by the class name (e.g. nav-links)
  - .nav-link selects any elements with a class="nav-link"
- id
  - select an element by it's id using # followed by the id
  - #root selects any element with id="root"
block
- the actual rules of .css and .scss files
- defined between curly braces ({})
- each line / statement should terminate with a semi-colon ;

/* select an element by using its name */ 
body {
    display: flex; 
}
/* select an element by its ID */
#root {
    margin: 0; 
}
/* selecting elements by class */
.nav-links {
    text-decoration: none; 
}

Sassy selecting 👌

One of the first features .scss improves on from .css is the selection of nested elements. Imagine you are styling a basic navbar for a website:

<!--- index.html -->
<html>
  <body> 
    <header>
      <nav>
        <span class="logo">Sassy</span>
        <ul>
          <li>
            <a href="#">Home</a> 
          </li>
           <li>
            <a href="#">About</a> 
          </li>
           <li>
            <a href="#">Contact</a> 
          </li>
        </ul>
      </nav> 
    </header>
  </body> 
</html>

codepen

You might do something like:

/* CSS */
html {
  margin: 0; 
  padding: 0; 
}
header {
  border-bottom: 1px solid #1F7A8C; 
}
nav {
  display: flex; 
  margin: 0 2rem; 
  justify-content: space-between; 
}
nav span.logo {
  font-family: cursive; 
  font-weight: bold; 
  font-size: 2rem; 
  align-self: center; 
  height: 50px; 
  width: 100px; 
  border-radius: 50px; 
}
nav ul {
  display: flex; 
  align-items: center; 
}
nav ul li {
  list-style: none; 
  display: flex; 
  height: 50px; 
  width: 100px; 
  border-radius: 50px; 
  background: #BFDBF7;
  justify-content: center;
  margin: 0.2rem 1rem;
  border: 1px solid #1F7A8C; 
  color: #053C5E; 
}
nav ul li a {
  color: inherit; 
  font-family: monospace;
  align-self: center; 
  font-weight: bold; 
  font-size: 1.3rem;
  place-content: center; 
  text-decoration: none; 
 }

Nesting selectors ⇣

Instead of repeating nav ul at the beginning of each selection statement as we did in or .css file, we can nest the selector definitions inside one another.

html {
  margin: 0; 
  padding: 0; 
  header {
    border-bottom: 1px solid #1F7A8C; 
    nav {
        display: flex; 
        margin: 0 2rem; 
        justify-content: space-between; 
        span.logo {
            font-family: cursive; 
            font-weight: bold; 
            font-size: 2rem; 
            align-self: center; 
            height: 50px; 
            width: 100px; 
            border-radius: 50px; 
          }
          ul {
            display: flex; 
            align-items: center; 
          }
          li {
            list-style: none; 
            display: flex; 
            height: 50px; 
            width: 100px; 
            border-radius: 50px; 
            color: #053C5E; 
            background: #BFDBF7;
            justify-content: center;
            margin: 0.2rem 1rem;
            border: 1px solid #1F7A8C; 
            a {
                color: inherit; 
                font-family: monospace;
                align-self: center; 
                font-weight: bold; 
                font-size: 1.3rem;
                place-content: center; 
                text-decoration: none; 
               }
          }
      }
  }
}

Notice how each selector is nested inside the curly-braces ({}) comprising it's parent selector.

Notice how the .scss version shorter, but it's easier to understand and easier to read.

Solely with the information of the .scss file above, we know that the <nav> element is a child of the <header> element because the nav selector is nested inside the header selector. We don't need to repeat selectors in nested selector statements either.

In this simple example, the benefit might seem negligible, but this becomes increasingly valuable as your stylesheets grow in size.

Sassy Pseudo selectors 🥸

Given the previous .html file we looked at before, how would you add the :hover pseudo selector in CSS?

/* redefine the entire selector hierarchy (nav ul li) and apped pseudo selector */
nav ul li:hover {
    transition: 1s all ease; 
    color: #000;  /* make the text black */
    filter: invert(100%);  /* invert the default colors */
}

The Sassy way emphasizes the DRY principle, instead providing its own pseudo selector to address these style definitions.

In Sass, the ampersand (&) represents the parent selector, and enables chaining. So if we can define seperate styles for mouse over (:hover), visited pages (:visited), the last item (nth()) and all the other pseudo selectors like so

/* abbreviated .scss file */
/* css removed from most of document for simplicity */ 
html { /* styles.. */
  header { /* styles.. */
    nav {  /* styles.. */
        span.logo { /* styles.. */}
          ul { /* styles.. */}
          li {
            /* & represents parent (li) */ 
            /* ⬇️ hover styling ⬇️ */
            &:hover {
                transition: 1s all ease; 
                color: #000;  /* make the text black */
                filter: invert(100%);  /* invert the default colors */
            }
            a { }
          }
      }
  }
}

The & refers to the selector parent, so since we are in the body of the li's styling, the li tag is the parent select the & symbol is referencing.

We can use the & operator in our sassy .scss files in conjunctions with all the same pseudo selectors as .css files.

li {
    &:hover {
        /* hover pseudo selector */
    }
    &:focus {
        /* focus pseudo selector */ 
    }
}
a {
    &:visited { 
        /* visited pseudo selector */ 
    }
}

But we can get sassier. In .scss we can truly embrace the DRY principles and use the & operator to append to the parent selector.

So if we have an element with the class .hero, and inside that element, there are other elements that have classes starting with .hero, we can append to the class selector using the & operator:

.hero {
    &-container {
        /* equivalent to `hero-container` */
    }
    &-title {
        /* equivalent to `hero-title` */
    }
    &-sub-title {
        /* equivalent to `hero-sub-title` */
    }
}

🕺 Variables with sass

Variables in .scss files start with the dollar-sign symbol ($), and can store any valid CSS value.

$primary-color: #053C5E; 
$secondary-color: #BFDBF7;

We can then assign the values stored in our sassy variables simply by placing where ever we need it:

body {
    background: $secondary-color; 
    color: #053C5E; 
}

When the .scss file is run through the Sass compiler, the variables values will be replaced with the value assigned to the variable. While native CSS does allow for variables, Sass does it better.

Another benefit to .scss variables is that they can be mutated from the start of the file to the end, without altering the v

Sass variables support being mutated from the start of the file to the end. If you assign $primary-color: #053C5E, on line 10, and re-assign it on line 254 mutated the value such that $primary-color: #000, every subsequent block will substitute $primary-color will receive the color code of #000, while every element before its re-assignment on line 254 will remain the original value of #053C5E.

Sass	CSS	Ramifications
Sass variables are replaced with their values by the Sass compiler	CSS variables are loaded and interpreted by the browser	more overhead for the client browser
Sass variables are pre-fixed with `$varName` and called using `$varName`	CSS variables are declared using `--varName` and are scoped to the tag that they are defined in	using variables is more complex, syntactically longer, and more difficult to read
Sass is transpile to basic CSS	CSS variables are only supported by newer browsers (explorer will not work)	Sass compiles `.scss` files such that the resulting configuration has more compatibility than CSS variables

Just like most developers are used to, variables defined using $varName are scoped to the block, (i.e. between { and }) that they were defined in. If you define at the root of your .scss document, it will be scoped to the entire document, define it within the scope of a selector it will be scoped to the parent selector and its children.

body {
    /* variables defined here will only be accessible within the body 
     * of the selector and its nested selectors */
    $font-size: 12px; 
    p {
        /* 👍 we CAN access $font-size here ✅ */
    }
}
/* 👎 we CANNOT access $front-size here ⛔️ */

Sass variables mutated from the original values start of the file to the end. If you assign $primary-color: #053C5E, on line 10, and re-assign it on line 254 mutated the value such that $primary-color: #000, every subsequent block will substitute $primary-color will receive the color code of #000, while every element before its re-assignment on line 254 will remain the original value of #053C5E.

$color: #333; 
body {
    $color: #444; /* mutation scoped to this block */
    p: $color: ; /* color → #444 */
}
footer {
    p: $color; /* color → #333 */
}

Sassy Mixins and At-rules 🌀

Mixins are like JavaScript functions:

they can be declared as a variable and re-used in multiple locations
they can take 0 or more arguments
they can be scoped (like a function assigned to const)

You begin a mixin with @mixin followed by the name of the mixin you are defining.

Then place all the .css rules between the opening curly brace ({) and the closing curly brace (}) that make up the mixins body.

/* reset properties associated with a list */
@mixin reset-list {
  margin: 0;
  padding: 0;
  list-style: none;
}

We can then use apply our @mixin reset-list anywhere it makes sense to do so, including inside another @mixin definition using the @include at-rule, followed by the name of the mixin (e.g. reset-list).

/* apply mixin to navbar  */
nav ul {
  @include horizontal-list;
}

/* apply mixin to another mixin */
@mixin horizontal-list {
  @include reset-list;

  li {
    display: inline-block;
    margin: {
      left: -2px;
      right: 2em;
    }
  }
}

sass docs

Adding arguments to sassy @mixin is remarkable similar to the syntax used in JavaScript as well.

The @mixin variable-name remains the same, but before the opening curly brace defining the .css properties, we place any parameters delimited by commas (,) and surrounded by parenthesis.

@mixin rtl($property, $ltr-value, $rtl-value) {
  #{$property}: $ltr-value;

  [dir=rtl] & {
    #{$property}: $rtl-value;
  }
}

.sidebar {
  @include rtl(float, left, right);
}

Every rule previously mention applies here as well. Each variable ($variableName) will be subsituted for the parameter provided to the mixin when we declare the mixin using the @include mixin-name followed by the parameters wrapped in parenthesis.

mutating a mixin will only affect subsequent code
same scoping rules apply
same syntax for declaring and using variables

We can define default values for @mixins using a colon (:)

@mixin replace-text($image, $x: 50%, $y: 50%) {
  text-indent: -99999em;
  overflow: hidden;
  text-align: left;

  background: {
    image: $image;
    repeat: no-repeat;
    position: $x $y;
  }
}

.mail-icon {
  @include replace-text(url("/images/mail.svg"), 0);
}

Interpolation

Interpolation can be used almost anywhere in a Sass stylesheet.

to define classes
to define css properties
to define values of css properties
to combine variables

@mixin inline-animation($duration) {
  $name: inline-#{unique-id()};

  @keyframes #{$name} {
    @content;
  }

  animation-name: $name;
  animation-duration: $duration;
  animation-iteration-count: infinite;
}

.pulse {
  @include inline-animation(2s) {
    from { background-color: yellow }
    to { background-color: red }
  }
}

Using a variable in a property value doesn't require interpolation. (e.g. color:#{$accent} === color: $accent)
interpolated variables will be returned as strings.

Mixin and Flow Control 🪖

Mixins provide for a variety of flow control with @if, @else, @while ,@each and @for at-rules.

@if determines whether or not a block is evaluated.
@each evaluates a block for each element in a list or each pair in a map.
@forevaluates a block a certain number of times.
@while evaluates a block until a certain condition is met.

/* only apply a border-radius if the the radius is not 0  */
@mixin square($size, $radius: 0) {
  width: $size;
  height: $size;

  @if $radius != 0 { /* must evaluate to True/False */
    border-radius: $radius;
  } 
  @else { /* can only be included if there is an `@if` at-rule */
    border-radius: unset; 
  }
}

You can implement if → else if → else logic by inserting a @else if at-rule following an @if at-rule and before an @else at rule

@mixin triangle($size, $color, $direction) {
  height: 0;
  width: 0;

  border-color: transparent;
  border-style: solid;
  border-width: $size / 2;

  @if $direction == up {
    border-bottom-color: $color;
  } @else if $direction == right {
    border-left-color: $color;
  } @else if $direction == down {
    border-top-color: $color;
  } @else if $direction == left {
    border-right-color: $color;
  } @else {
    @error "Unknown direction #{$direction}.";
  }
}

anything with a determined value is truthy and anything that is null is falsey

Looping ➰

We can implement looping in @mixins using @for at-rule and interpolation.

@mixin order($height, $selectors...) {
    /* increase the margin top for each element selected 
     * in $selectors */
  @for $i from 0 to length($selectors) {
      /* interpolate the selector using the `nth` function */
    #{nth($selectors, $i + 1)} {
      position: absolute;
      height: $height;
      margin-top: $i * $height;
    }
  }
}

The @each at-rule works similarly:

/* collection of sizes */
$sizes: 40px, 50px, 80px;

/* loop through the values applying the size to the 
 * matching class (e.g. `icon-50px` ) */
@each $size in $sizes {
  .icon-#{$size} {
    font-size: $size;
    height: $size;
    width: $size;
  }
}

You can also loop through collections using the @while mixin, but doing so typically is implented using functions, which definitely goes beyond the basics, and we've already covered a lot here.

Wrap up

These are the fundamentals of Sass, but there's lots more to it. There's more at-rules as well as functions and modules. However, even without functions, or mixins, Sass makes styling a more readable, more maintainable, and more concise way to add styling to html.

So the question is, do you want to get sassy? 💅

🧐 Demystifying Big 🅾️

Jason — Mon, 30 Nov 2020 06:27:22 +0000

What is Big 🅾?

Big O is fundamental in the world of computer science, yet many developers and engineers often struggle to understand it.

Most people know its important, and its commonly something software engineers to ruminate upon, exaggerating the complexity and difficulties in understanding and using Big O.
This fear can often results in avoidance of the topic.

Let's stop fearing it, and start getting excited about it. Big O can be a helpful tool to help developers and software engineers to improve the quality and efficiency of code.

Learning Objectives

provide an introduction into Big O notation
define "algorithms" in the context of Big O
define time complexity/efficiency
- asymptotic behavior
- worst-case analysis
explain how to calculate time complexity
- step-by-step breakdown
- code examples
define the fundamental types of asymptotic complexity
Differentiate between O, o, θ, Ω and ⍵

Here we will focus Big O are in terms of time complexity since this is what most people are referring to when discussing Big O.

Algorithms → Big 🅾

Algorithms are programmatic operations that performs a computation to calculate a value or values.

Big O is the standard notation computer scientists use to define, discuss, compare and quantify the performance of algorithms using mathematical terms.

define how the algorithm responds to an increasing number of input values (quantify how algorithm scales)
mathematically compare the efficiency of different algorithms

Complexity Analysis & Time Complexity

Complexity analysis is a tool for determining how an algorithm responds to increasing inputs. It can be defined in terms of both spacial efficiency as well as time complexity.

time complexity refers to the efficiency of an algorithm in respect to the amount of time an algorithm requires to execute completely as its input increases.
spacial complexity refers to the efficiency of an algorithm in respect to the amount of memory (RAM) it consumes as the input increases.

Note: this article, we will be focusing on time complexity

Lots of Factors

The speed at which a computer can execute (complete) and algorithm is impacted by a wide variety of factors:

Hardware
- CPU Clock Speed
- CPU Cores (dual-core, quad-core, etc.)
- Cooling Ability (ability to dispense head from critical components under load)
- RAM read/write speed
- Hard-drive read/write speed
- Available disc
Network
- Network speed (up/down)
- Concurrent Network Operations
Software
- Operating System (Mac, Windows, Linux)
- Concurrent applications
- Security & monitoring software

The key idea here is that finite execution speed is highly variable. When we calculate an algorithms time complexity we simplify the calculation to only include the specific instructions executed as a direct result of an algorithm, ignoring all the factors that may impact execution speed when they are outside the scope of the algorithm.

Calculating Time-Complexity

Calculating an algorithm's time complexity begins by breaking down the operation into individual steps.

What's a step?

In the context of big O and algorithmic complexity...

a step is NOT → 🚫
- a function
- a line of code
- a statement in code
- a block of code
a step is → ✅
- a single unit of work executed by the central processing unit (CPU).

This includes operations like:

assigning a value to a variable
looking up the value of an element in an array
comparing two values
incrementing/decrementing a value
a single arithmetic operation (addition, subtraction, multiplication, division)

and many more.

The goal is to break down an algorithm into the smallest unit of work that a computer can perform in a single step.

Learn by Example

One of the best ways to illustrate calculating time-complexity is to work through a real example.

Take the maximum function below:

const arr = [45,23,67,32,11,17,94,16,47,42,23] // input 

function maximum(arr) {
    let max = arr[0]
    for(let i = 1; i < arr.length; i++){
        if(arr[i] > max) {
            max = arr[i]
        }
    }
    return max 
}

The function maximum defined above is an example of an algorithm. It is a strictly defined process for finding the largest value in a collection of numbers.

The maximum function involves the following steps

create max variable (allocate memory)
look up value of item at index 0 in arr (e.g. arr[0])
assign the value returned as to max variable (e.g. max = arr[0])
create i variable (e.g. let i)
assign i a value of 1 (e.g. let i = 1)
define loop termination condition (e.g. i < arr.length)
define loop increment (i++)
retrieve the value at position 1 in arr (e.g. arr[1] → 23)
compare the value of the element retrieved to max (e.g. arr[i] > max)
since arr[1] is 23 in the example above, the loop concludes and restarts
increment i (e.g. i++)
lookup value at arr[2] (since i = 2)
compare arr[2] with max
since arr[2] = 67 and max = 45, arr[i] > max evaluates to true (e.g 67 > 45)
enter if block
re-assign max = arr[i] (e.g. max = 67)
increment i (e.g. i++)

... and continuing the loop block until the loops terminating condition (i <arr.length) is reached.

Now since we are focused on time-complexity, we need to differentiate between setup steps, and the steps that are impacted by the size of the input. In other words, define which steps would increase as the input to the algorithm increases, from the steps that would execute regardless of the size of the input.

So given the maximum algorithm:

Independent Steps (required regardless of input size)
- create max variable
- assign max to the first value of the input (arr[0])
- creating loop statement
  - the i variable
  - assigning the i variable a value of 1
- returning the max value
Dependent Operations (execute a variable number of times depending on input size)
- Number of times we have to increment i
- Number of times we have to lookup a value from the input arr[i]
- comparing the value of arr[i] to max
- assigning max a value

Remember: we are time complexity is quantifying how an algorithm responds to an increasing input

Given the above, we can state objectively that the maximum function has

4 independent operations
4 dependent operations

Or as a mathematical function where n represents the size of the input: f(n) = 4n + 4

4 referring to the operations that are not affected by n
4n referring to the operations affected by n

Worst-case Scenario

After distinguishing the individual steps of an algorithm, we need to determine how those execution steps are affected by different types of input.

We start evaluating input types with what is called the worst-case scenario. In terms of time-complexity, the worst case scenario refers to an input that would require the most operations to complete.

In the example of the maximum function, the worst-case scenario would be the scenario in which the input array was sorted smallest to largest, which would require every iteration through the for loop to evaluate the if (arr[i] > max) as true, and thus executing an additional steps defined inside the if block.

if ( arr[i] > max ) {
    max = arr[i]
}

So using the 4 independent steps, 4 dependent steps, and 2 conditional steps, we can alter the previous formula to add the conditionally dependent steps outlined as part of the worst-case scenario: f(n) = 4n + 4 + 2n or simplified as f(n) = 6n + 4

Asymptotic behavior

In complexity analysis, we are primarily concerned with how the function (f(n)) behaves as the input (n) grows.

So the next step in calculating the time-complexity is to eliminate (ignore) all the independent variables (the steps that occur regardless of the input size) from the equation.

In the case of the mathematical function defined earlier (f(n) = 6n + 4), 4 is constant regardless of the input size, however the 6n grows directly as the size of the input grows larger. We refer to these independent operations as 4 "initialization constants".

Initialization Constants

Initialization constants are the steps of an algorithm that will execute regardless of the size of the input. Including "behind the scene" initialization operations like the virtual machine required for Java.

When we remove our initialization constants, our mathematical function for maximum is stated simply as f(n) = 6n

We remove initialization constants because these steps are not affected by the input size, or the input values. Instead they are a direct result of the syntax and rules of a high-level programming language. Initialization constant can vary quite dramatically from one language to another, and do not help to clarify how an algorithm responds to increasing input sizes (time complexity).

Asymptotic behavior refers to an algorithms time complexity with intialization constants removed.

Common Types of Asymptotic Behavior

Given this behavior we can conclude:

A algorithm that does not require any looping will have a complexity of f(n) = 1 since the number of instructions is constant regardless of the size of the input
A algorithm with a single loop, which loops from 1 to n will have a complexity of f(n) = n since it will perform the instructions inside the loop a constant number of times.
An algorithm with a nested loop (a loop inside another loop) will have a complexity of f(n) = n² since the execution time will increases by a factor of n as the size of the input (n) increases in size.

Now to take everything that we've discussed an put it in the computer science language of Big O is pretty simple. Essentially we've already done it.

f(1)
- represents algorithms with a constant number of instructions
- alternatively, you could say the size of the input does not affect the execution time of the algorithm
- mathematically, we would represent this as f(n) = 1
- is referred to as a "constant time"
- execution time is constant regardless of the size of the input
f(n)
- represents an algorithm that's execution time grows in direct proportion to the size of the input
- alternatively, the size of the input directly affects the algorithms execution time
- mathematically, we would represent this as f(n) = n
- is referred to as a "linear time"
- execution time grows in direct proportion to the input (n)
f(n²)
- represents an algorithm that executes proportionally at a rate of n squared compared to the input siz
- mathematically, we would represent this as f(n) = n²
- is referred to as quadratic time
- execution time grows in a quadratic fashion as the input increases.

... and this would continue as the exponents representing the function grows.

Remember the key idea here - we are trying to indicate how an algorithm scales as the input to the algorithm increases. Algorithms with a larger θ will execute more slowly than algorithms with a smaller θ

Asymptotic Complexity & Bounds

It is important to understand that O(n) (pronounced "Oh of n") and θ(n) (pronounced "theta of n") do not have the same meaning.

Algorithms expressed in terms of θ ("theta") are expressed in terms of "tight bounds".
With tightly bound complexity, an algorithm will consistently execute at the rate expressed by the function of theta.
Algorithms with complexities expressed in O are defining the upper bounds or worse case scenario for execution steps.

The difference here is between O and θ really comes down to how much variability there is in the equation.

Take Array.find(x => condition) function:

const input = [5, 12, 8, 130, 44];
const found = input.find(element => element > 10);

console.log(found); // 12

The .find method iterates through every element in the array, and return the first element that matches the provided logical comparison.

Under the hood, the .find function is performing the following:

function find(collection, condition){
    for(let i = 0; i < collection.length; i++){
        const item = collection[i]
        if(condition(item)) {
            return item 
        } 
    }
    return null; 
}

In summary .find:

loops through a collection
With each iteration passing each element as a parameter to the function provided (condition)
Depending on the return value of condition(item)
- true indicates a match has been found and the value is returned
- false indicates a non-match, and the loop continues
If no match has been found by the end of the loop through the collection, then a null value is returned

Assuming Array.find works like the function defined above:

If the first element in the collection matches the provided condition to the Array.find algorithm could complete with only a single iteration. This possibility indicates an algorithm that's worst-case scenario involves looping through the entire collection.
- This would be a linear-time-complexity or f(n) = n
- Since this is the upper bound, we could also express it as o(n)

There are 3 primary types of bounds in asymptotic functions:

O(n) denotes the mathematical function in the worst case scenario
- pronounced "big O of n"
- referred to as upper bound
- Worst-case scenario
  - Most execution steps
  - Longest execution time
- Greatest time-complexity
- Least efficient
θ(n) denotes the mathematical function of the exact time-complexity of a an asymptotic function given any input.
- pronounced "theta of n"
- referred to as tightly-bound
- Exact
- exact execution steps
- consistent response to increasing input size
- consistent efficiency regardless of input values
- consistent complexity regardless of input values
Ω(n) denotes the mathematical function provided the best case scenario (fastest execution)
- pronounced "omega of n"
- referred to as lower bound
- Best-case
- Least execution steps
- Best-case scenario
  - Lest execution steps
  - Fastest execution time
- Least time-complexity
- Most efficient

This can be broken down further between O vs. o and Ω vs ꞷ or "big O vs little O" and "big omega vs little omega":

Notation	Pronunciation	Bound	Numeric Operator	Meaning
`O`	"big O"	tight-upper	`<`	maximum possible number of execution steps (tightly bound)
`o`	"little O"	upper	`≤`	highest possible number of execution steps
`θ`	"theta"	tight	`=`	exact number of execution steps (tightly bound)
`Ω`	"big omega"	lower	`≥`	least number of execution steps
`ꞷ`	"little omega"	tight-lower	`>`	least number of execution steps (tightly bound)

Tight refers to how accurate the mathematical function representing the asymptotic complexity is for a given algorithm.

Learn by example

The best way to learn is to do it, so join me in taking apart a sorting algorithm and examining its asymptotic time-complexity.

Sorting Algorithms

Sorting Algorithms are algorithms that sort a collection of items by a specific attribute. These algorithms are prevalent in nearly every modern application.

Examples of sorting algorithms:

Sorting files in Finder/Windows explorer (Alphabetically, by size, by file type, etc.)
Sorting shopping results (by price, by rating, by sales, etc.)
Sorting contacts (by first name, by last name, by date of birth, by workplace, etc.)
Sorting job posting (by post date, by industry, by company, etc.)

There are numerous realistic and practical application for sorting algorithms, and like many algorithms, there is multiple ways to tackle the same problem.

Selection Sort

A "selection sort" algorithm takes an input, and sorts it according to some arbitrary value. Take a number selection sorting algorithm like the one below:

function selectionSort(arr){
    const inputArr = [...arr]
    const output = []

    while (inputArr.length > 0) { 
        let min = inputArr[0]
        let minIndex = 0

        for(let i = 1; i < inputArr.length; i++) {
            if (inputArr[i] < min) {
                min = inputArr[i]
                minIndex = i 
            }
        }

        output.push(inputArr.splice(minIndex, 1))
    }

    return output
}

The basic sorting function (selectionSort) defined above sorts values from smallest to largest by:

copying the input (to avoid modifying by reference)
iterating through the copied array (inputArr) and removing the smallest element (min) from the input array amd adding it to the output array.
repeating step 2 until the inputArr has no elements left

Challenge Go ahead and see if you can calculate the complexity (in big O notation and θ notation) yourself.

Calculating Selection Sort Time Complexity

Recall, we mathematically determine complexity by:

determining the individual steps executed by the CPU
1. create inputArr
2. copy arr into inputArr
3. create output
4. initialize output = []
5. create loop
  1. create i
  2. assign i = 1
  3. lookup inputArr[i]
  4. compare inputArr[i] < min
  5. optionally, assign min = inputArr[i]
  6. optionally, assign minIndex = i
  7. increment i
  8. check condition (i < inputArr.length)
  9. repeat loop while i < inputArr.length
6. remove min element from inputArr
7. add it to minimum value to output array
8. check inputArr.length > 0
9. optionally, loop
determine which steps are dependent steps
- dependent
  - lookup inputArr[i]
  - inside loop:
    - compare inputArr[i] < min
    - optionally, assign min = inputArr[i]
    - optionally, assign minIndex = i
    - increment i
    - repeat loop while i < inputArr.length
  - remove min element from inputArr
  - add it to minimum value to output array
  - check inputArr.length > 0
  - optionally, loop
- independent
  - create inputArr
  - copy arr into inputArr
  - create output
  - initialize output = []
  - create loop
    - create i
    - assign i = 1
determine the worst-case scenario
- the execution of both loops (for and while) are both directly impacted by the size of the input, and unaffected (in terms of execution time) by the values of the input.
remove initialization constants

Walking through the Selection Sort

The while loop that states we continue looping until every element from inputArr has been removed. Then with each iteration through the while loop, a nested for loop through the same collection of elements is executed to find the smallest value.

the first pass inputArr, will determine 11 is the smallest element in the inputArr and remove it, placing it in output
The second pass through inputArr will determine 12 is the smallest value, and remove it from inputArr, placing the value in output
The third pass through inputArr , will determine 22 is the smallest value, remove it from inputArr, placing the value in output
The fourth pass through inputArr , will determine 25 is the smallest value, remove it from inputArr, placing the value in output
The fifth pass through inputArr , will determine 64 is the smallest value, remove it from inputArr, placing the value in output
The sixth pass through inputArr , will determine that there are no more elements within inputArr, and exit the loop.
The output will be returned with the elements sorted from smallest to largest [11, 12, 22, 25, 64]

Overall we can summarize the behavior of an input [11, 25, 12, 22, 65] with the following table:

loop	`output`	`inputArr`	`min`	`inputArr.length`	`output.length`
0	`[]`	`[11, 25, 12, 22, 64]`	`11`	5	0
1	`[11]`	`[25, 12, 22, 64]`	`12`	4	1
2	`[11, 12]`	`[25, 22, 64]`	`22`	3	2
3	`[11, 12, 22]`	`[25, 64]`	`25`	2	3
4	`[11, 12, 22, 25]`	`[64]`	`64`	1	4
5	`[11, 12, 22, 25, 64]`	`[]`		0	5

Overall the selectionSort function
- Is comprised of two (2) loops
- The outer-most loop executes n times
- the inner loop executes n times

In the worse case scenario both loops are executed 5 times for an input with 5 elements. In terms of a mathematical function, we could represent this as f(n) = n * n or f(n) = n².

Since the there is no scenario in which this algorithm will execute faster than f(n) = n²

Cheers 🥂 to you if you got that 👍

The sorting algorithm outlined above is a highly inefficient method of sorting 🧠 If you are up for a challenge, see if you can think of a more efficient algorithm for sorting numbers 🧠

Recursion

Recursion refers to the process in which a function calls itself to determine the end result. Recursion occurs very commonly, you'll find recursive functions in:

calculating the number of .jpeg files in a folder
- every folder inside the root folder must also run the same function
calculating the size of a folder
- every folder inside the folder must also be calculated
factorials
- to find the factorial of 5, you first find the factorials of 1, 2, 3 and 4

... and many more.

Recursive Complexity

One of the simplest examples of a recursive algorithm is factorials. A factorial is a defined as the product of every integer between a number and 0. So determining the factorials of 1 through 5 would look like:

Input	Math Equation
`1`	`f(1) = 1`
`2`	`f(2) = 2 * 1`
`3`	`f(3) = 3 * 2 * 1`
`4`	`f(4) = 4 * 3 * 2 * 1`

Functionally, we would calculate a factorial using recursion.

function factorial(number) {
    if (number = 1) return 1 
    return number * factorial(number - 1)
}

Given the above function, can you determine the asymptotic complexity?

The factorial(number) function above does not have any loops. Previously algorithms without any loops had a constant runtime, however with the factorial(number) function, this is not the case. As you can imagine the greater the input value, the greater the number of execution steps, and the simple recursive function above would have a linear complexity or complexity of θ(n).

This begs the question: Do recursive functions always have linear complexities?

Another recursive function referred to as "binary search" is slightly more complicated. In binary search algorithms, the function receives a collection of sorted values. Since the input to the function is sorted, some optimizations can be made to more quickly find the desired value.

Imagine the function:

function findIndexFromSorted(array, target) {
    let start = 0 
    let end = array.length - 1 
    while(start <= end){ 
        let middle = Math.ceil((start + end) / 2) 

        // make sure we always have a valid middle value 
        if (middle > array.length - 1) middle-- 

        // see if middle element is target 
        if (array[middle] === target) return middle  

        // check right side 
        if (target > array[middle]) {
            start = middle + 1 
            continue 
        }

        // check left side 
        if (target < array[middle]){
            end = middle - 1
            continue 
        }
    }
}

Here we begin by checking the value at the middle of the array to see if it is the target. If it is, the function has found the target and should return the index. If not, we see if the value of the middle of the array is less than or greater than the target. Then we change our search parameters (start and end) to inspect the right-side (higher numbers) or left-side (lower number) of array. With each iteration through the while loop, n or the number elements (relevant input) shrinks.

So with each iteration through the recursive algorithm, the number of elements inspected shrinks by a factor of 2. Or as a mathematical function: f(n) = n / (2 ^ i) / f(n) = n / 2ⁱ where i represents the iteration.

Let's represent the iteration with i:

Iteration	Number of relevant elements	`i` function
1	`n`	`i = n / 2`
2	`n / 2`	`i = n / 2²`
3	`n / 4`	`i = n / 2³`
4	`n / 8`	`i = n / 2⁴`
5	`n / 16`	`i = n / 2⁵`

But what is the value of i for a given input n?

`n`	`i`	`n` function	`n` value
1	`i = n / 2¹`	`f(1) = 1/2¹ = 1/2`	`0.5`
2	`i = n / 2²`	`f(2) = 2/2² = 2/4`	`0.25`
3	`i = n / 2³`	`f(3) = 3/2³ = 3/8`	`0.375`
4	`i = n / 2⁴`	`f(4) = 4/2⁴ = 4/16`	`0.25`
5	`i = n / 2⁵`	`f(5) = 5/2⁵ = 5/32`	`0.15625`
6	`i = n / 2⁶`	`f(6) = 6/64 = 3/32`	`0.09375`

That's may seem kinda messy, but given this information we can solve for n using 1 = n/2ⁱ. Multiply both side of the equation by 2, we get 2ⁱ = n or n = 2ⁱ. Recall back to algebra, how do you define a variable in terms of the exponent it was raised to?

Answer: Logarithms

Logarithms and Complexity

A logarithm answers the question "How many of this number do we multiply to get that number?"

the base of the logarithm refers to the number being raised to an exponent
the number in parenthesis specifies the desired value of the base raised to that number

For Example:
|Sentence | Logarithm |
|:--------|:----|
| What exponent does 2 need to be raised to, in order to get the value of 8? | log₂(8) |
| What exponent does 2 need to be raised to, in order to get the value of 256? | log₂(256) |

Using logarithms, we could define the binary search algorithm above as: f(n) = n / 2 * log₂(n)

This introduces the last type of asymptotic complexity, logarithmic complexity. In Logarithmic asymptotic algorithms which the algorithms, as the input n increases, the efficiency of the algorithm increases.

We can summarize these various algorithms with a chart to demonstrate how the algorithm responds to increasing inputs:

All Together

In short, here are the general rules regarding Big O and calculating algorithmic complexity

Algorithms that execute faster with a larger input, will often execute faster will smaller inputs as well.
Many simple algorithms can be analyzed by counting the loops
- An algorithm with a single loop, will generally have a linear complexity.
- Every nested loop will increase the complexity beyond f(n) = n by a factor of n
  - a single loop will have a complexity of f(n) = n
  - a nested loop with will have a complexity of f(n) = n²
  - a nested loop nested inside another nested loop (3 loops) will have a complexity of f(n) = n³
Given an algorithm with a series of loops (not nested loops), the slowest loop (e.g. the loop with the most computational steps) will determine the asymptotic behavior of the algorithm.
- Two nested loops followed by a single loop is asymptotically the same as the nested loops since the nested loops will have a greater impact on execution time as the input grows.
While all the symbols O, o, Ω, ω and Θ are useful at times, O is the one used more commonly, as it's easier to determine than Θ and more practically useful than Ω.
- It is easier to determine O complexity than θ complexity or Ω complexity
- O complexity provides the best insight into performance, since it assumes the worst-case scenario
Logarithmic complexity generally occurs in recursive function, and represents an algorithm that gets more efficient as the input increases.

References

Dionysis Zindros - A Gentle Introduction to Algorithm Complexity Analysis
Big O Cheat Sheet - Know Thy Complexities!

What are microservices, and why should you care?

Jason — Mon, 23 Nov 2020 01:54:23 +0000

What are microservices

As a software engineer or web developer, you've probably heard the term "microservice" before, but for less seasoned developers, the concept of microservices is likely an unfamiliar and seemingly daunting term.

The goal here is to break it down - explain what it is and why you should care.

Monoliths and the "monolithic server"

Before we can understand microservices, it's important to understand the traditional architecture used for building applications, commonly referred to as the "monolithic server".

The traditional full-stack applications is engineered into two primary parts:

The client (front-end)
The server (back-end)

This segments the presentation and of information and the implementation of business logic into the front-end, while the backend supports those features and enables persistence of data.

Monoliths

Meriam-webster defines "monolith" as:

"a single great stone often in the form of an obelisk or column"
"a massive structure"
"an organized whole that acts as a single unified powerful or influential force"

While not specific to software, the analogy is the same.

Typically the monolithic architecture is referencing the back-end (server) that supports data persistence and handles all the logic pertaining to creating, modifying, deleting, and retrieving information related to an application (or applications).

With Monolithic servers, every feature is run on the same system (computer/server) and is part of the same codebase and the same database.

In short → a monolithic application, implements every feature of the application.

Microservice Applications

Microservices are design around the applications features.With each microservice operating independently from each other, but working together to support all the functionality of the application.

In the microservice application architecture, each feature has its own small service called a "microservice" with no dependencies on the other services or features offered as part of the application.

Microservices vs. Monoliths

If each approach was taken to the extreme...

a monolithic server architecture would consist of a single server responsible for all the features, functions and middleware of the application such as:
- routing
- authentication
- business logic
- database interactions
a microservice based architecture would consist of multiple servers. Each server supporting all the functionality associated with a single feature of the application, and each microservice having independent routing, independent code bases, independent business logic, independent authentication, and independent data management.

Implications

The important take-away is that each microservice is self-contained, without any dependence on the other microservices. Using more technical terms, the features assocaited with the application in a monolithic application architecture are tightly coupled together.

This results in an application and development workflow that tightly ties together different developers from different teams, working on different features to a single shared code base, running the same shared middleware, and accessing the same shared database. In short, the application's features are highly dependent upon each other and a single feature breaking could result in the entire application failing.

Microservices seek to address this architectural issue, by making independent servers or services ("microservices") that only are responsible for a single feature of the application.

In a microservice based architecture, routing, authentication, business logic, and database interactions, are all wrapped into small independent pieces ("microservices") and have can operate on their own. With microservices, no feature of the application is dependent on shared code or servers.

This is similar to the idea behind "thin vertical slices" ([here] is an explanation of thin vertical slices if you are not familiar with the approach) commonly embraced in agile methodologies as well as the single responsibility principle.

The problem with the monolithic approach

If a hardware failure occurs in a monolithic architecture, the entire application can be broken, since all of the features, routing, middleware, business logic, and database interactions all occur on the same system.

Similarly, since every feature is running on a single server, that server is using a large code base, that is shared between multiple developer/engineers and teams. As a result each feature is highly dependent on the others, and any addition or modification to the functionality of the application means modifying the code for the entire application.

Drawbacks of Microservices

The microservice approach sounds great so far, but there are some drawbacks.

Communication between services
- most applications require information from one feature in order to implement another feature. Since the microservice makes each feature independent of each other, data is managed independently and is not inherently available to other parts of the application.
Greater resource requirements
- Data management
  - Data Duplication:
    - to avoid being reliant on other microservices, most applications implemented with a microservice architecture duplicate data, with each service having its own copy of the information it needs to operate.
  - Data model associations
    - associating information from one microservice to another is a complex process, since each service has no direct access to the database pertaining to another feature of the application.
- More computing resources:
  - in order to be truly independent from the other microservices, each microservice must run on a server/computer that is only used for that feature.
  - for every feature to work in microservice architecture, multiple servers must all be running at the same time (compared to a single server in the monolithic application architecture)
  - development teams will often duplicate efforts implemented in other microservices, writing code that is very similar (if not the same) to the code implementing similar functionality in a different microservice.
- More complex testing & debugging
  - integration testing involving multiple features, is more complicated under the microservice based approach.
  - logs for each microservice (feature) are on different servers, and could be in completely different formats.

Still unclear?

Hopefully the difference between the fundamental paradigms behind application architecture (microservice vs. monolith) is a little clearer. However, I firmly believe the best approach to understanding anything in software development is to build it.

If that's of interest to you, look out for a follow-up tutorial demonstrating the microservice architecture.

GraphQL vs. REST

Jason — Mon, 16 Nov 2020 02:00:27 +0000

What is GraphQL?

GraphQL is an API standard as an open-source project by Facebook to be an alternative to REST.

Instead of many endpoints that return fixed data-structures, GraphQL only exposes a single API endpoint that responds precisely with the data specified in the HTTP request.

More efficient how?

Only the necessary data is transferred over the network, resulting in minimization of network consumption.

GraphQL exposes a single endpoint that responds to HTTP requests for data (GraphQL requests), and evaluates the query and and replies to HTTP request with only the data specified. No more, no less. Unlike REST APIs, which have several endpoints and respond very structured responses to requests, often returning excess information and/or requiring multiple HTTP requests to piece together objects.

REST vs. GraphQL

There is a blog application that has the following objects and relationships:

user - represents a user model.
- properties:
  - user.id integer (primary key, auto-incrementing)
  - user.firstName string
  - user.lastName string
  - user.password_digest string
  - user.dob date-time
- relationships:
  - has-many followers
follow - represents a subscription to another user's blog posts
- properties:
  - follow.id integer (primary key, auto-incrementing)
  - follow.subscriber integer (foreign key, user who "follows" another user)
  - follow.user integer (foreign key, user that is "followed")
- relationships:
  - has-many users
  - belongs-to users

REST Approach

A REST API for this blog application would have a /users" endpoint and a /follows endpoint with the following routes:

Users REST Endpoint

INDEX - GET /users
SHOW - GET /users/:id

CREATE - POST /users/

body (JSON):

{ user: { firstName , lastName password, dob}}

UPDATE - PATCH /users/:id

body (JSON):

{ user: { firstName , lastName password, dob}}

DELETE - DELETE /users/:id

Follows REST Endpoint

The endpoint /follows/

INDEX - GET /follows
SHOW - GET /follows/:id
CREATE - POST /follows
- body (JSON):
```
{ follow: { subscriber , user}} 
```
UPDATE - PATCH /follows/:id
- body (JSON):
```
{ follow: { subscriber , user}} 
```
DELETE - DELETE /follows/:id

In order to get all the users that follow the user currently logged in (assuming basic setup and no nested routes) the following logic would be executed:

Front-end (client) executes a HTTPGET request to the /follows endpoint (index)
REST API (backend/server) queries the all the follow records in the database, and encodes them as JSON in the body of the HTTP response (status 200 success) returned to the client.
Front-end (client) decodes HTTP request and parses the JSON data from the body creating an array in memory with all the follow objects returned from the GET request.
Front-end (client) executes a reduce function, filtering down the array of follow objects so that it only includes the ones whose user field matches the id field of the authenticated user.
Front-end (client) executes a HTTP GET request to /users endpoint (index)
REST API (backend/server) queries database for all the user records in the database, and encodes them as JSON data in the body of an HTTP response (status 200 success) returned to the client.
Front-end (client) creates an array to store the associated user objects, then loops over the user (foreign key) field filtered from the GET request to the follow /follow adding the user's with the corresponding ids.

GraphQL Approach

Front-end (client) sends GraphQL query to server:

body:

query {
    Follow (user: 23){
        Followers {
            firstName 
            LastName
        }
    }
}

GraphQL API (backend/server) queries the database for all the records of follows the whose user propety is 23, then takes those foreign keys (follow.user) to query the database for all the user records contained in the result of the first query and returns an HTTP response to the client containing an array of objects each with firstName and lastName fields of only the user models with matching follow.user

The difference

REST APIs are built with 5-7 routes for each of the endpoints. Each endpoint represents a collection of records in a database (in a "table" in relational databases), and return either a single record (object) or all of the records (objects). The client (frontend) is then responsible for parsing the responses, filtering the data (if needed) and making additional subsequent requests for more information (if needed), which returns individual records (objects) or all records associated with an endpoint (or "table") in strictly defined data structures which could result in repeating the filtering of data, and making additional/supplemental HTTP requests over and over until all the data is necessary information is gathered.

GraphQL APIs reduce the number of HTTP requests/responses by enabling the developer to "declare" exactly the information needed, and allow the API to join, filter and sort data in a single HTTP request (similar to filtering done in SQL databases using the where operator).

Instead of providing excess records (e.g. REST INDEX) The HTTP response generated from the GraphQL server contains only the records that match the conditions specified in by the client, and each object only has the fields specified, stripping out additional fields and objects, and (in some cases) dramatically reducing the size of the HTTP response.

TLDR;

GraphQL takes a declarative, SQL-like approach to data fetching (APIs), and increases application efficiency and flexibility by enabling client (frontend) request to declare the required information, then querying, filtering, ordering, and joining records/objects (like a SQL statement) and returning only the declared records and fields. No extraneous records, and only the fields declared.

This approach allows GraphQL to reduce both the number/frequency of HTTP request and size of HTTP requests.

Debounce, Performance and React

Jason — Fri, 06 Nov 2020 02:43:39 +0000

Debounce, Performance and React

While "debounce" is a more broad software development pattern, this article will focus on debounce implemented in React.

What is Debounce?

Debounce is a way of delaying some peice of code, until a specified time to avoid unnecessary CPU cycles and increase software performance.

Why does it matter?

Performance.

Debounce allows us to increase application performance by limit the frequency of "expensive operations".

Specifically, operations that require significant resources (CPU, Memory, Disk) to execute. "Expensive operations" or slow application load times, cause freezes and delays in the user-interface, and require more of your network than is ultimately necessary.

Understanding through example

Debounce makes the most sense in context.

Imagine we have a simple movie search application:

import React, { useState } from "react";
import Axios from "axios"; // to simplify HTTP request 
import "./App.css";

/**
 * Root Application Component
 */
export default function App() {
  // store/update search text & api request results in state
  const [search, setSearch] = useState("");
  const [results, setResults] = useState([]);

  /**
   * Event handler for clicking search
   * @param {event} e
   */
  const handleSearch = async (e) => {
    e.preventDefault(); // no refresh
    try {
      const searchResults = await searchAny(search);
      await setResults(searchResults.Search);
    } catch (error) {
      alert(error);
    }
  };

  return (
    <div className="app">
      <header>React Movies</header>
      <main>
        <Search value={search} setValue={setSearch} onSearch={handleSearch} />
        <Movies searchResults={results} />
      </main>
    </div>
  );
}

/**
 * Movie Card component
 * @param {{movie}} props with movie object containing movie data
 */
function MovieCard({ movie }) {
  return (
    <div className="movieCard">
      <h4>{movie.Title}</h4>
      <img alt={movie.Title} src={movie.Poster || "#"} />
    </div>
  );
}

/**
 * Container to hold all the movies
 * @param {searchResults} param0
 */
function Movies({ searchResults }) {
  return (
    <div className="movies">
      {searchResults !== undefined && searchResults !== []
        ? searchResults.map((m) => <MovieCard key={m.imdbID} movie={m} />)
        : null}
    </div>
  );
}


/**
 * Search bar
 * @param {{string, function, function}} props
 */
function Search({ value, setValue, onSearch }) {
  return (
    <div className="search">
      <input
        type="text"
        placeholder="Movie name..."
        value={value}
        onChange={(e) => setValue(e.currentTarget.value)}
      />
      <button onClick={onSearch}>Search</button>
    </div>
  );
}

In the sample React application outlined above, HTTP request (the "expensive operation") containing the search string (title of the movie) to the OMDb API are made when the user clicks the "Search" button. The API responds with a list of movies in JSON.

Note: The example above does NOT implement the Debounce pattern.

Not Debounce

Since the "expensive operation" in the example React application above only executes the HTTP request (i.e. "searches for movies") when the "Search" button within the <Search /> component is clicked - Debouncing would have little or no effect on the application's performance.

But that's not how most people use modern web applications.

We are used to web-apps responding immediately as we enter text with our search results (e.g. google). So what happens if we refactor the code to work in that fashion?

Dynamically Searching

Well the most straight-forward approach would be to listen to the onChange event for the <Search /> component, and re-execute the HTTP request (the search) every-time the text changes.

That means that if you were to search "Terminator", the onChange event would get called for each character in the string. Assuming it was typed with no typos, this would create at least 9 get HTTP requests:

"t"
"te"
"ter"
"term"
"termi"
"termina"
"terminat"
"terminato"
"terminator"

That's 9 or more HTTP requests that may be re-executed so rapidly that the first request has not been responded to - not to mention processed, and rendered - before the next request is made.

Expensive Operations

HTTP request are referred to as "expensive" operations because they involve creating a request, encoding the request, transmitting the request over the web, an API receiving the request, then the process repeats in reverse as the request is processed by the API and returned to the source (our React application).

To make things worse, in our example, each HTTP response must be processed and mapped to components (<Movies /> and <MovieCard />) to display the movie information.

Since each <MovieCard /> component has an image of the movie, each of this card's will then have to create another HTTP request to another resource to retrieve the image.

Alternatively, we could keep execution of the search as it was originally, only initiating the get request, when the <Search /> component's click event is triggered.

Problem solved?

Sure, for this simple example - however what happens when you add filtering:

Every movie returned from the OMDb API has Poster,Title,Type,Year, and imdbID properties. Realistically, we might want to filter the returned results by Year, or Type.

For simplicity, let's just explore filtering by Year.

We can create a <YearFilter /> component that will take in the search results as a prop, and then we can use a .reduce() function to get all the years of the movies being rendered:

  // use `reduce()` to get all the different years
  const years = searchResults.reduce((acc, movie) => {
    if(!acc.includes(movie.Year)) {
      acc = [...acc, movie.Year] 
    }
    return acc 
  },[]);

Next we would need create a select, and map all the different years in <option> elements within that <select>.

// map the different years to
{<select> 
{years.map((year) => {
  return <option>{year}</option>
}}) 
}

Combine these two functions, and we should have a <YearFilter> component that displays the years of the movies returned by the search.

It might look something like:

// imports 
import React from 'react' 

/**
 * Component for filtering the movies 
 * @param {{searchResults}} props 
 */
export const YearFilter = ({ searchResults }) =>  {

  // no filter if 
  if(searchResults && searchResults.length < 1) return null

  // get all the different years
  const years = searchResults.reduce((acc, movie) => {
    if(!acc.includes(movie.Year)) {
      acc = [...acc, movie.Year] 
    }
    return acc 
  },[]);


  // map the different years to
  const options = years.map((year) => {
    return <option>{year}</option>;
  });

  // return JSX 
  return (
    <div className="yearFilter">
      <label>Year</label>
      <select>{options}</select>
    </div>
    )  
}

export default YearFilter

Next we would monitor for the <select>'s onChange event, and filter out all the displayed movies to only those that match the result.

I hope at this point you're getting the idea. To keep this article from turning into a tutorial, I'll pause on the example.

The Problem we are solving is that we have a scenario in which we our React application has an expensive operation that is being re-executed rapidly, so rapidly that operation ("effect") may not even finish its execution before another call to the function "effect" is called.

Introducing Debounce

With Debounce, we tell React to only re-execute the query after a certain amount of time. The simplest way to implement this would be to leverage the native setTimeout() function provided by JavaScript, and wrap the timeout around the "expensive operation".

So let's focus just on the operation we are concerned about: retrieving movie titles. Logically, we may want to wait to make the request until someone has stopped typing, or once all the filters have been selected.

Since the OMDb API's free tier only allows 1,000 request per day, we also may want to limit how many requests are made for that reason as well.

So here I've simplified the expensive operation we want to Debounce inside a useEffect hook:

useEffect(() => {
  // using Axios for simplicity 
  Axios.get(baseUrl, { params: {
    apiKey: 'YOUR-API-KEY', s: searchTitle
  } }).then(response => setResults(response.Search))
}, [searchTitle])

Now let's wrap our effect with a setTimeout() ensuring that the effect will only re-execute after a delay.

useEffect(() => {
  // capture the timeout 
  const timeout = setTimeout(() => {
    Axios.get(baseUrl, { params: {
      apiKey: 'YOUR-API-KEY', 
      s: searchTitle 
      } }).then(response => setResults(response.Search))
  }, 400) // timeout of 250 milliseconds 

  // clear the timeout 
  return () => clearTimeout(timeout)
}, [searchTitle])

The setTimeout() function wrapped around the HTTP request to our API in this example now ensures that no matter how many times the effect is called (i.e. anytime the searchTitle changes), the actual network request cannot be called more frequently than in intervals of 400 milliseconds.

The time is an arbitrary number, adjust as needed

Keeping it "DRY"

In all most real-world React applications, there isn't just a single network request. Well, "copy and paste" is never a good option in software development. If we simply copied the effect above and changed the function wrapped inside, we make the first programming mistake of repeating ourselves, and assume technical debt that could be problematic later.

Rather than "copy and pasting" and modifying to suit unique needs, we can abstract the behavior.

In React, we can abstract this functionality using a custom hook.

// useDebounce.js 
import { useEffect, useCallback } from 'react' 

export const useDebounce(effect, dependencies, delay) => {
  // store the provided effect in a `useCallback` hook to avoid 
  // having the callback function execute on each render 
  const callback = useCallback(effect, dependencies)

  // wrap our callback function in a `setTimeout` function 
  // and clear the tim out when completed 
  useEffect(() => {
    const timeout = setTimeout(callback, delay)
    return () => clearTimeout(timeout)
  }, 
  // re-execute  the effect if the delay or callback changes
  [callback, delay]
  )  
}

export default useDebounce

Now anywhere there's an expensive operation that has potential to be executed often and/rapidly, we simply wrap that function ("effect") within the custom useDebounce hook:

useDebounce(() => {
  // effect 
  Axios.get(baseUrl, { params: {
      apiKey: 'YOUR-API-KEY', 
      s: searchTitle 
      } }).then(response => setResults(response.Search))
}, [searchTitle], 400)  // [dependencies, delay]

And that's Debounce, and how you can abstract the behavior of Debounce to re-use that logic (in a maintainable way) throughout your application.

Conclusion

Implementing debounce in react applications can help avoid unnecessary operations and increase performance. By increasing performance, our React application becomes faster, more responsive to user-input, and provides an improved user-experience.

This pattern can even be abstracted to a custom hook so that the pattern is easy to implement throughout your application, but will be most impactful to "expensive operations" or "effects" that are frequently or rapidly re-executed (and it is not necessary to re-execute).

What do you think? Does Debounce make sense to you? Will you use it?

How JavaScript came to dominate web development

Jason — Mon, 26 Oct 2020 17:54:12 +0000

The story of JavaScript

The web gets accessible

In the 1990s, the first user-friendly, graphical web-browser ("Mosaic) was released by developer Marc Andreessen from the National Center for Supercomputing Applications at the University of Illinois. ("Mosaic) was then replaced with the Mosaic Navigator, which later became the Netscape Navigator.

These "navigators" - which we now refer to as web "browsers" - made the web accessible to every one; not just those who knew how to use a command-line.

Java and the Web

Sun Microsystems, bought by released [Java] in 1995. Java borrowed syntax from C/C++ languages, but had a key a difference: Java was a compiled language that could be run on any operating system as long as the Java Virtual Machine was installed on the system. This embraced the idea of "WORA" or "write once, run anywhere". By re-designing the code base to be run through a virtual machine, Developers could develop a single code base, speeding development and reducing bugs.

Java "applets" were introduced to build on this idea, but in the context of the internet. A Java applet was simply a Java application embedded in an HTML web page. While simple, this enabled Java developers to not only deploy desktop applications, but also web applications using the same robust, high-level programming language they were used to. Now Java applications could be delivered to any operating system over the internet and be run on most computers, as long as the Java virtual machine was installed on the client system.

Undeniably useful; Applets had a critical flaw - Java applets were in-effect isolated from the DOM (Document Object Model). This separation meant that Java applets could not "see" (be aware of) or mutate (modify) the DOM. Java applets, just like all other Java code had to be compiled through a virtual machine before it could be run on the client system, and the Virtual machine couldn't parse the DOM, just the Java applet - in-effect isolating the applet from the web page.

Netscape and JavaScript

To make more dynamic applications that didn't have the limitations imposed by the compilation process and virtual machine required to run Java applets, Netscape contracted Brendan Eich to build a brand-new "scripting" language that would enable developers to add interactivity and functionality to HTML documents, animate HTML content, perform conditional validations, and lay the foundation for a more dynamic and more comprehensive (i.e. "more desktop like") browser experience.

Netscape required Eich create this new "scripting" language with a couple of requirements:

Eich's new language needed to combine great amounts of functionality into minimal and simple code
The language should use a syntax that was familiar and approachable to existing developers by resembling Java

To make the language, do a lot with little work; Eich sought to employ functional programming schemes that made it quick, and simple to write procedures that would could process and/or generate data, as well as respond to input with very few lines of code.

While it can be debated which programming paradigm is "best", Eich sought to combine the the the ability to encapsulate functionality and data within the OOP structure of "objects" and "classes", but remove the rigid structure and more elaborate setup common with traditionally OOP languages like Java.

With a these requirements in mind, Eich created a new programming language called "Mocha". Mocha was an interpreted and weakly typed functional programming language designed specifically for the web. Despite many name changes, Mocha (aka "JavaScript") was the foundation for the ECMAScript or JavaScript we know today. It required no compilation, no virtual machine, and could interact with the DOM natively. This new programming language was the first viable alternative to Java applets for web applications.

Competition & Browser Wars

As Netscape's development continued to gain traction and market share and revenue for web applications became significant, many other players stepped in to try to grab their share of the web application market. In 1996, software giant Microsoft reverse-engineered JavaScript to run its "navigator" or web-browser; Internet Explorer.

Determined to dominate the market, Microsoft not only supported JavaScript in Internet Explorer, but also bundled the browser with it's Windows 95 operating system. End-user's on the Windows Operating System now had a browser pre-installed and ready-to-go when the booted up their computer for the first time. No installation or configuration necessary.

Microsoft's strategy proved to be successful, but Microsoft didn't just want to compete in this new market, Microsoft hoped to dominate it. In an effort to accomplish this goal, Microsoft developed a web-language of its own CSS or "cascading stylesheets". With CSS, developers could make their web pages not only interactive, but also beautiful.

It wasn't long before Internet Explorer became the default browser used by most people. Microsoft's strategy had worked. Netscape responded by launching anti-trust lawsuits against against Microsoft, and even defacing the "e" logo statue outside Microsoft's office. Despite Netscape's effort's agains the software giant, by 1999 - Internet Explorer controlled 99% of the market.

Ending the war

Netscape was fighting a losing battle, and rapidly losing market share. While the company may not survive, their mission to advance web development remained vital to the company's leaders.

In an effort to ensure the web remained open and accessible for everyone, Netscape took their technology open-source, handing over ownership to non-for-profit Mozilla. Under Mozilla, "Mocha" which had became "LiveScript" then JavaScript, was standardized as "ECMAScript" by the ECMA International standards organization in 1997.

Continuing on its' mission to keep the web open and accessible; Mozilla developed and released it's own open-source web-browser - "Firefox". As competitors continued to enter the market introducing their own browsers (Opera, Safari, FireFox, etc.), Internet explorer slowly started to lose its domination of the market. Despite competitors, Internet Explorer continued to be the dominant browser with market share only falling to 50% by 2010.

OOP or Functional?

Starting with a functional approach Mocha/LiveScript/ECMAScript/JavaScript centered around the idea of a executing procedures on a "scheme". This scheme we now call the DOM or Document Object Model. This functional approach made simple applications a breeze to develop, but was fundamentally different from the OOP languages that had been common in application development.

Eich sought to enable OOP design principles in JavaScript through an idea of "prototypes" and "prototypal inheritance". With the addition of prototypes and prototypal inheritance, JavaScript employed principles from both functional and OOP programming programming paradigms.

As with most changes of significance, controversial and largely unpopular at first, because it was different. No programming language before had combined OOP and functional programming paradigms like JavaScript did, and no language had been designed exclusively to be executed in a browser.

Some developers resented the lack of structure with JavaScript, primarily as JavaScript code could be written using OOP principles, or Functional principles. While flexible, this meant that the format and structure of JavaScript applications varied dramatically. Additionally, the weak-type system, varying browser support, and interpreted nature of JavaScript sometimes resulted in web applications that could look different on different browser's and were often buggier then their strongly-typed counterparts.

Despite the controversy, demand and use of web applications continued to rise and JavaScript became the primary programming language for web development. With a large developer base, and open-sourcing, the language was quickly integrated and improved upon with the third version of ECMAScript (which had started as "LiveScript", and had been "Mocha" before that) was released in 1999 further increasing the performance and feature-set offered.

Blurring the desktop and web experience

In 2005 a ES4 (ECMAScript version 4) arrived with a headline feature: AJAX. AJAX or "Asynchronous JavaScript and XML" enabled asynchronous execution of functions/procedures. With asynchronous code execution, web applications could remain responsive to input even while executing expensive (i.e. "demanding") operations.

JavaScript continued to evolve rapidly as projects, libraries, and frameworks made it faster and easier than ever to quickly build web applications. Libraries like jQuery were built on top of JavaScript, and reduced development time with useful helper functions for common operations, while simultaneously abstracting these operations so that the end-result was the same regardless of the client's browser of choice.

In 2009, ES5 (ECMAScript 5) was released, followed by ES6 in 2015. With each version came increased browser support, increased performance, as well as additional features that was easier to execute common functions and more readable/intuitive code. With the release of ES6 (officially published as "ES2015") new syntax and more controlled scoping largely closed the gap in feature-set offered by JavaScript in comparison to traditional languages.

JavaScript today

Allowing development of web applications that utilize OOP or functional programming principles - JavaScript remains the primary avenue for creating web applications. JavaScript remains a flexible, modern, and powerful programming language for a wide variety of applications, and is the most popular programming language used by developers today.

References

Lets talk TypeScript

Jason — Wed, 21 Oct 2020 06:19:11 +0000

Lets talk TypeScript

Ever wonder what the buzz surrounding TypeScript is all about? Keep reading and come on a deep dive on TypeScript addressing the fundamental questions surrounding TypeScript:

What is TypeScript?
What features/benefits does TypeScript offer
What are the fundamentals a JavaScript developer needs to get started with TypeScript?

It is assumed that readers of this post understand basic JavaScript and have some experience creating JavaScript applications.

What is TypeScript

As with anything, a good place to start is with defining "TypeScript".

TypeScript is:

a super-set of JavaScript
open-source
statically typed langauge
strongly typed language

What's the appeal?

More apprehensive developers may ask: "Why would I want to learn TypeScript?" and "How would TypeScript improve code?". To answer this as concisely as possible: TypeScript doesn't offer any functionality that isn't offered by JavaScript, TypeScript simply adds strong-typing on top of JavaScript.

Personally, I began learning programming in the strongly typed langauges like C# and Java. Transitioning to a weakly typed langauge like JavaScript was uncomfortable. JavaScript meant that the rules of strongly-typed programming langauges were no longer true. The idea that I could declare a variable with a value of 23 and later change it to the string "Sally", and that was "ok" seemed like bad behavior, like breaking the rules.

This is where TypeScript comes in; it adds strong typing (and the associated benefits/drawbacks) to the langauge of the web.

Strongly and Weakly typed languages

Weakly typed langauges (like JavaScript) often made me feel like I was doing something bad - "breaking the rules", because when I learned how to write my first piece of code, I was also taught the various data types, and that these types must be declared, or the code will not compile. End of story.

Enter JavaScript - which will infer and coerce variable to the desired type whenever possible. With weakly typed langauges like JavaScript a variable's type is mutable (can be changed). A variable could start out holding a string value, and later hold a number, or an object or a boolean, etc.

Essentially the fundamental rules embedded in someone working with Java and C# were thrown out the window.

With a strongly typed langauge, variable must be declared with a type. This type would define a contract that the variable assigned to the type would be required to follow. This type would be declared when the variable was created and could not be changed (immutable type) once declared.

With strong-typing; variables, functions, and objects have strictly defined rules that could not be broken. Any piece of code that fails to adhere to the rules defined by the type or interface defined would throw an error, and fail to compile.

These contracts mean that the developer writing the code, or building features implementing third-party code (that is strongly-typed) cannot write code that doesn't follow the defined contract. A variable initally defined as a number must always be a number.

It also means that functions in strongly-typed langauges like TypeScript have contracts for both the input (parameters) as well as the output (the return value), and that if the code was attempted to be used in a way that violates the terms of the contract an error is thrown and the code will fail to compile.

Personally, I loved the tooling that strongly-typed langauges offered in modern IDEs:

intelligent code completion of methods/function, variables, fields, classes, interfaces, modules, properties/attributes, and more.
in-line access access to third-party library documentation

Weighing Pros and Cons

While I personally love the structure that comes with strongly typed languages, I would feel remis if I didn't mention the benefits of weakly-typed languages. The main benefit; flexibility.

With weakly typed langauges, a function can return one data-type in one case and a totally different value-type in another case. No overloading, interfaces, or generics required - it just works.

The JavaScript compilier doesn't care about the type of values provided to a function, class or method. Additionally, the type of the return value of the function is also irrelevant to the JavaScript compiler.

In JavaScript, a function that takes two arguments/parameters and adds them together can return different data types, and the code will compile without issue. This could be fine, but it could also result in "bugs" that are difficult to find and de-bug as there is no garuntee to the type or structure of the data going into, or returning from a function.

// function to add 2 variables together 
function add(x, y) {
  return x + y 
}

/* by changing the data-type of parameters provided to the 
 * function, we also can change the data-type returned by the function */
add(2,3) // => 5 (number)
add('2', '3') // => '23' (string)

In the example above, the function add(x,y) takes in two parameters (x and y) and returns x + y. Used as intended this would return the sum of the two numbers provided. However, if we alter those one or both of those variables to have a data-type of string, the function will return a string where the parameters have been concatenated.

There are scenarios where it may be desireable to have different data-types returned by a function, depending on the parameters provided to the function. In this way, we do not need interfaces or generics to implement abstract functionality, we can simply ignore the data-type.

This can make JavaScript code more concise. Avoiding type/generic definitions, interfaces, and casting. It could be argued that weakly-typed langauges like JavaScript enables developers to be more expressive, and more flexible code (polymorphism, mixins, etc.).

However, since the compilier has no defined rules on the data-types of variables, the parameters provided to a function or the return value of a function, the compilier cannot identify unexpected behavior (because we haven't defined what the expected behavior is).

As a result, working in weakly-typed langauges means that unexpected behavior may not appear until an application is published and unexpected inputs are provided that break the functionality of the application.

Thing about it: would you rather be alerted to problems as you develop by a compilier or after deployment, when the application is being used be real customers?

Strongly typed langauges also enable (somewhat) self-documenting code; allowing IDEs to automatically display information about the names, types, and return values of functions/methods/procedures and provide this inline (within the code editor) as the code is typed, and even auto-completing code in some scenarios.

In short, weakly-typed langauges benefit from:

more concise code
more flexible code
more expressive code

While, strongly-typed langauges benefit from:

Implicit documentation
Fewer errors at runtime via strong typing
Increased performance through optimization (sometimes)

A Metaphor

In my head, weakly-typed languages seem to me like a highway that has no speed limit and no rules. There are no rules about the speed at which you travel, the mode of transportation, safety regulations, etc.

If used as intended a highway like this has the potential to function fine, maybe even better in specific situations. As with weakly-typed langauges, we are trading structure and rigid rules for flexibility.

If such a highway (a metaphor for a weakly-typed variable or function) existed, I can easily imagine people driving faster, on both sides and in both directions, failing to signal or use seatbelts, and countless other things that would appual a rule-abiding citizen.

Enter TypeScript

TypeScript was created developed by Microsoft in 2012 and it seeks to add the structure and rules of strongly-typed langauges to "the langauge of the web" (JavaScript) without requiring changing the experience for end-users.

TypeScript Fundamentals

As a superset of JavaScript, all JavaScript is valid TypeScript. In other words; any valid JavaScript code is also valid in TypeScript; however it doesn't recieve the benefits (or drawbacks) of strong typing unless the JavaScript is annotated with types. This is significant for a couple reasons:

Progressive Adoption - Since TypeScript is a superset of JavaScript, strong-typing can be added incrementally, without requiring re-writes of entire applications since the TypeScript is compiled to JavaScript anyway.
Future Proofing & Compatability - Since TypeScript cannot run in its default state and must transpiled into JavaScript in order to be run - developers using TypeScript do not need to be concerned with browser support as TypeScript code can be transpiled into various versions of JavaScript with release dates as far back as 1999 (which the TypeScript compilier does by default).

Installation

TypeScript can be installed via NPM using the command npm install -g typescript which will install the TypeScript compilier globally. Once installed, we can see what version of typescript we have by running tsc --version.

Setup and Configuration

There are numerous options that can configure the way the TypeScript compilier transpilies TypeScript code into JavaScript code. These options can be executed manually at the time of compilation (as command line arguments) or can be picked up automatically with a JSON configuration; tsconfig.json placed in the project's root directory, and will automatically be picked up by the TypeScript compilier.

There are numerous options here, but most are just that: "options", meaning that you do not need to provide them. However, there are some common one's that I'd like to bring to discuss:

"target" - allows configuration of the target version of JavaScript. Defaults to "es3". Can be configured to the latest version of JavaScript by specifying "esnext" instead:

// tsconfig.json 
{
  "compilerOptions": {
    "target": "esnext" 
  }
}

"watch" - allows automatic re-compiliing of TypeScript to JavaScript as changes are saved to a TypeScript file, removing the need to run the tsc command to recompile TypeScript code to JavaScript. Disabled by default.

// tsconfig.json 
{
  "compilerOptions": {
    "target": "esnext", 
    "watch": true
  }
}

"lib" - enables included type declarations for common technologies/features found in modern web applications like the DOM without any compiliation errors along with access to integrated documentation within most IDE's.

// specify native support for common DOM elements that exist as 
// global variables & classes like `document`, `window`, `URL`, etc. in modern version of JavaScript 
{
  "compilerOptions": {
    "target": "esnext", 
    "watch": true, 
    "lib": ["dom", "es2017"]
  }
}

Whether run manually, or automatically using the "watch" function configured in a tsconfig file: TypeScript code placed in .ts files, will be converted into its configured version JavaScript code (ES3 by default) with the same file names, but with the .js extension.

Declaring variable types

In TypeScript, we define and assign types to variables. Once assigned the type cannot be changed.

Implicit vs. Explicit Type Declarations

Type declarations can be declared/implented in two ways; explicitly or implicitly.

To implicitly declare a the data type of a variable, we can define the value of the variable at the time of declaration, which allows the compilier to infer the data type of the variable and enforce its type.

/* implicit declaration */ 
let age = 23

/* attempting to assign a string to a variable implicitly declared 
 * as a number is not allowed and will create a compile-time error */ 
age = "twenty-three" // [ts] Type "twenty-three" is not assignable to type 'number'

Note: In JavaScript, this would be allowed and could create a bug that likely would be difficult to find - but due to the strong typing of TypeScript - the code will fail to compile. Since TypeScript is a superset of JavaScript, we can "opt out" of the strong typing inherent to TypeScript by declaring the type of any which will indicate to the compilier that it should not validate changes to the value of that variable.

If we don't have a value to assign to the variable at declaration, we can explicitely declare the variable type by annotating the variable declaration with its type. Without a type annotation TypeScript variables will be declared as any meaning that they are not type-checked.

/* No Type Anotation */
let age; // will be inferred as `any` data type and will not be type-checked by the compiler 
age = 23 // => valid 
age = 'suzie' // => valid 

/* Explicity Type declaration */
let lucky:boolean; // indicates that only booleans (true/false) values can be assigned to the `lucky` variable 
lucky = 'suzie' // => type error 
lucky = true //=> valid

Best Practice: If you have a value to assign at the time of the variable declaration, do not explicitly declare its type as it would be redundant.

Moving beyond "primitive" data-types

In JavaScript (and TypeScript) there are six (6) primitive data types:

undefined
boolean
number
string
bigint
symbol

More complex pieces of information are representing with what is referred to as "Structural Types". This includes; arrays, maps, sets, dates, and any other "object" where it is necessary to encapsulate more than one primitive data-type, or that need to structure data in a specific manner.

Custom Types

With TypeScript, custom "types" can be declared using the keyword: type followed by the name of the type (in Pascal case) and setting it equal to (=) the type definition. This sets up a contract that can define the format of a variable, the format of parameters to a function as well as the format of a function's return value.

Once declared, a custom type is implemented exactly like a primitive type.

/* declare custom type of "Font" which will be required to always be a string value */
type Font = string 

/* declare variable to have a type of "Font" */
let myFont:Font 

// valid 
myFont = "bold" 
myFont = "Italic"

// invalid 
myFont = 400

Union Types

TypeScript goes beyond primitive and custom types by providing "union types". With union types, not only is the structure and type of data enforced, but the actual value is limited to the value(s) outlined within the union type declaration.

/* be defining the `Style` type as a union type, 
 * the TypeScript compilier will ensure that any 
 * variables assigned as that union type will only 
 * have values matching the prescribed values */
type Style = 'italic' | 'bold' | 'regular' 

// Explicitely declare strong type
let font:Style; 

// valid 
font = 'italic' 

//invalid 
font = 'helvetica'

Interfaces

Another to define the structure in TypeScript is through interfaces. Interfaces specify the shape of an object or class without strictly requiring the value be of a specific type. In this way, TypeScript provides abstraction and flexibility.

As long as a variable, parameter or return value aheres to the rules established in the interface definition - the variable, parameter and/or return value can be of any type.

/* declare a custom `type` of person, which is represented 
 * as an object with a 'first' property which is a string, 
 * and a `last` property that is also a string */
type Person = {
  first: string 
  last: string 
}

/* explicitely define variable type */
let winner: Person; 

// valid 
winner = { first: "Usain", last: "Bolt" }

// invalid 
winner = "Usain Bolt" 
winner = { first: "Usain", last: "Bolt", country: "Jamaica" }

In this case, a variable implementing the interface Person ensures that the variable winner must be an object with a property for first that is has a type string and property named last which is also of type string.

All variables implementing the Person interface must adhere to these rules. They cannot have any additional properties (like country), would throw an error and that assining any assignment to the variable winner cannot deviate from the rules defined by the interface. Any violation of those rules would throw an error.

Making more flexible interfaces

In some situations, the rigid definition of types and interfaces can restrict functionality. One such scenario is in the event where there is a collection of items that all have first and last properties that are both strings, but could have additional properties beyond that as long as the first and last properties exist.

This restriction can be circumvented wiht a little creativity by adding a little bit to the the type definition:

So if the goal was to have enable the scenario where we have a collection of objects that have first and last properties that are strings, we can specify that an additional property named as a string will have an associated type of any, enabling greater flexibility through polymorphism.

This is just like a dictionary

/* adding an addtional key value pair to be stored with any name and any value */
type Person = {
  first: string 
  last: string 
  [key: string]: any 
}

/* explicitely define variable type */
let winner: Person; 

// valid 
winner = { first: "Usain", last: "Bolt" }
winner = { first: "Usain", last: "Bolt", country: "Jamaica" }
winner = { first: "Usain", last: "Bolt", fast: true }

// invalid 
winner = "Usain Bolt"

Types and Functions

In addition to defining types and interfaces for variables, TypeScript enables (and encourages) defining data-types in the function definition such that the parameters of a specific function adhere to the types declared, and return a value that adheres to the type specified as the return type.

Strongly typing parameters of functions and their return values uses the same syntax as type/interface declarations (exluding the const/let used with variable declarations). First we define a name for each parameter, for each named parameter, the type is defined using a colon (:) followed by the type (e.g. x:number). The return value of the function is defined following the closing parenthesis ()) of the function's parameter list and before the opening curly-brace ({) of the function's body:

/* function to raise x to a power of y WITHOUT type declarations */
function pow(x, y) {
  return Math.pow(x,y) 
}

/* The same function to raise x to a power of y WITH type declarations */
function pow(x:number, y:number):number {
  return Math.pow(x, y) 
}

Function that do not return a anything, (like event listeners, side-effects, etc.) should be defined as having a return type of void:

/* Example of a functiont that does not return any value */
function handleClick(event:React.MouseEvent):void {
  // ... execute event handler 
}

By adding strong typing to parameters and return values of functions, the TypeScript compilier can:

validate parameters to functions are of the correct type
validate the return value of a function

Working with arrays

Arrays defined in .ts (TypeScript) files that are not strongly-typed function the same as arrays in .js (JavaScript) files. Elements within arrays without strong-typing will accept elements of any data-type, which could result in each element adhering to the same rules (i.e. be of the same type), or being of varying types.

/* declaring an array without a type will essentially "opt out" of 
 * the safe-gaurds provided by TypeScript */ 
const arr = [] 

/* So we can add elements to the array of any type */
arr.push(1) 
arr.push('Susan')
arr.push(false)

By declaring adding typing to arrays, the compiler will throw an error anytime an element failing to adhere to the type/interface outlined in the array's type definition will throw an error.

Typing is added to arrays similarly to adding typing to variables and function definitions. First declare the type of variable (const/let), followed by the name of the array, followed by a colon (:) and the type (e.g. :number) or interface (e.g. Person), then with opening and closing brackets ([]) to indicate that it is an array of that type.

/* strongly typed array of numbers */
const arr: number[] = []`

This can be useful when working with complex or irregular objects as well as increasing performance through optimization (in some cases).

/* declare an interface */
interface Person = {
  first: string 
  last: string 
  age: number
}

/* every element within the array must adhere to 
 * the rules defined in the interface or type annotated, 
 * in this case: the person interface */
const people:Person[]; 

people.push({ first: 'Barack', last: 'Obama', age: 59}) // valid 
people.push({ first: 'Steve', last: 'Jobs' }) // throws an error

Tuples

TypeScript builds on this strong typing of arrays by enabling definition of a "tuple", which (in TypeScript) is a strongly typed, fixed length array.

/* declare a tuple that has 3 elements, 
 * the first being a number, 
 * the second being a string
 * and the thirds being a boolean */
type Contestant = [number, string, boolean ]

To create a tuple of this type we annotate the variable with the type :Contestant:

/* Custom Type */
type Contestant = [number, string, boolean ]

/* Create Tuple from Type */
const competitors: Contestant = [24, 'Tony Robbins', false]

Note: with the type definition above, we cannot initialize a variable of type Contestant to an empty array ([]), rather it must be declared with elements matching the types/interfaces declared by the tuple's type

Generics

In order to implement functionality where behavior has been abstracted so that the logic implemented can be repeated with different varaible types, TypeScript offers "generics".

This abstraction of behavior with generics is pervasive in Framework's like Angular. Generics are also common in a variety of Software Engineering design principles and patterns like the "observer" pattern. In the observer pattern, a one-to-many relationship is defined between an object and all it's "obsevers" (other objects), such that when the state of the "subject"
being observed changes, all the observers of the subject are automatically updated.

Generic Syntax

To declare a generic in TypeScript we using angle brackets (<>) enclosed with an alias (often "T": <T>) representing an abstraction of the object that is being added the "generic" logic or functionality defined by in the generic type definition.

In TypeScript this might look something like:

/* declare generic type of "Observable" 
 * with the variable `T` representing 
 * any object that where "Observable" 
 * functionality is needed */
class Observable<T> {
  /* define that any observable will have a public property 
   * named `value` */
  constructor(public value: T) {}
}

/* explicitly declare an observable number */
let importantNumber: Observable<number>; 

/* explicitly declare an observable person */
type Person = { first: string, last: string }
let importantPerson: Observable<Person>;  

/* implicitly declare an observable number */
let secondPassed = new Observable(23)

With generics, logic and functionality can be created without knowing the type of data (primitive or structured) that will implement the abstracted ("generic") logic.

And that's the basics

Hopefully by this point you've got a basic idea of what TypeScript is, what benefits and drawbacks TypeScript offers when compared to JavaScript and the basics of defining, implementing and using strongly typed variables, interfaces, arrays, and the abstraction of typing using Generics.

Getting Started with Vue.js

Jason — Fri, 21 Aug 2020 22:49:11 +0000

Getting Started with View

View is a declarative and progresive web framework that is designed from the ground-up to be incrementally adoptable by focusing solely on the view layer.

The Basics

To create a Vue instance connecting the Vue JavaScript framework with the HTML document, you must either have the Vue framework installed and referenced in your project, or link to a CDN.

<!-- index.html -->
<html>
    <head>
        <link rel="stylesheeet" href="index.css">
        <!-- Import the view framework via CDN -->
        <script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>
    </head>
    <body>
        <!-- we will use this ID to set the root element for Vue.js -->
        <div id="app">
        <!-- We use double curly brace syntax to reference information contained in the 'data' element of the Vue , this is called a "template literal" -->
            {{ message }}
        </div>

        <!-- Link to associated View/Vue -->
        <script src="index.js"></script>
    </body>
</html>

// index.js 
var app = new Vue({ 
        el: '#app', /* the sets up the connection to the root element of the application */
        data: {
            message: 'Hello Vue!', /* an property defined in the `root` of data will be immediately accessible between double {{}}curly braces in a HTML document */ 
        }
    }
)

Now any change this data object within the associated Vue changes, the associated data in the HTML template will also be re-rendered.

If you don't believe me, open up the JavaScript console and change the value of app.message and take a look at the HTML page in your browser? (it should be displaying the new value)

Now that Vue is connected to our HTML, we no longer need to interact with it directly, but rather through our instance of Vue({...}) which is connected directly to our <div id="app">

Directives

Directives in Vue are HTML elements that are prefixed with v- which indicates that they will have special properties provided by Vue. So if we have something like v-bind, we are telling view that we are about to "bind" some piece of data as an attribute to an HTML element, effectively; we can bind JavaScript code to attributes of an HTML elements to add functionality.

<div id="app">
    <span v-bind:title="message">
        Hover your mouse over this text for a few seconds to see when you loaded the page. 
    </span>
</div>

<script>
var app = new Vue({
    el: '#app', 
    data: {
        message: `This page was loaded at ${new Date().toLocaleString()}` 
    }
})
</script>

This would be effectively equivilant to:

<div id="app">
    <span title="This page was loaded at CURRENT DATE/TIME">
        Hover your mouse over this text for a few seconds to see when you loaded the page. 
    </span>
</div>

... except that native HTML doesn't allow us to dynamically generate text so we would have to do something like this:

    <div id="app">
        <span>
            Hover your mouse over this text for a few seconds to see when you loaded the page. 
        </span>
    </div>
    <script>
        const span = document.querySelector('#app > span')
        span.setAttribute('title', `This page was loaded at ${new Date().toLocaleString()}`)
    </script>

Redering Collections

As is common in programming, we often need to iterate ("loop") through data sets and display information from the objects being iterated ("looped") through, view does this by attaching a "for" (v-for) to the element to be rendered for each object being iterated over.

So if we had a collection of todo's, we could display each of them using the v-for directive, which will take a string argument that includes an alias which will represent each object as it is iterated through, and the name of the collection within the data set containing the objects to loop through.

That sounds complicated, but in practice it looks something like this:

    <!-- 
        Target Root Element 
    -->
    <div id="app"> 
        <ul>
            <!--    
                Element to display each iterated object
                along with an alias ("todo") of what each item will be called from the speciefied collection ("todos")
            -->
            <li v-for="todos in todos">
                {{ todo.text }}
            </li>
        </ul>
    <div>
    <script>
        var app = new Vue({
            el: '#app', 
            data: {
                todos: [
                    { text: 'Learn Java' }
                    { text: 'Learn Kotlin' }
                    { text: 'Deploy android application to the google store' }
                ]
            }
        })
    </script>

Or if we wanted to expand on that check list we could add additional properties and loop through them like so:

<div id="app">
    <span>Leveling up the todo list</span>
    <ul>
        <span v-for="todo in todos">
            <li>{{todo.text}}<input type="checkbox" v-bind:checked="todo.checked" aria-label="todo.text"/> </li>
        </span>
    </ul>
</div>
<script>
var app = new Vue({
    el: '#app', 
    data: {
        todos: [
            { text: 'Learn Java', checked: true }
            { text: 'Learn Kotlin', checked: false, }
            { text: 'Deploy android application to the google store', checked: true }
        ]
    }
})
</script>

Conditional Rendering

Well that's all fine and dandy, that's very little of what the Vue.js framework enables; one of the more common functionalities of any JavaScript framework (React, Vue, Angular) has to do with reactively displaying different pieces of information depending on various conditions.

To enact conditions we use the "if" v-if directive, and supply that directive with the name of the property we want to perform the "if" evaluation upon.

That could look something like:

<div id="app">
    <!-- 
        `v-if` is checking the 
        "seen" property of `data` within the `Vue` 
        It should evaluate to true or false 
    -->
  <span v-if="seen">Now you see me</span>
  <span v-if="unseen">Now you don't</span>

</div>
<script>
var app3 = new Vue({
  el: '#app',
  data: {
    seen: true,  /* element should render */
    unseen: false,  /* element should not render */
  }
})
</script>

Events

In order to handle events with view, we utilize the "on" (v-on) directive, which attaches event listeners to HTML elements.

<div id="app">
  <p>{{ message }}</p>
  <!-- 
      Attaching a click event listener to a method called 'reverseMessage'
    -->
  <button v-on:click="reverseMessage">Reverse Message</button>
</div>
<script>
var app5 = new Vue({
  el: '#app-5',
  data: {
    message: 'Hello Vue.js!'
  },
  methods: {
    reverseMessage: function () {
      this.message = this.message.split('').reverse().join('')
    }
  }
})
</script>

Using v-on we can attach any event listeners that we would use outside of a framework simply by specifying what event after the colon (v-on:click)

Alright so, that's the basics to get you started. There is so much more to be discovered. Look out for follow-up post soon!

Acknowlegements

Inspired by Vue JS Guide

An Intro into React Hooks with `useState`

Jason — Wed, 15 Jul 2020 19:50:21 +0000

An Intro into React Hooks with `useState`

First, lets get a baseline.

React hooks allow developers to encapsulate abstract logic that can be re-used in some, a few or many components within a react application. Since state is one of the most cumbersome items to manage within a react application; most react hooks help manage state. In fact, one of the most-used react hooks is called useState and (unsurprisingly) it abstracts the code surrounding using state, allowing the developer to focus more on application functionality and less on the technicalities surrounding creating, modifying, and retrieving state.

Old vs. New

To better understand this, let's take a look at a traditional component built without hooks.

import React from 'react' 
// a Counter component that allows an end-user to increment or decrement a counter 
class Counter extends React.component {
  constructor(props) {
    super(props)
    this.state = { count: 0 }
  }

  // increment the value of the counter, defaulting to increase of 1
  increment(amount = 1){
    this.setState(prevState => {
      return { count: prevState.count + amount }
    })
  }

  // decrement the value of the counter, defaulting to a decrement of 1
  decrement(amount = 1){
    this.setState(prevState => {
      return { count: prevState.count - amount }
    })
  }

  // reset the counter to the initial state 
  reset() {
    this.setState({ count: 0 })
  }

  render() {
    return (
      <div>
        <span>{this.state.count}</span>
        <button onClick={ e => increment() }>+</button>
        <button onClick={ e => decrement() }>-</button>
        <button onClick={ e => reset() }>Reset</button>
      </div>
    )
  }
}

The code above demonstrates a traditional react component built with class-based inheritance. With hooks, we can transition this code to a more functional approach, with less "boiler-plate" code.

import React, { useState } from 'react' 

function Counter (props) {
  const [value, setValue] = useState(0)

  function increment(amount = 1){
    setValue(value + amount)
  }

  function decrement(amount = 1){
    setValue(value - amount)
  }

  function reset(){
    setValue(0)
  }

  return (
      <div>
        <span>{this.state.count}</span>
        <button onClick={ e => increment() }>+</button>
        <button onClick={ e => decrement() }>-</button>
        <button onClick={ e => reset() }>Reset</button>
      </div>
    )
}

Getting started

The first thing that changes, is that inherently, functions are stateless. In order to circumvent this limitation hooks offload that task to a seperate function: useState.

So first we must import useState from the React library:

import React { useState } from 'react'

Now instead of setting the initial state in the constructor of the component (functional components do not have constructors), we set state in the constructor of the useState hook: useState(initialValue).

// old 
class Counter extends React.component {
  constructor(props) {
    super(props)
    this.state = { count: 0 } // providing initial value 
  }
}
// new 
import { useState } from 'react'
function Counter(props){
  const [count, setCount] = useState(0) // providing initial value
}

Unlike class-based state, state using hooks can be of any data type (recall that class-based components are hashes).

Mutating State

The useState hook returns two variables to the caller:

a variable that can be used to access the current state.
a function that can be used to mutate state.

It is up to the developer to name the returned values accordingly, but by convention it is common to name the returned values as 'value' and 'setValue' as [value, setValue] or in the case of our Counter component: [count, setCount].

When we want to change state, we have a couple options:

We can directly modify the state, in which we use the setValue function returned by useState to mutate the value.
We can provide a function that mutates the state, in which the function recieves (as an argument) the previous state and the output of that function is the new state.

This would be contrasted with the component based approach, where we must use a function that recieves the previous state as the argument and returns the new state:

// Component based approach 
increment(amount = 1){
  this.setState(prevState => {
    return { count: prevState.count + amount }
  })
}

So with hooks, we could do the same thing:

// functional approach mirroring the component based approach 
function increment(amount = 1){
  setCount(previousCount => { 
    return previousCount + 1
  })
} 
// or (shorthand)
function increment(amount = 1){
  setCount(previousCount => previousCount + 1)
}

But with functional components we could simplify this even more:

function increment(amount = 1){
  setCount(count + 1)
}

Since we already have the current count in memory, all we have to do is access that and implement the same logic, since whatever is placed in the setCount function will be the new value for state.

The Gotchas

With class-based state, we typically store data in a hash, we then copy and modify the state in order to mutate it. While we could do this with the useState hook, it is not recomended. Instead, it is more efficient (and likely more readable) to place each piece of state in seperate state variables:

//incorrect: 
const [state, setState] = useState({ count: 0, color: 'blue'})

// correct 
const [count, setCount] = useState(0)
const [color, setColor] = useState('blue')

Why?

This would be best answered by reviewing an example; imaginge we had a component that needed to manage states including count and color... To change the color of the component with class-based components we would:

function changeColor(newColor){
  this.setState(previousState => {
    // copy previous state and overwrite color attribute 
    return {...previousState, color: newColor }
  })
}

In functional components, leveraging the useState hook, it would look like:

function changeColor(newColor) {
  setColor(newColor)
}

So why would we use hooks instead of classes?

When you update state, it is more clear what is changing
The syntax is more readable and concise
It is more effecient ( we are not repeatably copying and overwritting data)

Summary

Woah, I know that could be a lot to grasp at once, so here are the key take aways:

React hooks abstract functionality that would typically require a class-based component into a function that can be used in any component within a React application.
The useState hook allows us to more simply manage state than the traditional class-based approach.
If there are multiple pieces of state to be modified, those should be seperated into seperate pieces of state with their own accessor and setter.

The JavaScript Stack Explained

Jason — Thu, 21 May 2020 22:20:45 +0000

JavaScript code is executed through leveraging two key data structures:

the stack
the heap

The goal in this blog post is to explain and clarify what the JavaScript call stack is.

The Stack

A stack is an ordered data structure that keeps track of functions invocations. It is important to note, the JavaScript call stack is part of the JavaScript runtime, you do not directly modify the stack.

Whenever you invoke a function (in JavaScript) the details of the invocation of that function is saved ("pushed") to the top of the stack. When the function returns a value, the information regarding the invocation is removed ("popped") from the top of the stack.

A Simple Stack Example

function multiply(x, y){    // line 1 
    return x * y;           // line 2
}                           // line 3 
let result = multiply(3,5); // line 4

So in practice; when a script is executed by the browser, the JavaScript runtime first loads the main function to the top of the stack; in the example above this would be line 5 (let result = multiply(3,5);), where the stack records the name of the function and the location (i.e. line-number) at which the function was invoked.

At this point the stack would have 1 invocation:

4 function: main

As the JavaScript runtime parses the first function call from the top of the JavaScript file (the multiply function), it then loads ("pushes") the multiply function to the stack.

At this points the stack would have 2 invocations:

4 function: main
2 funtion: multiply

This indicates that the call stack, with the first function of main is waiting on the function of multiply to resolve, before it can continue. Once the result of multiply(3,5) has been evaluated, multiply is removed ("popped") from the call stack.

Since there is nothing else in the file, the execution of the main function is considered complete; which means the call stack will now remove the main function from the stack, resulting in an empty stack/call stack.

Stack Frame

The "Stack Frame" refers to a single element in the JavaScript runtime call stack. Each "Stack Frame" contains the following information:

the function that was invoked.
the parameters that were passed to the function
the line-number from which execution of the function started.

So, piecing that information together, we can understand that the JavaScript call stack is:

An ordered set of stack frames
the most recently invoked function would be at the top of the stack
the bottom of the stack is the first function invoked
the stack is always processed from top to bottom.

Why should you care?

Understanding how the call stack works is fundamental to writing web applications. Not only is it helpful to understand how the JavaScript runtime executes the logic in your application, but if you have ever seen a JavaScript error (or an error in pretty much any language), you've seen a text representation of the call stack (typically called a "stacktrace"), which tells you where your code threw an error, and what events lead up to that errors occurrence.

An Introduction to JavaScript Classes & Methods

Jason — Thu, 21 May 2020 17:01:37 +0000

JavaScript Classes

In programming, classes are used a "blue print" for modeling real-world items in code.

In JavaScript, the syntax for creating a class could be as simple as:

class Square {
    constructor(sideLength){
        this.sideLength = sideLength; 
    }
    area(){
        return this.sideLength * this.sideLength; 
    }
}

Breaking this down:

First we declared a class called Square to represent the idea of a square.
Then we declared that in order to create a square, we need to know the length of one side of the square. We specified this by defining a constructor method, which is a special method that "builds" our class when we instantiate it.
In the constructor we took the provided sideLength and saved it to an instance variable called: sideLength
a. Variables specified with the keyword this indicate instance variables
We also specified a method called area which takes no parameters/arguments, as denoted by the empty parenthesis area(). In this method, we specified that the area of the Square is equal to this.sideLength * this.sideLength

Instantiating

Once the blue print (class) has been defined, we create "instances" or specific occurences of that class. In order to instantiate the class we defined above we would use the following syntax:

let square = new Square(5);

This says, store an instance of a square, with a sideLength equal to 5 in a variable we named square. Now that we have an instance we can use the instance method associated with the Square class:

square.area(); // => 25

Methods Types

Standard Methods

Recall the Square class example...

class Square {
    constructor(sideLength){
        this.sideLength = sideLength; 
    }
    area(){
        return this.sideLength * this.sideLength; 
    }
}

... area() is a standard class method. Standard methods in JavaScript are available to any instance of the class they to which they are defined.

Static Methods

Static methods are class-level methods. In other words, they cannot be called on an instance of a class, but rather they are called on the class itself. Typically, static methods are generic utility methods that have functionality relating to the class, but not an instance of a class.

To illustrate this, we will use a different example:

class MyMath {
    static square(number){
        return number * number; 
    }
    static cube(number){
        return number * number * number; 
    }
}

In the example above, we are defining what it means to square a number, and what it means to cube a number. It is important to note, that with static methods, we have no dependence on an instance - or in more technical terms; static methods are stateless.

To use a static method, we must call upon the method at the class level, not the instance level:

let squaredNumber = MyMath.square(5);  // => 25 
let cubedNumber = MyMath.cube(3) // => 9

Getters and Setters

In most object-oriented programming (OOP) languages, objects/classes have "getter" and "setter" methods that provide access to instance variables. In most native OOP languages, you have "private variables" that are only accessible within the class themselves. This is designed to protect the state of that object by controlling when and how instance variables are set ("setters") and retrieved ("getters").

JavaScript is a functional programming language at its core, which means that it is designed to be written in a procedural style. This is in comparison to OOP languages which model "state" (variables) and "behavior" (methods) within objects after real life. Diving into procedural vs. OOP is out of scope for this topic, but a fundamental programming idea that every modern developer should have a firm grasp around.

class Dog {
    constructor(name){
        this.name = name; 
        this._activityLevel = 1; 
    }
    // setter method 
    set activityLevel(level){
        if (level > 10) level = 10 
        if (level < 1) level = 1 
        this._activityLevel = level; 
    }
    // getter method 
    get run(){
        return `${name} runs ${this._activityLevel * 1.2} miles per day`  
    }
}

Inherently, "getter" methods (in JavaScript) provide the ability to access an objects internal state, without invoking the method:

let skipTheDog = new Dog("Skip");   // => null 
skipTheDog.activityLevel(5);        // => null 
skipTheDog.run;                     // => `Skip runs 6 miles per day`

Notice with the setter (skipTheDog.activityLevel(5);), we pass in the value we want to use to modify the internal state of the object. Conversely, with getter we do not need to use parenthesis (()) or "invoke" the method as it is defined as a "getter" method in the class definition. In other words; "getter" methods operate a lot like the properties of an object, except that they do not allow you to change the objects internal state:

let skipTheDog = new Dog("Skip");                // => null 
skipTheDog.activityLevel(5);                     // => null 
skipTheDog.run = `Skip runs six miles per day`   // => ERROR

Per the example above, we can not use "getter" methods to set internal state, so this would throw an error.

Glossary of Terms

Class - a blue-print that defines a type of object.
Constructor - a special method that defines the required parameters to instantiate that class.
Instance - A specific occurance of an instantiated class.
Instantiation - The process of creating an "instance" of a class
Invoke - to call execution of a method, function, subroutine or procedure
Method - a procedure associated with a class that defines behavior of an object
Parameter - an arguement for a method

Key Concepts to get Started with Rails APIs

Jason — Tue, 21 Apr 2020 15:52:55 +0000

What is an API?

Well first, an API is an “Application Programming Interface”, and it is a way for one application to “talk” to another. Of course, you have to speak the same language ( .json , .csv , .txt ). And it is through API’s that most web applications are built. So if you want to do full-stack engineering, you need to know API’s.

My goal here is to share the concepts that I believe are key to understanding API’s in Ruby. I am sure that there are many tutorials that will show you exactly how to do it, so I will not re-hash that here; here my goal is to help you understand how an API works conceptually.

The trick to forgetting the big picture is to look at everything close-up. - Chuck Palahniuk

Programming Paradigms
Model View Controller
Web Concepts
HTTP Requests
Routing
Rendering
Static
Dynamic

Model View Controller

Starting if with a definition; Model-View-Controller or MVC is an architectural software engineering design pattern in which we decouple different functions of an application or in programmer talk - separate our concerns. In this case; we are separating the concerns of modeling data into three broad categories;

1.Model - as a verb it would be “modeling”, this functional group is responsible for “modeling” or data. These are the objects that hold and organize our data.

Controller - as the name implies, this functional layer serves as a sort of router, designated the responsibility of communicating with the models to work with the application data.
View - the view assumes responsibility of displaying content to a user by interpreting the information received from the controller.

It is key to understand the distinctions here; a view is only responsible for display functions, a model is responsible for representing our data, and a controller contains the logic for interaction between the two other layers.

HTTP and the Internet

HTTP stands for Hyper-text transport protocol (a web communication protocol) and is the standard along with HTTPS or Hyper-text transport protocol secure. In programming lingo; think of HTTP as an object that has methods and functions that allow us to send messages and read messages over the internet.

Like most things in the world of systems, there are pieces to an HTTP command; a header, a body, and a footer. The header will have things like who sent the request, what type of request it is (more on that later), the path of the resource they wish to issue the command to, and more, but those are they key things. Next there’s the body, which will have the “payload” of the command, and lastly there is a footer that denotes that that is the end of the HTTP command.

Starting with the types of HTTP; there are a few core types that mirror CRUD (create, read, update and delete) functions.

In HTTP lingo;
• "create" would correspond to a PUT HTTP command.

• "read" would correspond to a GET HTTP command.
• "update" would correspond to a PATCH HTTP command.
• "delete" would correspond to the DELETE HTTP command.

There are additional (less common) types of HTTP commands like;
• TRACE , which will echo back the last received request
• OPTIONS , which will return the HTTP methods supported by the server
• CONNECT , which will convert the command to a TCP/IP tunnel (generally for SSL)
• HEAD , which asks for a response (like a GET but without the body)

These allow servers to send and retrieve information and are the key building blocks of API’s.

Routing

The next fundamental concepts of Ruby API’s is the concept of routing. Personally, I like to think of Routing just like a network router that most of us have in our home. It takes a HTTP command (or request) and directs it to the appropriate resource. However, unlike network switches/routers, Ruby routes, referring to directing traffic from an endpoint which is how most websites work.

When you go to http://www.cnn.com/, your browser is sending a GET request to that DNS (Domain Naming Service) resolves that to an IP address, which your browser then sends an HTTP GET command. In this case, no authentication is required, and the website responds with and HTTP response (request --> response) whose body (think "payload") carries the HTML from the requested page.

In the example of cnn.com, routing was implied: since nothing followed the .com, we simply wanted the index page. When you want to go to a more specific resource at that IP address like https://www.cnn.com/us... the traffic will be directed by DNS to the same server, however that server will respond different as the GET command has refined the information it is requesting . This is the fundamental concept of routing. It involves interpreting an HTTP request and directing it to a controller which can process that request.

Rendering

Let’s start with a definition; [technopedia’s(https://www.techopedia.com/definition/9163/rendering) definition was the first one I found that I felt concisely describes rendering in the context of the web:

Rendering is the process involved in the generation of a two-dimensional or three-dimensional image from a model by means of application programs

Here, what I am referring to by "rendering" is the act of interpreting web code (most commonly in the form of HTML, CSS and JavaScript) and generating or retrieving the requested information.

In the case of web applications, it can be as simple as delivering an HTML page. This is typically referred to as static rendering. Well this works fine for “about us” pages, more elaborate sites will display different depending on a variety of factors, this we call dynamic rendering.

Putting it all together

So now that we understand how the internet works (HTTP commands, requests and responses) and how those requests are routed and rendered. Let’s put all those pieces together and talk about how it fits into the MVC software design pattern and more specifically Ruby (on Rails).

At a high level, an HTTP GET command is sent to a web resource, requesting to read data. That resources processes HTTP command/request and routes it to the appropriate resource. Assuming the requestor has adequate permissions, the resource will then pull up (think “read”) the requested information with an HTTP response and the body of the HTTP response will have the payload or information requested by the user.

Now let’s put that in context of MVC and Ruby on Rails with an example:

A resources makes a HTTP GET command to a resource we will call myapp.com . That resources receives the requests and routes the traffic based upon the directions supplied in the routing file (routes.rb).

The routes file describes what to do depending on the request. Here we are requesting (GET) a document called ’myapp.com/about’ which in Rails means that I want to GET or “read” data from the “about” page. In this example, I am simply going to pass this to a StaticContoller by directing the traffic to: static#about , which says
pass this traffic “to the StaticContoller and call the about method" (or “action” in Rails lingo). and passes the HTTP command onto the relevant controller (the “C” in MVC).

The controllers job is to process that request by using the Models to represent application data and then call upon a View to display that data to the user complete with the information requested with the initial HTTP command.

There’s a lot more to understanding how this works, as Rails is a framework that is built leveraging conventions (marketed as “convention over configuration”), which simply means that these pieces are all “wired” together based on naming conventions.

How does this all fit in with APIs?

In the case of Rails applications, all of the above process holds true, but we exclude the “View” part (mostly). In the case of an API, another application is requesting information, and the job of the API is to return that information in a mutually agreed upon language; which in most cases in json.

Here if we are making a HTTP GET request, we want to “read” information; so the Rails application would still be routing that request to a controller, and the controller would still be interacting with one or more of the application models, but the last part differs. Unlike a standard web page, an API request would be expecting different content in the body of the HTTP response, which is often text formatted as JSON or (JavaScript Object Notation). In other words, the “View” here would be simply JSON data, no HTML or CSS.