Dylan Paulus' Blog

How to Use PostgreSQL for Data Normalization

Fri, 20 Dec 2024 00:00:00 GMT

Managing a database is more than just storing information—it's about storing data efficiently, effectively, and balancing trade-offs. We can employ techniques like data normalization to optimize our data for maintainability and readability, or data denormalization to optimize for raw query speed. Data normalization is the process of breaking data down into structured tables to reduce duplication and make it easier to query and store by enforcing standardization.

In this article, we'll take a look at what data normalization is, how to apply normal forms to achieve data normalization, challenges and tools for data normalization in PostgreSQL, tips on when to denormalize, and how TimescaleDB makes normalization easier.

Resizing AWS Mac Volumes

Tue, 03 Dec 2024 00:00:00 GMT

I recently ran into an issue with our Mac build machine in AWS, where the EC2 instance kept running out of disk space. It should be easy enough to bump the EBS volume size and call it a day. Wrong. No matter what I changed the volume size to, the Mac instance would not recognize the new space. What gives?
After some digging, I found that Mac requires us to resize the OS APFS (Apple File System) container after providing the volume with more space. Let’s walk through, from the start, how to increase the size of an EBS volume on a Mac AWS instance.

Increase EBS Volume Size

In the EC2, under Instances, select the instance that needs the volume resized.

Once inside the instance, select Storage and the volume that needs to be resized.

Then, with the volume selected, choose Modify Volume from the Actions dropdown.

Update Size to be the new desired size of the volume.

After the volume has been resized, we need to reboot the EC2 instance. Navigate back to the instance dashboard and select Instance State > Reboot instance.
This may take some time for the instance to fully reboot.

But once the instance is back up and in a healthy state, connect into the instance by going into the instance dashboard and selecting Connect.
Use whichever method you prefer to connect to the instance.

Now we can see how much disk space this instance has. To do this run df -h or diskutil:

diskutil list external physical

At this point you will notice that even though the volume has been increased, the OS has not recognized the new space. diskutil and df is showing the old volume size.
The Apple file system doesn't expand automatically to fill the new space to avoid potential data loss, and provide users control over the space on the system.

To expand APFS use the new space run the following commands:

First, repair the disk to fix and prevent any potential problems:

PDISK=$(diskutil list physical external | head -n 1 | cut -d " " -f 1)
yes | sudo diskutil repairDisk $PDISK

Finally, resize the APFS container to take advantage of the new space:

APFSCONT=$(diskutil list physical external | grep "Apple_APFS" | tr -s " " | cut -d " " -f 8)
sudo diskutil apfs resizeContainer $APFSCONT 0

After running the above commands, you will see the new space reflected by again running df -h or diskutil list external physical!

Recursive Query in SQL: What It Is, and How to Write One

Mon, 04 Nov 2024 00:00:00 GMT

As developers, querying in PostgreSQL for hierarchical data is difficult. SQL is a declarative programming language, but our brains are trained to think imperatively. Recursive queries using Common Table Expressions (CTE) simplify writing iterative queries and are essential in traversing hierarchical data, like tree or graph structures.

Throughout this article, we'll explore SQL recursive queries with examples, look at optimizing recursive queries, and discuss advanced techniques.

Understanding SQL Aggregate Functions

Mon, 28 Oct 2024 00:00:00 GMT

You may have heard that "data is the new oil." By itself, data is unrefined and not valuable, but given processing and refinement, it becomes precious. We gain insights into our products, applications, and customers by exploring our data. PostgreSQL exposes aggregate functions that give us the tools to transform and process our data to provide meaning.

In this article, we'll take a look at how to use SQL aggregate functions, the pitfalls, and how Timescale gives us advanced tooling to aggregate time-series data.

Understanding Foreign Keys in PostgreSQL

Sat, 28 Sep 2024 00:00:00 GMT

Foreign keys in PostgreSQL are a fundamental way of defining relationships between tables. Splitting data across multiple tables is foundational to relational databases and data normalization. However, when spreading related data across various tables, we must ensure that values in one table are valid and exist in another. Enter foreign keys.

Explaining PostgreSQL EXPLAIN

Tue, 30 Jul 2024 00:00:00 GMT

EXPLAIN is a command we prepend to queries to tell us what operations PostgreSQL plans to run for that query, how many rows each operation touches in the database(s), and how long those operations take. EXPLAIN is the go-to performance diagnostic tool for discovering what is causing a query to run slowly.

PostgreSQL Security Guide

Thu, 04 Apr 2024 00:00:00 GMT

Databases store an application's most valuable asset: data. This data includes personal information like names, passwords, and street addresses, but it could also include company secrets. Having an insecure database is devastating for a few reasons:

Leaking personal data erodes trust from users and customers
Falling share prices or loss of revenue
You can be hit with regulatory penalties (e.g., GDPR)
In specific sectors, vulnerabilities can be used to cause physical harm

How to Use a Common Table Expression (CTE) in SQL

Sat, 09 Mar 2024 00:00:00 GMT

Common Table Expressions (CTEs) are my go-to tool when writing complex SQL queries. They can be thought of as working like sub-queries or temporary tables but with their own superpowers.

In this article, we'll take a deep dive into what CTEs are and how they can simplify your queries, how recursive CTES can turn impossible PostgreSQL queries into possible, and how to use CTEs to create optimization fences to improve the performance of your queries.

Understanding PostgreSQL Tablespaces

Sun, 28 Jan 2024 00:00:00 GMT

Tablespaces are a PostgreSQL feature that gets easily overlooked but can provide substantial speed improvements and cost-saving potential. As our database grows, tablespaces become a powerful tool in our toolbelt.

How to Design Your PostgreSQL Database: Two Schema Examples

Tue, 02 Jan 2024 00:00:00 GMT

How we design and lay out our tables is one of the most important decisions in developing effective and efficient PostgreSQL databases. A database schema is the architecture or structure of the data in our database. It defines what tables we'll have, columns, data types, naming, and relationships between tables.

Creating a Fast Time-Series Graph With Postgres Materialized Views

Mon, 27 Nov 2023 00:00:00 GMT

Imagine you have a massive amount of time-series data you want to explore and visualize. Seeing the latest trends, the historical patterns, and the outliers in your data can help you gain insights and make decisions. But how do you visualize and analyze time-series data effectively? How do you create graphs, plots, and other visualizations for real-time analytics showing the current state of your data and the historical changes over different time intervals? And how do you do it efficiently without sacrificing performance or accuracy?

In this article with Timescale we dive into practical examples of using materialized views and continuous aggregates to create fast, performant time-series graphs.

Easily Generate Mock Data with PostgreSQL

Thu, 09 Nov 2023 00:00:00 GMT

import { Accordion } from "../../../../components/Accordion";

When writing articles about PostgreSQL there are times I need to generate large swaths of data to test and demonstrate a topic (for example, these Timescale articles here and here).
It can be a pain to manually insert data or create a CSV and import it into PostgreSQL--which I always have to StackOverflow.
Lately, I ran into a much simpler solution to generating data: the generate_series function.
It's perfectly suited for integers and timestamp data types, streamlining various tasks such as populating test databases or setting up date ranges for reports.

Generating Mock Data

generate_series can be thought of as a for-loop or generator to produce a range of numbers or dates.

To generate a range of numbers, we call generate_series with a start and end value:

SELECT * FROM generate_series(1, 10);

We can specify a step value by providing generate_series as an optional third argument.

SELECT * FROM generate_series(1, 10, 2.5);

Inserting Mock Data

generate_series' power comes to fruition when we need to insert mock data into a table.
We can easily insert a range of numbers into a table by using generate_series in a SELECT statement and then inserting the results into a table.

For the rest of this article, we'll use users table that looks like this for our examples:

CREATE TABLE users (
 id serial PRIMARY KEY,
 name text NOT NULL,
 created_on timestamptz
);

Then, if we wanted to insert five users into the table we could run:

INSERT INTO users (name)
SELECT
    'Dylan'
FROM generate_series(1, 5);

This pattern can be used to insert any number of rows into a table.
If you're feeling brave, try inserting 1,000,000 users into the table by changing generate_series(1, 5) to generate_series(1, 1000000)!

Up to this point we are creating a lot of duplicate data.
What if we wanted to create a bunch of users with all distinct names?
We can access the current index of the loop (using as) to generate a unique name for each user.

That would look like this:

INSERT INTO users (name)
SELECT
    'Dylan number ' || i
FROM generate_series(1, 5) as i;

Creating Time-Series Data

generate_series is incredibly effective at generating time series data.
This is where I get the most use out of it because it can become extremely tedious to create a lot of data around time ranges.

Similar to the integer example, generate a range of timestamps by providing a start and end value followed by an optional step or interval.

For example, to generate a user for every hour in a week, we could run the following SQL:

INSERT INTO users (name, created_on)
SELECT
    'Dylan',
    time_hour
FROM generate_series(
    TIMESTAMPTZ '2023-11-01',
    TIMESTAMPTZ '2023-11-07',
    INTERVAL '1 hour'
) as time_hour;

This query creates 146 rows with a user named Dylan every hour between November 1st and November 7th, 2023.

You may be asking yourself, can we use multiple generate_series to populate multiple fields? Yes!
But, we need to use joins to combine the data from the two series.
To quickly create a grid of users and created_on dates we can take the cartesian product of two series, otherwise known as a cross join, by adding another generate_series to the FROM clause.

A cartesian product is the result of joining two tables where the result is the combination of every row in the first table with every row in the second table.

For example, let's say we have two pants (blue jeans and sweatpants) and three shirts (t-shirt, polo, and sweatshirt).

The cartesian product of our pants and shirts would look like:

| Pants       | Shirts      |
| ----------- | ----------- |
| Blue Jeans  | T-Shirt     |
| Blue Jeans  | Polo        |
| Blue Jeans  | Sweatshirt  |
| Sweatpants  | T-Shirt     |
| Sweatpants  | Polo        |
| Sweatpants  | Sweatshirt  |

INSERT INTO users (name, created_on)
SELECT
    'Dylan number' || i,
    time_hour
FROM
    generate_series(1, 5) as i,
    generate_series(
        TIMESTAMPTZ '2023-11-01',
        TIMESTAMPTZ '2023-11-07',
        INTERVAL '2 days'
    ) as time_hour;

In the INSERT statement above, we'll create four time_hour timestamps for every two days in the week for every iteration of i (there are five of them).
Resulting in 4 * 5 = 20 twenty rows created.
To better grasp what's happening here, it'll be easier to look at the SELECT output of the users table.

Using multiple generate_series functions combined with a cartesian product can be a powerful combination for creating unique, time-series data.

Conclusion

PostgreSQL's generate_series is a game-changer for developers like me, who frequently dive into the deep end of data generation for testing and optimizing queries. It's a powerhouse that can effortlessly create anything from a handful to millions of rows, transforming a potentially arduous task into a few simple lines of SQL.
So, when you need to mock up data, let generate_series be your go-to solution.

Happy data generating!

Need a realistic dataset to test something more interesting than a flat table? Postgres: The Graph Database You Didn't Know You Had uses generate_series to populate nodes and edges, then walks through recursive CTEs against the same data. For performance work on bigger tables, Explaining PostgreSQL EXPLAIN covers how to read query plans once the rows pile up.

Wrangling Table Bloat in Large PostgreSQL Tables

Fri, 03 Nov 2023 00:00:00 GMT

I worked with Timescale again to write an article on how table bloat effects large tables, and how we can fix it.

We cover a range of topics including:

What is table bloat?
Why is it an issue?
How to monitor table bloat?
What Vacuum and AutoVacuum is
Tips with tuning AutoVacuum
Table Partitioning
How Timescale chunks makes partitioning easier
And more!

How to Reduce Your PostgreSQL Database Size

Sat, 07 Oct 2023 00:00:00 GMT

I had the pleasure of working with Timescale to
write an article on how to reduce your PostgreSQL database size.

We cover a range of topics including:

What are pages and tuples
How table bloat occurs
Why we should vacuum our tables
Timescale compression
Retention policies
And more!

Unraveling Graph Structures: Exploring Adjacency Matrices

Wed, 19 Jul 2023 00:00:00 GMT

import { Image } from "astro:assets";
import baseGraph from "./base_graph.svg";
import table from "./table.svg";
import unidirect from "./unidirect.svg";

In Postgres: The Graph Database You Didn't Know You Had we covered how we can store a DAG (Directed Acyclic Graph) in a relational database.
We looked at one representation of a graph data structure called an adjacency list--a table with two columns representing how nodes connect.
The columns store connections from the source or "from" node to a destination or "to" node.

Our Graph

    <div class="w-full lg:w-1/2 mt-16 lg:mt-0 mx-auto">
        <strong>Adjacency List</strong>
        <table class="w-full mx-auto">
            <thead>
                <tr>
                    <th colspan="2">Edges</th>
                </tr>
                <tr>
                    <th>Source</th>
                    <th>Destination</th>
                </tr>
            </thead>
            <tbody>
                <tr>
                    <td>A</td>
                    <td>B</td>
                </tr>
                <tr>
                    <td>A</td>
                    <td>C</td>
                </tr>
            </tbody>
        </table>
    </div>
</div>

Using Python, a code representation would look like:

class Node:
    pass

A = Node()
B = Node()
C = Node()

adjacency_list = [
    { "source": A, "destination": B },
    { "source": A, "destination": C },
]

An adjacency list is a simple and efficient way to store graph data, but there are many more ways to represent graphs.
In this article, we'll explore one of these alternatives called the adjacency matrix.

Adjacency Matrix

An adjacency matrix is a table with a row and column for each node in the graph (or NxN matrix).
To represent the edges we store a 1 in a column for a connection and a 0 for no connection.
We will start out exploring how to represent DAG's as an adjacency matrix since we covered DAG's in the Postgres article.
To store direction in an adjacency matrix the x-axis or rows represent the "from" or "source" node.
The y-axis represents the connection.
Using the same graph as above, the adjacency matrix would look like this:

Our Graph

    <div class="w-full lg:w-1/2 mt-16 lg:mt-0 mx-auto">
        <strong>Adjacency Matrix</strong>
        <table class="w-full mx-auto">
            <thead>
                <tr>
                    <th></th>
                    <th>A</th>
                    <th>B</th>
                    <th>C</th>
                </tr>
            </thead>
            <tbody>
                <tr>

    <td class="bg-secondary-300">A</td>
                    <td>0</td>
                    <td>1</td>
                    <td>1</td>
                </tr>
                <tr>
    <td class="bg-secondary-300">B</td>
                    <td>0</td>
                    <td>0</td>
                    <td>0</td>
                </tr>
                    <tr>
    <td class="bg-secondary-300">C</td>
                    <td>0</td>
                    <td>0</td>
                    <td>0</td>
                </tr>
            </tbody>
        </table>
    </div>
</div>

adjacency_matrix = [
  [0, 1, 1],
  [0, 0, 0],
  [0, 0, 0]
]

What about non-DAG graphs?

For undirected graphs, graphs where all connections are bidirectional, the setup is the same to create the adjacency matrix.
The only difference is our graph has no explicit direction. If A connects to B, then B also connects to A.
Let's take our previous DAG graph, and remove the direction.

Our Graph

    <div class="w-full lg:w-1/2 mt-16 lg:mt-0 mx-auto">
        <strong>Adjacency Matrix</strong>
        <table class="w-full mx-auto">
            <thead>
                <tr>
                    <th></th>
                    <th>A</th>
                    <th>B</th>
                    <th>C</th>
                </tr>
            </thead>
            <tbody>
                <tr>

    <td class="bg-secondary-300">A</td>
                    <td>0</td>
                    <td>1</td>
                    <td>1</td>
                </tr>
                <tr>
    <td class="bg-secondary-300">B</td>
                    <td>1</td>
                    <td>0</td>
                    <td>0</td>
                </tr>
                    <tr>
    <td class="bg-secondary-300">C</td>
                    <td>1</td>
                    <td>0</td>
                    <td>0</td>
                </tr>
            </tbody>
        </table>
    </div>
</div>

A cool property emerges from undirected graphs. Can you spot a pattern in the table above?
Draw a diagonal line from the top left of our matrix to the bottom right (sandwich square style) and fold the matrix along this line.

The connections mirror each other across this line. Our matrix is considered symmetric when this occurs.
Symmetric matrices appear in all undirected graphs, but not DAGs!

This is great, but why would we use an Adjacency Matrix?

Matrices are incredibly fast at checking if two nodes are connected

Instead of having to loop through all the edges in an adjacency list to find if two nodes are connected, an adjacency matrix acts
as a hash table. In our example graph above, if we wanted to check if A has an edge to B it would be as simple as checking the [B][A] position
in the matrix.

Note: Since we're working with DAG's and 2D arrays, the order we look up a connection is flipped: [Destination][Source].

A = 0
B = 1

has_connection = adjacency_matrix[B][A]

Removing and adding a connection between nodes is similar and run in constant time.
Need to connect two nodes? Modify the position in the matrix to be 1 (adjacency_matrix[destiation][source] = 1).
What about deleting an edge? Update the value to be 0 (adjacency_matrix[destiation][source] = 0)!

Why would I not use an Adjacency Matrix?

They're huge!

If we look at an adjacency matrix we need to store every bit of information about the graph, the connected nodes (1's), and not connected nodes(0's).
Compared to an adjacency list which stores only the connections; adjacency matrices take up a lot of space!

It's expensive to add/remove nodes

We talked about how adjacency matrices are fast at looking up, adding, and removing connections between nodes.
On the flip side, adjacency matrices are slow when adding or removing nodes from the graph.
To add a node we need to copy our matrix to a new matrix with an additional row and column(of size N+1 x N+1).
Then, populate the matrix with the connections to or from the new node.
To compare, adding a new node to an adjacency list is a matter of pushing a new node to the list of nodes.

End

There are many different ways to represent and visualize a graph.
A different representation may be better based on your personal use cases and requirements.
Need to quickly look up which nodes are connected or need to quickly add or remove edges? Then the adjacency matrix may be the best choice.
Are you constantly adding nodes to the graph and are limited in your memory footprint? The adjacency list is the representation for you!

Improve Your Prompts for LLMs: Simple and Effective Techniques

Wed, 07 Jun 2023 00:00:00 GMT

import { Prompt } from "./prompt";

Tools like ChatGPT and Bing have been skyrocketing in popularity.
ChatGPT took five days since launch to reach 1 million users.
Governments all over the world are trying to figure out what to do with this technology.
Sweet AI-generated images are showing up everywhere; like this dog I generated using Bing:

"Can you generate a picture of an astronaut dog jumping over a fire on the moon?"

Though LLMs (Large Language Models) are still in their infancy, research has shown some pretty big productivity boosts in a range of different professions.
Using metrics from Github Copilot, an AI-based coding tool, Github has found that developers complete tasks in 55% less time when taking advantage of AI.

This is all to say that LLMs are a tool we'll need to learn to use and use well.

There are many options when choosing a LLM, with the most popular being ChatGPT and Bing.
OpenAI's ChatGPT is the most well-known, but if we want to use the latest features like ChatGPT-4 (an upgrade to ChatGPT-3) we'll need to pay $20 a month.
Microsoft has released new Bing that takes advantage of ChatGPT-4 behind the scenes and is free to use.
Finally, Google has Bard which is also free to use.
All offerings come with their unique pros and cons.

Regardless of which tool you use, the question remains: how do we get the most out of these tools?

Prompt Engineering

We interact with LLMs by giving them a prompt, or text input, generally in the form of a question or instruction.
LLMs then reason out the answer and respond.
Prompt Engineering is a term coined to describe the process of writing prompts to get the best results from LLMs.
Just like in everyday conversation, the words we choose to ask in a question can dramatically change the response we get.
For example, if I ask “What is the best way to get to the airport?” I’ll get a different response than asking “How do I get to the airport?“.

Throughout this article we’ll build on a prompt to create a meal plan for a single day; taking advantage of different Prompt Engineering techniques.
I’ll provide the prompt used, and the response I got back from the LLM—in my case I’ll be using ChatGPT-3.
Try it for yourself, but remember that the results will vary by the LLM being used.

Please create me a low sugar meal plan for one day. **Low-Sugar Meal Plan for One Day**

Breakfast

Scrambled eggs with vegetables (spinach, bell peppers, mushrooms)
Whole grain toast
A small serving of fresh berries (such as strawberries or blueberries)
Herbal tea or black coffee (unsweetened)

Snack

Greek yogurt with a sprinkle of cinnamon
A handful of unsalted almonds

Lunch

Grilled chicken breast
Mixed greens salad with cherry tomatoes, cucumber, and avocado
Olive oil and lemon juice dressing (no added sugar)
Steamed broccoli

Snack

Sliced cucumber and carrot sticks with hummus

Dinner

Baked salmon fillet with lemon and dill
Quinoa pilaf with mixed vegetables (broccoli, carrots, peas)
Steamed asparagus

Dessert

Fresh fruit salad (such as watermelon, cantaloupe, and kiwi)

Note: Remember to drink plenty of water throughout the day.
Adjust portion sizes according to your specific dietary needs and consult with
a healthcare professional or a registered dietitian for personalized advice.

Constraints

Just like people, LLMs need constraints and clarity to understand what's being asking.
Be specific when writing prompts, and have a desired outcome in mind.
The best mental model I've been told is to think of LLMs as an intern, brand new to the job.
They are eager to get stuff done, but need clear and direct instructions.
The best way to get the best results out of LLMs is to be specific.

Let's improve upon our prompt by adding some constraints.

Please create me a low sugar meal plan for one day. The plan should be a maximum 1,800 calories, and do not include breakfast. No gluten. High in protein. **Low-Sugar, Gluten-Free, High-Protein Meal Plan for One Day**

Lunch

Grilled chicken breast (4 oz)
Quinoa salad with mixed vegetables (cucumber, cherry tomatoes, bell peppers)
dressed with lemon vinaigrette
Steamed broccoli (1 cup)

Snack

Greek yogurt (6 oz) with sliced almonds (1 tbsp) and a sprinkle of cinnamon

Dinner

Baked salmon fillet (4 oz) with garlic and herbs
Sautéed kale (1 cup) with garlic and olive oil
Roasted sweet potatoes (1 medium) with a sprinkle of paprika

Snack

Celery sticks with almond butter (2 tbsp)

Dessert

Mixed berries (1 cup) with a dollop of unsweetened whipped cream

Note: Please note that portion sizes and specific calorie counts may
vary depending on the size and brand of the ingredients used. Adjust the
portion sizes and consult a healthcare professional or a registered
dietitian for any specific dietary needs or concerns.

Role prompting, or "Act like a..."

Role Prompting or "Act like a ..." is a technique that can be used to provide more context and constraints to LLMs.
First we tell the LLM to assume a role or persona. Then we provide a prompt.
For example, if we had a question about woodworking we might say, "Act like a master woodworker. What is the best way to cut a dovetail joint?".
Role prompting is another great way to provide constraints to LLMs.

Let's improve upon our meal plan prompt by adding a role.

Act as an expert nutritionist with 20 years of experience. Please create me a low sugar meal plan for one day. The plan should be a maximum 1,800 calories, and do not include breakfast. No gluten. High in protein. **Low Sugar Meal Plan**

Maximum 1,800 Calories | No Gluten | High in Protein

Lunch

Grilled chicken breast (4 oz) seasoned with herbs and spices
Quinoa salad with mixed vegetables (such as bell peppers, cucumbers, and cherry
tomatoes) dressed with lemon juice and olive oil
Steamed broccoli (1 cup) -
Mixed greens salad with avocado slices and a light vinaigrette dressing
Sparkling water with a squeeze of fresh lemon

Snack

Greek yogurt (6 oz) topped with mixed berries (such as strawberries and
blueberries)
Handful of unsalted almonds

Dinner

Baked salmon fillet (4 oz) marinated in a mix of lemon juice, garlic, and dill
Roasted Brussels sprouts with garlic and olive oil (1 cup)
Steamed asparagus (1 cup)
Quinoa (1/2 cup) cooked with vegetable broth
Herbal tea or water with a slice of lemon

Evening Snack

Celery sticks and carrot sticks with hummus
Green tea or water

This meal plan is designed to be low in added sugars and gluten-free while
providing ample protein from lean sources like chicken, fish, and Greek
yogurt. It incorporates a variety of colorful vegetables, healthy fats from
avocado and olive oil, and whole grains like quinoa for additional fiber.
Remember to drink plenty of water throughout the day to stay hydrated.

Please note that this is a generalized meal plan, and it's always a good idea to consult with a registered dietitian or nutritionist who can create a personalized meal plan based on your specific dietary needs and health goals.

Few shot prompting

Few shot prompting is my favorite technique, and can really take the performance of LLMs to the next level.
First we provide the LLM with a few examples (or shots) of what we want, and then we ask the LLM to generate a similar response (furthering adding constraints to our prompt).
The term "shot" is synonymous with "example". In Pompt Engineering you will also find zero shot prompting and one shot prompting.

Zero Shot Prompting: No examples are provided
One Shot Prompting: One example is provided
Few Shot Prompting: Two or more examples are provided

The shots, or examples, can be given in the same prompt, or broken out into separate prompts.

For example, in our meal plan example we could ask the LLM in a single prompt:

Use the following examples of a meal plan:

example 1:

Breakfast (364 calories)

1 serving Egg & Avocado Toast with Spinach & Salsa

A.M. Snack (59 calories)

1 medium peach

Lunch (584 calories)

1 serving Hot Turkey Pesto Sandwich

P.M. Snack (200 calories)

1 cup edamame in pods

Dinner (306 calories)

1 serving One-Pot Lentil & Vegetable Soup with Parmesan

Daily Totals: 1,512 calories, 65g fat, 93g protein, 140g carbohydrate, 34g fiber, 1,538mg sodium

To make it 1,200 calories: Omit the morning and afternoon snacks and reduce the pesto from 1 Tbsp. to 1 tsp. on the sandwich at lunch.

To make it 2,000 calories: Add 1/2 cup unsalted roasted cashews to A.M. snack and increase to 1 1/2 cups edamame at P.M. snack.

example 2:

Breakfast (302 calories)

1 serving Copycat Spinach and Mushroom Egg Bites
1 slice whole-wheat bread
1 1/4 cups sliced strawberries

A.M. Snack (315 calories)

1 medium banana
2 Tbsp. creamy natural peanut butter

Lunch (306 calories)

1 serving One-Pot Lentil & Vegetable Soup with Parmesan

P.M. Snack (247 calories)

32 unsalted dry-roasted almonds

Dinner (349 calories)

1 serving Chicken, Quinoa & Sweet Potato Casserole

Daily Totals: 1,518 calories, 67g fat, 75g protein, 158g carbohydrate, 31g fiber, 1,482mg sodium

To make it 1,200 calories: Omit peanut butter at A.M. snack and reduce almonds to 18 at P.M. snack.

To make it 2,000 calories: Increase to 2 slices bread and 1 1/2 cups strawberries at breakfast, increase peanut butter to 1/4 cup at A.M. snack, and increase almonds to 1/2 cup at P.M. snack.

Act as an expert nutritionist with 20 years of experience. Please create me a
low sugar meal plan for one day. The plan should be a maximum 1,800 calories,
and do not include breakfast. No gluten. High in protein.

Or ask the LLM to read a few examples first before we ask our question.
To reduce the amount of time needed for the LLM to repond, we can ask it to confirm once it has read the example.

Read the following meal plan and respond with, "yes" once you read it.

Breakfast (364 calories)

1 serving Egg & Avocado Toast with Spinach & Salsa

A.M. Snack (59 calories)

1 medium peach

Lunch (584 calories)

1 serving Hot Turkey Pesto Sandwich

P.M. Snack (200 calories)

1 cup edamame in pods

Dinner (306 calories)

1 serving One-Pot Lentil & Vegetable Soup with Parmesan

Daily Totals: 1,512 calories, 65g fat, 93g protein, 140g carbohydrate, 34g fiber, 1,538mg sodium

To make it 1,200 calories: Omit the morning and afternoon snacks and reduce the pesto from 1 Tbsp. to 1 tsp. on the sandwich at lunch.

To make it 2,000 calories: Add 1/2 cup unsalted roasted cashews to A.M. snack and increase to 1 1/2 cups edamame at P.M. snack.

Read the following meal plan and respond with, "yes" once you read it.

Breakfast (302 calories)

1 serving Copycat Spinach and Mushroom Egg Bites
1 slice whole-wheat bread
1 1/4 cups sliced strawberries

A.M. Snack (315 calories)

1 medium banana
2 Tbsp. creamy natural peanut butter

Lunch (306 calories)

1 serving One-Pot Lentil & Vegetable Soup with Parmesan

P.M. Snack (247 calories)

32 unsalted dry-roasted almonds

Dinner (349 calories)

1 serving Chicken, Quinoa & Sweet Potato Casserole

Daily Totals: 1,518 calories, 67g fat, 75g protein, 158g carbohydrate, 31g fiber, 1,482mg sodium

To make it 1,200 calories: Omit peanut butter at A.M. snack and reduce almonds to 18 at P.M. snack.

To make it 2,000 calories: Increase to 2 slices bread and 1 1/2 cups strawberries at breakfast, increase peanut butter to 1/4 cup at A.M. snack, and increase almonds to 1/2 cup at P.M. snack.

Using the meal plan examples from before act as an expert nutritionist with 20 years of experience. Please create me a low sugar meal plan for one day. The plan should be a maximum 1,800 calories, and do not include breakfast. No gluten. High in protein.

As an expert nutritionist with 20 years of experience, I've created a low-sugar meal plan for one day that is gluten-free, high in protein, and falls within the maximum 1,800 calorie range. Please note that individual nutritional needs may vary, so it's always a good idea to consult with a healthcare professional or registered dietitian for personalized advice. Here's the meal plan:

Lunch (approximately 400-500 calories):

Grilled Chicken Salad with Avocado Dressing:

4-6 ounces of grilled chicken breast
Mixed salad greens (spinach, arugula, or your preferred greens)
Sliced cucumber, cherry tomatoes, and red onion
1/4 avocado, sliced
1-2 tablespoons of homemade avocado dressing (made with avocado, lemon juice, olive oil, salt, and pepper)

Afternoon Snack (approximately 150 calories):

Greek Yogurt Parfait:

1/2 cup of plain Greek yogurt
1/4 cup of mixed berries (such as blueberries and raspberries)
1 tablespoon of chopped nuts (almonds, walnuts, or your preference)
Optional: sprinkle of cinnamon or drizzle of honey (if desired)

Dinner (approximately 500-600 calories):

Baked Salmon with Quinoa and Roasted Vegetables:

4-6 ounces of baked or grilled salmon fillet
1/2 cup of cooked quinoa
Roasted vegetables of your choice (such as broccoli, bell peppers, and zucchini) seasoned with herbs and olive oil

Evening Snack (approximately 150-200 calories):

Celery with Almond Butter and Chia Seeds:

2-3 celery stalks
1-2 tablespoons of almond butter (make sure it's free of added sugars)
Sprinkle of chia seeds for added fiber and healthy fats

Remember to drink plenty of water throughout the day and adjust portion sizes based on your individual needs and preferences.
It's also essential to include regular physical activity and maintain a balanced overall diet for optimal health.

Conclusion

Compare the first meal plan to the final result. After taking advantage of the prompt engineering techniques we learned, we can see that the last meal plan is much more specific, detailed, and closer to the answer we would expect!

Using constraints, role prompting, and shot prompting, we can improve the quality of our prompts, impress our friends, and increase our productivity.

Faster and Easier Python Debugging with breakpoint() and PDB

Mon, 08 May 2023 00:00:00 GMT

Debugging is an essential skill for any software developer.
It allows us to find and fix errors in our code, improve quality and performance, and learn from our mistakes.

One of the most common and powerful tools for debugging Python code is the Python Debugger (PDB).
PDB is a module that provides an interactive command-line interface for inspecting and manipulating the state of a running program.
With PDB, we can set breakpoints, step through the code line by line, examine variables and expressions, modify values, and more.

However, using PDB can also be cumbersome and tedious.
To invoke PDB, we need to import the pdb module and insert a pdb.set_trace() statement in our code where we want to pause the execution and enter the debugger.

import pdb

def add(a: int, b:int) -> int:
  pdb.set_trace()  # pause here and enter the debugger
  return a + b

print(add(1, 2))

This means we have to modify our source code every time we want to debug it and remember to remove or comment out the pdb statements when we are done.
Moreover, if we want to use a different debugger than PDB, such as IPython or PuDB, we have to change the import statement and the function call accordingly.

Fortunately, Python 3.7 introduced a new built-in function that simplifies this process: breakpoint().
The breakpoint() function is a convenient way to start a debugger at any point in our code without having to import anything or write debugger-specific code.
All we have to do is insert a breakpoint() statement where we want to pause the execution and enter the debugger!

In this article, we will learn what breakpoint() is, how to use it with PDB and other debuggers, and how to change its behavior with environment variables.

Using breakpoint()

When using PDB, we need to learn a couple commands to interact with the debugger.
There is a long list of commands PDB gives us, but we only need to know a few of them to get started.
For example, if we want to print values we use the p command.
If we want to execute the next line of code we use the n or next command.
To continue execution until the next breakpoint we use the c or continue command.
Finally, the l or list command shows us the code around the current line we are debugging.

Command	Description
`p [variable_name]`	Print the value of a expression.
`n` or `next`	Continue execution until the next line in the current function is reached or it returns.
`s` or `step`	Execute the current line, stop at the first possible occasion (either in a function that is called or in the current function).
`c` or `continue`	Continue execution, only stop when a breakpoint is encountered.
`l` or `list`	List source code for the current file.
`h` or `help`	Prints a list of commands we can use with PDB.

Let's see how breakpoint() works.
Below is a recursive function that calculates the factorial of a given number.
I've added a breakpoint() statement to the function so we can pause the execution and enter the debugger.

# main.py

def factorial(number: int) -> int:
  if number < 0:
    raise ValueError("`n` must be non-negative.")
  elif number <= 1:
    return 1
  else:
    breakpoint()  # pause here and enter the debugger
    return number * factorial(number - 1)


# factorial(5) is: 5 * 4 * 3 * 2 * 1 = 120
print(factorial(5))

When we run this code, the program will stop at the breakpoint() statement and launch the default debugger, which is PDB by default.
We can then use the PDB commands to inspect and manipulate the program state.

Open in new window

If you want to navigate back to the code, click "Show files" at the top left
of the code editor and select "main.py".

We can see that breakpoint() pauses the execution at the line where it is called.
By using the commands we learned above, we can inspect the program state (p number to see the value of n) and step through the code line by line (s).

Changing the debugger behavior

One of the advantages of using breakpoint() over pdb.set_trace() is that we can switch to a different debugger at any time.
By setting the PYTHONBREAKPOINT environment variable we can tell Python which debugger we would like to use.
For example, if we want to use IPython as our debugger, we can run:

$ export PYTHONBREAKPOINT=IPython.core.debugger.set_trace
$ python3 main.py

Another advantage of using breakpoint() is that we can disable all breakpoints in our code by setting the PYTHONBREAKPOINT environment variable to 0.
This is useful when we want to run our code without entering the debugger; without having to remove or comment out all the breakpoint() statements.

$ export PYTHONBREAKPOINT=0
$ python3 main.py

End

breakpoint() is a much needed improvement over pdb.set_trace()!
It gives us the ability to quickly debug our code, and easily switch between different debuggers.

Postgres: The Graph Database You Didn't Know You Had

Tue, 28 Mar 2023 00:00:00 GMT

PostgreSQL (Postgres), is a powerful relational database that can store a wide range of data types and data structures.
When it comes to storing graph data structures we might reach for a database marketed for that use case like Neo4J or Dgraph. Hold your horses!
While Postgres is not generally thought of when working with graph data structures, it is perfectly capable to store and query graph data efficiently.

Understanding Graph Data Structures

Before we introduce Postgres as a graph database we need to know what a graph data structure is.
A graph, or a graph data structure, is a collection of nodes and edges,
where each node represents an entity or "thing", and each edge represents the relationship between two nodes.

<g
  stroke-linecap="round"
  transform="translate(398 284) rotate(0 69.5 70.5)">
  <path
    d="M83.43 1.23 C93.23 2.08, 104.25 7.29, 112.17 13.41 C120.08 19.53, 126.57 28.93, 130.91 37.96 C135.26 46.99, 137.88 57.39, 138.24 67.6 C138.59 77.82, 137.09 89.73, 133.03 99.23 C128.97 108.73, 121.58 118.15, 113.87 124.6 C106.16 131.06, 96.49 135.31, 86.76 137.97 C77.03 140.64, 65.19 142.3, 55.48 140.59 C45.78 138.88, 36.62 134.12, 28.52 127.7 C20.42 121.28, 11.8 111.36, 6.9 102.06 C1.99 92.76, -0.65 82.01, -0.93 71.91 C-1.2 61.81, 0.91 50.75, 5.23 41.48 C9.54 32.22, 17.07 22.98, 24.96 16.3 C32.85 9.63, 41.75 3.74, 52.58 1.43 C63.4 -0.87, 82.78 1.56, 89.9 2.49 C97.02 3.42, 95.73 5.89, 95.29 7.02 M63.98 1.05 C73.4 -0.84, 85.27 0.85, 94.81 4.48 C104.36 8.11, 114.42 15.3, 121.26 22.83 C128.1 30.35, 133.15 39.55, 135.85 49.62 C138.55 59.7, 139.24 73.18, 137.46 83.29 C135.68 93.4, 130.57 102.19, 125.14 110.28 C119.71 118.37, 113.5 126.68, 104.86 131.83 C96.22 136.97, 83.33 140.64, 73.28 141.14 C63.22 141.63, 53.7 138.46, 44.52 134.79 C35.35 131.11, 25.15 126.48, 18.25 119.09 C11.35 111.69, 6.16 100.5, 3.13 90.43 C0.1 80.36, -1.3 68.81, 0.07 58.65 C1.44 48.49, 5.24 37.69, 11.33 29.48 C17.43 21.26, 27.64 14.29, 36.64 9.36 C45.65 4.42, 60.78 1.06, 65.38 -0.13 C69.97 -1.32, 63.98 1.22, 64.21 2.23"
    stroke-width="1"
    ></path>
</g>
<g
  stroke-linecap="round"
  transform="translate(255 590) rotate(0 69.5 70.5)">
  <path
    d="M50.22 2.43 C58.78 -1.42, 69.79 -1.29, 79.71 0.31 C89.64 1.9, 101.36 5.96, 109.78 11.99 C118.21 18.02, 125.27 27.46, 130.28 36.5 C135.29 45.54, 139.35 56.17, 139.84 66.25 C140.33 76.32, 137.01 87.51, 133.19 96.96 C129.38 106.4, 124.17 116.21, 116.95 122.9 C109.74 129.6, 99.76 134.2, 89.9 137.14 C80.04 140.08, 67.65 142.15, 57.78 140.53 C47.9 138.92, 38.75 133.23, 30.66 127.43 C22.58 121.63, 14.34 114.4, 9.27 105.74 C4.21 97.09, 0.99 85.8, 0.27 75.53 C-0.46 65.26, 1.09 53.71, 4.93 44.11 C8.76 34.51, 15.08 24.91, 23.26 17.92 C31.44 10.93, 48.18 4.81, 54.01 2.18 C59.84 -0.46, 58.06 1.18, 58.22 2.1 M38.48 7.08 C46.49 1.45, 59.19 -1.28, 69.19 -1.46 C79.18 -1.64, 89.2 1.53, 98.44 6 C107.69 10.47, 118.19 17.23, 124.66 25.35 C131.12 33.46, 135.16 44.69, 137.23 54.69 C139.29 64.69, 139.07 75.18, 137.04 85.32 C135.02 95.46, 131.09 107.57, 125.07 115.51 C119.04 123.45, 109.86 128.77, 100.9 132.95 C91.94 137.13, 81.65 140.15, 71.29 140.59 C60.93 141.02, 48.06 139.62, 38.75 135.55 C29.43 131.49, 21.47 124.29, 15.41 116.2 C9.34 108.1, 4.8 97.11, 2.38 86.99 C-0.04 76.88, -1.43 65.42, 0.87 55.49 C3.17 45.56, 9.7 35.64, 16.18 27.41 C22.65 19.18, 35.81 9.33, 39.71 6.12 C43.62 2.91, 39.08 7.06, 39.61 8.15"
    stroke-width="1"
    ></path>
</g>
<g
  stroke-linecap="round"
  transform="translate(584 538) rotate(0 69.5 70.5)">
  <path
    d="M103.2 7.88 C112.19 11.55, 119.45 20.72, 125.29 29.19 C131.13 37.65, 136.3 48.81, 138.24 58.67 C140.19 68.53, 139.86 78.66, 136.98 88.34 C134.1 98.03, 127.69 108.95, 120.96 116.78 C114.23 124.61, 105.73 131.24, 96.59 135.32 C87.46 139.4, 76.05 141.55, 66.16 141.25 C56.26 140.95, 46.09 138.22, 37.25 133.49 C28.41 128.77, 19 121.33, 13.1 112.91 C7.2 104.49, 3.51 93.29, 1.84 82.97 C0.17 72.65, 0.4 60.81, 3.07 50.99 C5.74 41.17, 11.33 31.59, 17.86 24.05 C24.39 16.51, 33.18 9.72, 42.26 5.74 C51.33 1.77, 61.81 -0.66, 72.33 0.18 C82.84 1.03, 99.53 8.64, 105.33 10.83 C111.12 13.02, 107.81 12.36, 107.09 13.32 M82.33 1.63 C92.34 2.11, 103.37 6.67, 111.28 12.6 C119.19 18.53, 125.02 28.06, 129.78 37.22 C134.55 46.38, 139.02 57.6, 139.88 67.57 C140.73 77.54, 138.82 87.69, 134.9 97.06 C130.98 106.44, 124.21 117.06, 116.34 123.82 C108.48 130.58, 97.37 134.74, 87.69 137.61 C78.01 140.48, 67.85 142.83, 58.26 141.02 C48.68 139.22, 38.6 132.95, 30.19 126.78 C21.77 120.61, 12.89 112.72, 7.74 103.99 C2.59 95.25, -0.42 84.61, -0.71 74.37 C-1 64.13, 1.79 51.85, 6.01 42.54 C10.23 33.23, 16.93 24.99, 24.62 18.52 C32.31 12.06, 42.8 6.88, 52.14 3.75 C61.48 0.62, 75.98 0.04, 80.65 -0.26 C85.31 -0.56, 80.03 0.63, 80.15 1.95"
    stroke-width="1"
    ></path>
</g>
<g stroke-linecap="round" transform="translate(10 10) rotate(0 69.5 70.5)">
  <path
    d="M54.43 2.18 C63.73 -1.18, 75.84 -1.09, 85.64 1.13 C95.44 3.35, 105.57 9.17, 113.23 15.51 C120.89 21.85, 127.22 29.92, 131.62 39.17 C136.01 48.41, 139.34 60.8, 139.58 70.98 C139.83 81.16, 137.59 91.17, 133.09 100.23 C128.59 109.29, 120.63 118.8, 112.57 125.33 C104.5 131.87, 94.34 137.18, 84.68 139.44 C75.03 141.71, 64.24 141.11, 54.64 138.94 C45.04 136.76, 34.87 132.53, 27.08 126.39 C19.3 120.25, 12.56 111.49, 7.94 102.07 C3.32 92.65, -0.31 80.25, -0.64 69.87 C-0.98 59.49, 1.41 48.89, 5.95 39.8 C10.5 30.7, 16.76 21.96, 26.61 15.28 C36.45 8.61, 56.83 1.86, 65.01 -0.27 C73.18 -2.39, 75.55 1.34, 75.65 2.51 M86.8 1.08 C96.43 2.68, 107.51 9.76, 115.37 16.7 C123.24 23.64, 130.21 33.31, 133.99 42.7 C137.78 52.09, 138.85 62.82, 138.11 73.04 C137.37 83.27, 133.99 94.87, 129.56 104.03 C125.14 113.2, 119.56 121.92, 111.55 128.05 C103.54 134.17, 91.44 139.17, 81.51 140.78 C71.58 142.4, 61.44 140.58, 51.97 137.73 C42.51 134.89, 32.52 130.11, 24.73 123.72 C16.95 117.33, 9.24 108.89, 5.28 99.38 C1.32 89.87, 0.34 76.83, 0.95 66.65 C1.55 56.47, 4.54 47.28, 8.91 38.3 C13.28 29.33, 19.39 18.91, 27.16 12.8 C34.92 6.68, 45.6 3.51, 55.51 1.62 C65.43 -0.28, 81.52 1.25, 86.64 1.42 C91.76 1.59, 86.13 1.47, 86.22 2.64"
    stroke-width="1"
    ></path>
</g>
<g stroke-linecap="round">
  <g transform="translate(144.5 103.5) rotate(0 148.60048447307202 92.8671882355213)">
    <path
      d="M-1.1 0.36 C48.42 31.32, 246.55 154.37, 296.08 185.15 M0.52 -0.5 C50.5 30.65, 248.65 155.18, 298.31 186.23"
      stroke-width="1"
      ></path>
  </g>
</g>

<g stroke-linecap="round">
  <g transform="translate(96.5 149.5) rotate(0 4.303626279905416 65.03650238673202)">
    <path
      d="M-0.87 -0.6 C0.68 20.83, 7.77 107.34, 9.48 129.09 M0.88 1.7 C2.2 23.29, 7.02 109.62, 8.25 130.67"
      stroke-width="1"
      ></path>
  </g>
</g>

<g stroke-linecap="round">
  <g transform="translate(139.5 406.5) rotate(0 89.83021834012123 91.4829672742635)">
    <path
      d="M-0.15 -1.03 C29.93 29.8, 151.28 153.22, 181.35 184 M-1.69 1.04 C28.19 31.64, 149.84 152.3, 180.58 182.4"
      stroke-width="1"
      ></path>
  </g>
</g>

<g stroke-linecap="round">
  <g transform="translate(515.5 407.5) rotate(0 57.04129605777564 66.19997333149428)">
    <path
      d="M-0.98 0.08 C18.17 22.19, 95.75 111.04, 115.06 133.32 M0.71 -0.92 C19.77 20.75, 95.69 109.25, 114.67 131.37"
      stroke-width="1"
      ></path>
  </g>
</g>

A visual example of a graph data structure.

To think about graphs in terms of code, we may write TypeScript that looks like this:

class Node {
  edges: Edge[] = [];
  data: string;
}

class Edge {
  previousNode: Node;
  nextNode?: Node;
}

Each node contains a list of its edges, and each edge contains a reference to the next/previous node. As we'll see in SQL later, the nodes don't always need to know about their edges.

Facebook is a popular social media platform that uses a graph to represent people and their relationships.
A person can have friends, and those friends also have their list of friends.
Each person is represented as a node, and each friendship would be represented as an edge.
Graphs are used to model a lot of different applications like your
npm dependencies,
workflows, transportation systems, manufacturing lines, and more!

Storing Graph Data Structures in Postgres

To store a graph in Postgres we only need to create two tables: nodes and edges.
The nodes table will store information about each entity, while the edges table will store information about the relationships between entities.

Let's start by creating a nodes table:

CREATE TABLE nodes (
  id SERIAL PRIMARY KEY,
  data VARCHAR(255)
);

The nodes table we defined here has two columns: id and data. The id column is an auto-incrementing integer that serves as the primary key for the table. The data column is a string that stores any extra data associated with the node.
For this example, we're keeping it simple and only storing a string column, but in real-world applications, this table could be anything and have any number of columns.

The most important table when creating a graph data structure is the edges table:

CREATE TABLE edges (
  previous_node INTEGER REFERENCES nodes(id),
  next_node INTEGER REFERENCES nodes(id),
  PRIMARY KEY (previous_node, next_node)
);

Here, we are creating two columns, previous_node and next_node, that represent our relationships between nodes.
Each of these columns represents a foreign key to a node. The important take away is an edges table references two rows in the same table.
An edge can only have one previous_node and next_node pairing, so we are using a composite primary key to ensure that each edge is unique and cannot reference itself.

With our tables created, we can now insert data into them.

INSERT INTO nodes (data) VALUES ('Bob');
INSERT INTO nodes (data) VALUES ('Hank');
INSERT INTO nodes (data) VALUES ('Jeff');

And then let's connect our nodes with edges:

INSERT INTO edges (previous_node, next_node) VALUES (1, 2);
INSERT INTO edges (previous_node, next_node) VALUES (1, 3);

nodes
id	data
1	Bob
2	Hank
3	Jeff

edges
previous_node	next_node
1	2
1	3

If we were to visualize our graph at this point, it would look like this:

![A graph representation of the SQL created above](./example-1.svg)

Querying Graph Data Structures in Postgres

With our graph data structure created, we can now query it using SQL we know and love!

Want to know who Bob is friends with?

SELECT id, data
FROM nodes
JOIN edges ON nodes.id = edges.next_node
WHERE edges.previous_node = 1;

Find all `nodes` connected to the node with `id` 1 (Bob's id).

Looks like Bob is popular! But what if we want to know who Bob's friends are friends with?

Let's insert a few more nodes and edges to show this:

INSERT INTO nodes (data) VALUES ('Sally');
INSERT INTO nodes (data) VALUES ('Sue');
INSERT INTO nodes (data) VALUES ('Sam');

INSERT INTO edges (previous_node, next_node) VALUES (2, 4);
INSERT INTO edges (previous_node, next_node) VALUES (3, 4);
INSERT INTO edges (previous_node, next_node) VALUES (4, 5);

nodes
id	data
1	Bob
2	Hank
3	Jeff
4	Sally
5	Sue
6	Sam

edges
previous_node	next_node
1	2
1	3
2	4
3	4
4	5

To query for all Bob’s friends of friends we could extend the previous query to join the edges table again, but that would cause a maintenance nightmare having to join on each “level” in the graph.

Postgres has a built-in feature that allows us to query graph data without having to know exactly how many joins we need: recursive queries. Recursive queries allow us to traverse the graph starting from a specific node and following its edges until some determined endpoint.

Writing a recursive query to find all Bob’s friends and their friends we would write the following SQL:

WITH RECURSIVE friend_of_friend AS (
  SELECT edges.next_node
  FROM edges
  WHERE edges.previous_node = 1
  UNION
  SELECT edges.next_node
  FROM edges
  JOIN friend_of_friend ON edges.previous_node = friend_of_friend.next_node
)
SELECT nodes.data
FROM nodes
JOIN friend_of_friend ON nodes.id = friend_of_friend.next_node;

This can be confusing at first glance, so let's break it down.
A recursive query is made up of two parts: the base case and the recursive case.
The base case is where we want to start our query.
The recursive case is the "loop" that will continue to run until some endpoint is reached.

WITH RECURSIVE {name} AS (
  {base case}
  UNION
  {recursive case}
)

The basic SQL structure of a recursive query.

In our example we want to start our query with Bob's friends, so we find the edges where Bob (id: 1) is the previous_node.
Then in the recursive case we continually join the edges table to itself until we reach the end of Bob's graph (eg. when we reach friend_of_friend.next_node = NULL).
Finally outside our recursive query we bring it all together. We need to query the nodes that are associated with the edges from the recursive query so we can get each of Bob's friends' names.

data
Hank
Jeff
Sally

Conclusion

By using features built into Postgres, we can store and query graph data structures.
We used a similar approach in my previous job to dynamically generate work instructions on a manufacturing line.
Based on parameters given, and rules defined on each edge, we could generate the correct document by traversing a graph stored entirely in Postgres.
If you are already using Postgres for your relational data, you can integrate graph data structures into your existing database without adding extra systems!

If you want to try the queries in this post against a populated table, the generate_series walkthrough covers how to spin up nodes and edges quickly. For more on the recursive CTE pattern used above, see Recursive Query in SQL: What It Is, and How to Write One.

Git Worktree: Enhance your Git Workflow

Fri, 10 Mar 2023 00:00:00 GMT

Have you ever found yourself in the middle of coding a feature, only to receive a notification that production is down? If you're using Git, you now have a few options: commit your work, stash your work, or discard your work.
Each of these options has its own set of problems, depending on the situation.
If you commit half-baked code, you may need to come back later and rebase to clean up your commit history.
Stashing can also cause problems. What if you need to stash extra code later before switching back to your original feature work?
As for me, I tend to throw away my current changes if they're small, but otherwise, I prefer not to.

Recently, I stumbled upon Git worktree, and it has been an amazing boost to my productivity.

What is Git Worktree?

Git worktree allows us to checkout multiple branches in a Git repository, enabling us to switch between different branches without losing our non-committed work.
Git achieves this by creating new, separate directories called "linked worktrees" that are associated with a single "main worktree" (the directory created using git clone or git init).

To checkout a new worktree, we use the git worktree add <path> <branch_name> command. Worktrees are created as new directories, with the add command taking a path argument to specify where to create the new directory, and a branch name argument to specify which Git branch to checkout.
We can create new branches by adding the -b argument, like this: git worktree add -b <branch_name> <path>.

We can view all the worktrees we've created using the git worktree list command.

With our different linked worktrees created, we can change code and switch between isolated instances of our codebase. The changes done in one worktree do not affect the other worktrees.

What about if we want to commit and push our changes out to Github? No problem! Git worktree is a way to checkout many branches.
So once we're done making changes in our worktree we can git add, git commit, and git push origin like if we are working on a different branch.
The changes would show up on Github under the <branch_name> we gave in git worktree add <path> <branch_name>.

When we are done with a worktree we can call git worktree remove <path_to_worktree> to delete it.

End

I keep all worktrees in a separate directory ~/.worktree, outside of my general projects directory ~/projects, to reduce clutter and keep "main worktrees" explicit from "linked worktrees".
I am constantly switching between branches and code, and Git worktree has been a huge help to my workflow!

Advice for New Software Engineers

Mon, 04 Jul 2022 00:00:00 GMT

A few months ago I had an opportunity to give a presentation to soon-to-be Computer Science (CS) graduates. We presented the software development process (SDLC), and how different teams at Schweitzer Engineering Laboratories adapt the development process to their needs. We ended the presentation with tips for what to expect entering the industry.
There is a big disconnect between what we learn while getting a CS degree and writing software that makes money. Not to say a CS degree isn't worth it; quite the opposite. I still use the algorithms, graph theory, data structures, and development processes taught in college. But, there is so much more to software engineering than code and theory. In this article we'll walk through the tips I would give myself leaving college, and the tips I gave to those soon-to-be CS graduates.

Don't worry about knowing everything

I've been programming a long time--I'm 1996 Space Jam websites old. I've contributed to many coding communities, built and maintained high-traffic applications with near-zero downtime, gave conference talks, released a course, and written a lot of these silly articles. If you were to pull me out of a crowd and ask me to invert a binary tree I would probably struggle. I've been rejected from many job interviews and called "not senior enough". The point is we all face rejection no matter how much we know, or how much experience we have. We can always be better. Don't fret about not knowing everything, and don't be afraid to say, "I don't know", but always follow up with, "But I'll find out". Throughout my four years getting a Computer Science degree I thought if I knew all the algorithms, and produced the fastest code I would be the best programmer. These things help, but after my first experience as a professional software engineer, I quickly learned there is so much more to software than Big O notation. It's not about knowing everything; it's being curious and able to figure it out.

Ask questions, have opinions

This piece of advice piggybacks "Don't worry about knowing everything", and adds some spice. Don't be afraid to ask questions. Ask the senior developer why they came to a certain solution, or how Map() is different than {} in JavaScript. This is a two-way street. When you become a senior software engineer ask the junior engineers questions. Remember, we can't know everything, but speak up when we do know something! Have opinions. Yeah, not every opinion will be correct, but this is how we learn. As a manager, I like when interns have opinions on architecture. This shows they care, they're engaged, and they're learning. Just don't be a jerk about it. Ask questions on the things you don't know, and have opinions on the things you do know!

Have a business-oriented mindset

We leave college with the wrong mindset of what companies look for. I thought software companies wanted the best software engineers because it makes them the best. Don't get me wrong, there is value in being good at writing software. Let's say we write a highly decoupled, blazing-fast, platform-agnostic, cleanest code application. If no one uses the application then all we did was create a waste of time and money pit. Great software engineers consider both technical and business needs. We need to think about how our decisions produce value. Switching frameworks may sound cool, but who gets the value out of that? If the old framework isn't maintained anymore, and we need to change to get security patch support then maybe it's worth switching frameworks. If we want to change frameworks, because we saw a post on Hacker News about it then maybe reconsider.

When I get asked how to get promoted and move up the software engineering ladder this is the biggest advice I can give. Consider how your skills produce value for your company. Same for writing a resume or interviewing. It's cool you know Haskell, but how does that transfer to producing value at the company you're being hired for? Maybe since you had to learn Haskell for a class you are a quick learner, and can onboard quickly?

Technology is a a means to an end. Our applications solve problems users have is the goal.

Everyone breaks production

You're going to break production. Everyone does it. Even that lead engineer you look up to who never does wrong has broke production at some point. Don't stress about if you're going to break production. Breathe in. Breathe out. Let it go.
A colleague, who did the talk with CS graduates with me, has a saying, "Optimize for mean to recovery." Find ways to reduce the blast radius once production is broken instead of worrying about breaking production in the first place. This could be:

Having battle buddies you can rely on when sh*t hits the fan. Find a support system who can jump in and help when production breaks
Learn everything about the environment. Ask questions not just about the systems you work on, but neighboring systems. How does each piece connect?
Improve your skills and learn different parts of the software stack. Learn how Databases work, maybe learn networking and DNS, and if you're working in containers maybe introduce yourself to Kubernetes

When interviewing for a company look for blameless cultures. This means when something eventually breaks in production the team doesn't start pointing fingers. Ask the interviewers how they deal with outages, and watch out for warning signs. Many buzzwords without any concrete plan/action can be a cause for concern.

Lastly, writing software is a team effort. When software breaks there are multiple chains in the process of breaking down. Maybe code reviews weren't as thorough as they could have been? Or maybe we're missing testing or test cases that would have caught the error? Did the Continuous Integration step run? Maybe the architecture is inherently complex? As engineers we like to point to a root cause (Fallacy of the single cause), but the Titanic didn't sink for one reason. The builders of the ship cut costs, the ship was moving too fast, and the ship's radio operator dismissed the warning (Pruitt, 2018). Find a team with a blameless culture and don't point fingers when systems fail. Iterate on failures to learn and get better. Software is a team pursuit.

References

Pruitt, S., 2018. _Why Did the Titanic Sink?_. [online] History. Available at: https://www.history.com/news/why-did-the-titanic-sink [Accessed 4 July 2022].

NPM: What are project dependencies?

Tue, 17 Aug 2021 00:00:00 GMT

Code dependencies are like Lego's. We are able to pull in other people's code, combining and stacking different packages together to achieve our goals. Using dependencies greatly reduces the complexity of developing software. We can take advantage of the hard work someone has already done to solve a problem so that we can continue building the projects we want. A development pipeline can have multiple kinds of code dependencies:

dependencies
developer dependencies (devDependencies)
peer dependencies (peerDependencies)

In JavaScript, we have a package.json file that holds metadata about our project. package.json can store things like our project name, the version of our project, and any dependencies our project has. Dependencies, devDependencies, and peerDependencies are properties that can be included in a package.json file.

{
    "dependencies": {
        ...
    },
    "devDependencies": {
        ...
    },
    "peerDependencies": {
        ...
    }
}

Production vs. Development

The type of dependency a package is changes depending on the instance where code will be used. Some packages are necessary for users to run our code. By "users", we refer to people who are not directly working in our code-base, such as those who interact with an application we wrote or a developer writing a separate library. In other words, these are packages that are required in a production environment. On the other hand, there are packages that are only needed by developers or systems while working in our code, such as linters, testing frameworks, and build tools. These are packages that users won't need, but developers or build systems will need.

Dependencies

Dependencies refer to packages that our project uses in production. They are essential for making our application run, as they are included with our code. Whenever we install a dependency, the package and any of its dependencies are downloaded onto our local hard drive. The more dependencies we add, the larger our production code becomes, since each new dependency is included in the production build of our code. It's important to evaluate whether new dependencies are truly needed before adding them, in order to minimize the size of our production code.

Dependencies are installed using npm install X or yarn add X

Examples of dependencies: React, stylized-components, jQuery

Dev Dependencies

Packages needed in development, or while developing our code, are considered dev dependencies. These are programs, libraries, and tools that assist in our development workflow. Dev dependencies also get downloaded to your local hard drive when installed, but the user will never see these dependencies. So adding a lot of dev dependencies only affects the initial yarn or npm install completion time.

Dev Dependencies are installed using npm install --save-dev X or yarn add --dev X

Examples of Dev Dependencies: Jest, ESLint, Webpack

Peer Dependencies

Peer dependencies are similar to dependencies except for a few key features. First, when installing a peer dependency it doesn't get added to your node_modules/ directory on your local hard drive. Why is that? Well, peer dependencies are dependencies that are needed in production, but we expect the user of our code to provide the package. The package doesn't get included in our code. This is to reduce including multiples of the same dependency in production. If every React library included a version of React as a dependency, then in production our users would download React multiple times. Peer dependencies are a tool for library owners to optimize their project size.

Peer Dependencies are installed using yarn add --peer X

Examples of Peer Dependencies: React, Bootstrap

End

I recently released a course, Creating React Libraries from Scratch, where we walk through deploying a React library from yarn init to yarn publish. Creating React Libraries from Scratch includes content just like this and more!

To learn more click the image below!

CSS Box Model

Sat, 24 Oct 2020 00:00:00 GMT

CSS is one of those technologies that has a low barrier to entry (good thing 🎉), but because of this sometimes how it works can seem like magic. It's easy to get started writing CSS, so we dive head first into it. Sometimes we smash our face into the concrete with frustration. Why won't my text move over yonder? Where did that scroll bar come from? How do I center this junk?

This is a series I'm starting called, "CSS: The Important Stuff". The goal is to take a dive into the mechanics of CSS so we can get a better intuition when styling and positioning elements. In part one we'll take a look at Box Model; the underlying layout of the web.

What is the Box Model?

It comes with great danger to myself to tell you that the web is made of boxes. Yes, it's boxes all the way down. Take a look at this website—open the Element Inspector in the browser's dev tools and add * { border: 1px solid red; }. Look at all those fine boxes.

The browser uses boxes to layout and render our websites. Within each box there are four properties: content, padding, border, and margin. Boxes are like onions, they have layers. Each property defines the size of our box (ie. width and height), styling, and how content around the box flows.

Content is what we're usually thinking of when we create HTML elements. Text, images, video, etc. This is at the center of the box
Padding gives space around the edges of the content. Separating the content from the border
Borders are used to separate boxes from each other—as seen in our red border example above
Margin is non-stylistic spacing around the box. This is useful to separate boxes from each other and position boxes

Why does this matter?

Dimensions

There are different ways to determine the width and height of a box. Is the box's dimensions determined by all its layers (margin, border, padding, content)? Or is it determined by the content?

The browser made a choice in box-sizing and the default is content-box. When we give our element a width and height, lets say .box { width: 100px; height: 100; } , the default behavior with content-box is to give the content layer the width and height of 100px. But, the box still has extra layers with padding and border. We would assume if we gave the element of 100px that it would be 100px, but the browser needs to add the values of padding and border on top of the content to get its "rendered dimensions".

Given the styling on our moon icon below, what would you expect the width and height to be on the box?

.moon {
  box-sizing: content-box;
  width: 100px;
  height: 100px;
  padding: 10px;
  border: 1px solid #FFF;
}

That's easy it's 100px... wait, 122px, what? How did we get 122px? Remember when we gave the width and height of 100px it only applies to the content layer. We also applied a padding of 10px on each side of the box and a 1px border around it. If we were to calculate the width of the box, we start with 100px, add 10px for the left padding, add 10px for the right padding, add 1px for the left border, and finally 1px for the right border.

$$
100px + 10px + 10px + 1px + 1px = 122px
$$

Seems a little counter intuitive—if I set my box to have a 100px width then it should be 100px darn-it! Luckily, there are more ways for the browser to calculate a box's size. When I think of the size of a box, I think of border-box . Think of the layers of a box, and when assigning box-sizing think of the value as being cascading. When an element has content-box that means the browser determines the size of a box starting from content and adding any child layers. Since there are no children to content width/height only applies to content. When using border-box, width/height is set for the border, padding, and content.

Let's take a look at the same moon icon, but apply border-box instead.

.moon {
  box-sizing: border-box;
  width: 100px;
  height: 100px;
  padding: 10px;
  border: 1px solid #FFF;
}

What we see is something quite different, the width and height of the moon is now a hard 100x100. This isn't magic though, the missing dimensions have to come from somewhere. Using border-box the content layer gets shrunk to make room for padding and border. With content-box our width was guaranteed to be 100px, but what is the width of our content now with border-box?

$$
100px - 10px - 10px - 1px - 1px = 78px
$$

To me border-box is easier to intuit and reason around, and becomes my default, but if the width and height of the content matters more than the visible box itself, use content-box.

References

Start With No

Sun, 13 Sep 2020 00:00:00 GMT

Our default response to any idea that comes up should be: “Interesting. Maybe some day.” In other words, a very soft “no” that leaves all our options open. We don’t put it in a backlog. We give it space so we can learn whether it’s really important and what it might entail.

_{"Shape Up" - Ryan Singer (Basecamp)}

Here's a story: At a previous employer, I had a boss who I thought was pretty tough. Not to me, but to our users. No matter the request, his response was always the same: "No." Eventually, we implemented around 40% of the requests, but the constant rejection of these requests stuck with me. Now that I lead a team, I notice myself using the same mindset. "No" isn't negative, and it's not dismissive. "No" is a way of protecting the team, the project, and the users.

No?

There is a natural progression to projects that looks something like this: first, the honeymoon phase. The pastures are green; the project has no technical debt, and every feature is a great idea. As we add functionality, our user base grows. If we're lucky enough to get traction, we move to phase two: the monolith. Our application now handles a bunch of use-cases. It does your taxes, picks up your dog's poop, and reminds you to call your mom. Only power users can fully grasp the purpose of the application. The technical debt is increasing with every new feature added. Finally, we get to the last phase. The application has become so bloated that it's hard to develop new features. New users aren't willing to learn the ins-and-outs of the product. A new startup comes around with a trimmed-down version of your application. It's so easy to use! Around this time, users are jumping ship.

Saying "no" is a buffer in our development process. It gives us, the developer, time to think of an optimal solution. Could a feature being asked for be solved in a way that satisfies multiple feature requests? Is there some domain logic we have yet to understand? Does the feature really make sense in this application? All these questions help reduce the lifecycle described above. It reduces feature churn by keeping the application simple and by solving issues the users actually have.

Be mindful of how features interact within your application. Nothing comes without a cost—especially in software development.

No.

"No" is a way of protecting people—the users and the development team. There is a gradient of experience when it comes to using your application. Users will be complete beginners, and others will be power users. As a product owner, we need to balance these two extremes. If the application is too power-user-centric, then it's harder for new users to grasp. When the application is too hand-holding, power users become frustrated. Saying "no" to one extreme is a way of keeping the scales balanced. But be mindful of what you say "no" to. Some features may be vital to the application's success. This is part of the art.

"No" gives time to find the optimal solution to a problem. Users ask for a solution to X and suggest implementing Y, but what they really need is K. Feature requests give us an opportunity to improve processes and workflows. Our users are domain experts but are prone to doing things the way they've "always done them." We can come in and find ways to simplify. Ask the user, "do we really need this step?" or "Could the system handle that instead of a person?" Once code is written and users get accustomed to the feature, it's really hard to change. Do this step upfront.

"No" keeps the development team doing meaningful work. Spending a sprint or two implementing a feature nobody uses or finds frustrating is demoralizing. Think about the workflow before writing any code. Question the feature and the users. Does the application need this? Could we implement it in a simple way? Reduce code churn; reduce developer churn.

No!

Work needs to get done. At some point, you need to say "yes," but instead of taking on every task, you get to be mindful of what to prioritize. You get to take on the tasks that add the most business value and delight users. Use "no" as a tool.

Making React Fast: Tips on Optimizing ReactJS

Tue, 04 Feb 2020 00:00:00 GMT

import { Image } from "astro:assets";
import htmlDiagramImage from "./html-diagram.svg?url";
import reactRenderingImage from "./react-rendering.svg?url";

React does a fantastic job abstracting away the rendering of webpages. When state changes, our UI's reflect it. But, have you ever gotten done writing your application just to notice things seem off? Clicking a button displaying a popover stutters for a second, or animations don't run smoothly.
With React being just a view layer there is a single bottleneck causing "jank" (stuttering in the interaction)... Rendering. If our applications never had to render they'd all be blazing fast running at millions of frames per second (I had top scientists run the numbers)!
Fortunately we don't live in that world. Our applications are useful--they render and then re-render.

The majority of devices have screens refreshing 60 times a second. Our applications have a short time-frame to update, render, and interact with users. According to Google all work needs to be completed within 10ms. Yes you read that right, 10ms. A daunting task. React gives us a lot of tools to take on this challenge. Let's take a look at a few of these.

The DOM Tree

Before moving onto improving React we need to take a step back. We need to get a few foundational ideas out of the way. The universal data structure of the internet is the Tree. HTML is built off of it.
If we consider the following HTML:

<div>
  <span>Hello</span>
  <p>World</p>
</div>

Then the data structure representation would look like:

React takes the same DOM (Document Object Model.. ie. HTML) tree structure, and mirrors it in memory--called the Virtual DOM. Kind of like how a cache is to I/O, the Virtual DOM is to the DOM Tree. It's faster to perform CRUD operations (Create, Read, Update, Delete) in the Virtual DOM. The browser performs massive amounts of work when the DOM Tree is changed: painting, layout, calculations, etc. The Virtual DOM is only a representation of the DOM in memory, so things like painting and layout don't need to be calculated. It's easier to perform many changes to the Virtual DOM then commit the final result, than it is to perform each change to the browser's DOM tree.

When thinking to optimizing React, think of the Virtual and browser's DOM Tree. The less work each of these structures have to perform, the faster our applications behave!

What causes React to render?

There are two main reasons for components to render in React: when a component's state changes, or when its props change. Out of the box React chooses the naive approach in deciding what needs re-rendered. Re-render the element, and any of its children nodes, every time the props/state changes. For example in the figure below, say we change the state of node 2. All elements contained within the dashed line would also be re-rendered.

Don't take this as a bad thing! React cannot make any preconceived assumptions on how our application functions, so it chooses the most user friendly approach. It would instead be frustrating if we updated our application with a logged-in user prop, and the MenuBar component six layers deep didn't reflect this change.

shouldComponentUpdate()

Every (class-based) React component has a shouldComponentUpdate() method which returns a boolean. It does exactly what the name suggests, returns true if the component should render on prop/state changes, or false if it shouldn't. Remember how we said a component always updates on prop/state changes? By default each component's shouldComponentUpdate() looks like:

shouldComponentUpdate() {
  return true;
}

Yup, on every update the component re-renders! But, what if we only wanted a component to update when certain props change? React will first call shouldComponentUpdate(), then move to updating the component if true is returned. shouldComponentUpdate() takes two parameters: the next props and the next state. We could calculate any number of scenarios to optimize our application. Consider,

shouldComponentUpdate(nextProps, nextState) {
  if (!this.props.isOpen && nextProps.isOpen) {
    return true;
  }

  return this.state.textInput === nextState.textInput;
}

This is great for components with a few props and state, but as components grow so do the need to check every prop and state. There has to be an easier way, right? Stay tuned!

PureComponent/Memo

Let's start with memoization... what is it? Why do we care?

Think of when a function receives arguments, like add(1, 2). Given the same inputs we can assume that we'll receive the same output (from our add example, the output is always 3). Let's also assume we have bad code and add(a, b) is a function that performs a bunch of computation. On average it takes three seconds to complete. After running the add(1, 2) function once we already know it outputs 3, so why should we waste additional time computing the output? Memoization is the act of caching, or storing, the result of a function call and returning the cached result on future requests.

In the same way, memoization is also utilized within React to prevent having to compute expensive renders (computations) over and over again.

Remember our friend shouldComponentUpdate()? We can achieve the same effect with PureComponent. Generally, our class-based React components will look like:

class MyComponent extends React.Component {
  ....
}

But, for extra optimization goodness we can replace React.Component with React.PureComponent.

class MyComponent extends React.PureComponent {
  ....
}

These two classes differ in their implementation of shouldComponentUpdate(). React.Component's shouldComponentUpdate() will always return true unless we override it (ie. always re-render on update). React.PureComponent has its own implementation of shouldComponentUpdate() which automatically performs a shallow comparison of all the component's props and state. If any of the new props the component receives are changed, then return true. Otherwise, it will return false (ie. not triggering a re-render, and returning the previously calculated render of the component).

Up until this point we've only talked about class-based components. You may be asking yourself, "Fine, but what about function components?" Since our goal is to 'cache' the output of a function component, React gives us a handy utility for memoizing our function components... React.memo! This works similarly to React.PureComponent in class-based components. If the component receives new props/state it re-renders. Otherwise, return the computed output from before.

function MyComponent(props) {
  ...
}

export React.memo(MyComponent);

Warning: Don't get React.memo() confused with React.useMemo(). These are different, and used in different ways!

Hooks (useMemo, useCallback)

I won't specifically go over how hooks work in this section. For an introduction, check out the infinitely better documentation from the official website. Instead, we'll be checking out two hooks that help us improve the rendering speed of our applications.

useMemo() is useful for 'caching' the results of a computationally expensive expression which returns a value. For example,

function MyComponent(props) {
  const result = React.useMemo(() => JSON.parse(props.value), [props.value]); // highlight-line

  ...
}

We provide useMemo() a second argument, which says whenever the value changes (props.value), rerun the function provided in the first argument. This makes it so values only get recalculated when they change.

useCallback() instead returns a 'cached' version of a function.

function MyComponent(props) {
  /* highlight-range{1-3} */
  const handleClick = React.useCallback((event) => {
    console.log(event);
  }, []);

  ...
}

Instead of rebuilding the function on every render, useCallback() calculates a function only when needed.

Extracting Components

Large components are hard to maintain. To make our components easier to manage we may break them up into smaller, easier to manage pieces. Great! We achieved clean code! But, splitting components into smaller chunks also makes it easier to optimize computational heavy code. Its hard to optimize certain aspects of a gigantic component. In React either the whole component re-renders, or it doesn't. If components are broken down, using the techniques mentioned above (memo, pureComponent, and shouldComponentUpdate) become really powerful. We can isolate the bottlenecks in our applications and optimize.

End

There is a tradeoff in optimization. Memoized components create more memory that needs to be stored (ie. the output being cached). Also, there are additional computations needed in figuring out when and when not to re-render. Don't prematurely optimize. Run performance tests when you can, and optimize the pieces of your code that really need it!

Music That Defined My Decade: 2010-2019

Sun, 29 Dec 2019 00:00:00 GMT

This is an attempt at a different kind of post. Something less technical. Something more personal. I'm a pretty big music fan, and I'm always scrounging around the internet for new artists and songs to fill my Spotify portfolio. One of my biggest fears is being that 50 year old dude who still only listens to those same two Def Leppard songs. Mullet optional.

Just to be clear, this isn't a list of the best albums/songs/whatever in the last decade--though I think they're pretty dope--but an anthology of nostalgia from the last ten years. Some songs are associated with life events, which I'll go in to. Others, just cool songs. For myself this is a journal. Maybe for the reader, a novelty to find new music.

To give some context, when 2010 reared its head I had just turned 17. Still in high school! I had just became an uncle, and my favorite artists were The White Stripes and The Red Hot Chili Peppers. A big change from Blink-182 and My Chemical Romance from years before (we all listened to it, don't judge). This was all fueled by that drunk next door neighbor who knew all the cool bands. It was around this time that I had been playing guitar for a few years. Playing in a band was the natural progression. We played all the covers: Iron Man, Smoke on the Water, and Crazy Train. This was short lived--we wanted music that related to us.

Wavelets split w/ Senders

Really, I don't remember how I ever stumbled across The Wavelets. What I do remember is that I found them on MySpace. The second I heard the intro lick to Let Off Some Steam I was instantly hooked. It wasn't grandpa's music. The sound coming from my speakers was raw in every sense of the word. The recording quality, vocals, lyrics, instruments. Despite that the lyrics were relatable, the guitar was all over the place, and it was a sound I never heard before. It was Let Off Some Steam that made me do a 180, and completely changed the music I was into. The Wavelets eventually stopped playing, and a few of the members created a new band, Dikembe, which hold some of my favorite songs of all time. Though they had a short discography, The Wavelets are the pioneers to the rest of this list. The home base. I've been playing music for close to ten years, and I'm still trying to recreate my own version of Let Off Some Steam.

Split w/ Senders by wavelets

This Town Needs Guns (TTNG) and Moving Mountains

I'm grouping these two bands, because they came around the same time. Though, totally different in sound, they equally expanded my musical pallette in different ways. These bands pushed me further off course. It started with rawness, The Wavelets, then got more mature with TTNG and Moving Mountains. A lot of the experiences I had in this decade can be equated to these three bands. The people I met, the places I got to travel to.

We'll start with Moving Mountains...

Moving Mountains

Pneuma, the first album from Moving Mountains, is a whirlwind of an album. Its loud and in your face, but also soft and melodic. The first song I heard from this band is 8105. It was completely different than other songs. First, it was freaking 8 minutes long! Second, it didn't follow the classic song writing structure. There is no verse, chorus, verse chorus... Just one long linear story. 8105 taught me to experiment, try radical new sonic escapes, and got me into the genre Postrock.

Pneuma by Moving Mountains

TTNG

TTNG is a different beast. Ever heard of Math Rock? No, it's not songs about multiplication tables. Math Rock is a style of music that fluctuates in time signatures. It can almost sound disjointed. But, TTNG with their song 26 is Dancier Than 4 is not just a crazy time signature free-for-all with guitars and drums flying everywhere. It's beautiful. Just listen to that outro! TTNG got me into the exocentric side of music and at the same time, the twinkly "pretty" stuff. Most bands I've played in, or played with have been categorized as "Math Rock". It has almost became a label for me now.

This Town Needs Guns by TTNG

The Appleseed Cast

I have a weird love/hate with The Appleseed Cast. Their music isn't bad--in fact it's amazing. Do you ever have one of those bands or songs that remind you of a time in your life? The Appleseed Cast is one of those bands. Around the time their album Illumination Ritual came out I had been hanging out with a girl I really liked. She liked me. But, depression and anxiety was running rampant. I went into a spiral--pushing everyone away (spoiler, this happens a few more times for different reasons). You know, college stuff where we really don't know what we want in life and what we're doing. What was the result? A year lost to isolation and drinking a lot. Spring came and I began to hike after class everyday. A mile. Then more. The Liberty Lake Loop was my favorite coming in at around 8 miles round-trip. My classes ended at 11am. I was generally done with the hike around 5pm. The whole hike I would listen to The Appleseed Cast's latest album over-and-over again, on repeat, for the full 8 miles, every time. The Appleseed Cast will always be associated to the time I went into that abyss, and found my way out. The good and the bad.

The Hotelier

Before I was even done with college I got a job offer for my dream job. Ever since six years old I wanted to work in the games industry. Here it was, I got an offer to be a programmer for Playstation in San Diego, CA. The experience was amazing--it was everything I would of wanted. Would.. Here I was in a totally new city. Everyday after work I would go home, and isolate myself. Stare at the walls of my 500 square foot apartment until I fell asleep. Then back to work. I had went from playing gigs every weekend and hanging with friends all the time to nothing. There was no future. To throw fuel on the fire, my dog got cancer. Then a second one did (we had three dogs). And a close grandparent started to show signs of Alzheimer's. Fuck! This is my life when The Hotelier's album Goodness came out. I would walk around a nearby lake, Lake Miramar, and listen the heck out of this album. Something about Goodness always lifted me up. It made me hopeful that even though I had achieved what I had always wanted to do, someday I would be back in my town playing my old crappy songs with the people closest to me.

When this began.
This was a thing.
That we could both share.
A bit of shade.
The goodness fades.
And we begin there.

End

Now there are probably hundreds, if not thousands of songs that could put on here. But, this is the music that stood out. That mean the most to me. Think of it as my most memorable five songs of the decade--without the clickbait. What would your top five songs be of the decade? What songs mean the most to you?

Lost Connections: Why You’re Depressed and How to Find Hope

Sun, 01 Dec 2019 00:00:00 GMT

You need your nausea. It is a message. It will tell us what is wrong with you.

Lost Connections is a challenge to the classic story any of us with depression and anxiety have heard. Go to a doctor. Get anti-depression pills. Become normal. Johann doesn't completely remove that fact that medical anti-depressants work, they do; just for a smaller subset of humans than is currently being prescribed. We live in the loneliest age. The internet has made us shelter away from society. During a study participants were asked, "In a crisis, how many close friends could you call?" Years ago the most common answer was five. Today it is none. In Lost Connections, Johann travels across the world to talk to leading psychologists and researchers to figure out the leading causes for depression and anxiety. He came across nine symptoms that may be the leading factors for making us (society) depressed and anxious.

Disconnection from Meaningful Work

For many of us, work is 8 hours a week day--1/4^th of the day. It's no wonder that a lack of autonomy in our jobs, and a lack of real purpose causes depression. Johann mentions that between 2011 and 2012, a polling company Gallup studied millions of workers across 142 countries. They found 13 percent of workers said they were "engaged." 63 percent said they were "not engaged." And finally the remaining 24 percent were "actively disengaged." Which means these workers were not only unhappy with their job, but actively acting out against the other employees and company.

Disconnection from Other People

As we dive head first into social media, the disconnection from humans grows. We no longer have real connections. Physical face-to-face connections. Johann talks of an experiment performed at Berkley by two professors. Groups from four countries were asked to put conscious effort into making themselves happier--The United States, Russia, Taiwan, and Japan. What they found is the group from the west (USA) didn't get any happier. Groups from the east (Russia, Taiwan, Japan) did. Why is that? Western countries tend to be more individualistic. You'll be happier if you buy that car, or get a promotion--build up the ego. The East instead looks at the group. How can I contribute to the community? They instead ignore the ego, and push to connect with other people.

Disconnection from Meaningful Values

Just as we have shifted en masse from eating food to eating junk food [...] we have shifted from having meaningful values to having junk values.

This chapter describes the shift in our culture from intrinsic values to extrinsic values (ie. trying to learn the piano, because we love it vs. learning the piano is impress others). Society has started to push "junk values" (extrinsic) as a solution to happiness. Studies have shown the opposite. An American psychologist, Tim Kasser, gives four reasons why extrinsic values make us feel bad.

Thinking extrinsically poisons your relationships with other people
The ego shrinks while performing intrinsic values. Extrinsic does the opposite. Intrinsic activities produces more flow states than extrinsic activities
Extrinsic thinking keeps us wondering, "How are people judging me?" It's an infinite game. Once we become rich, we want to become richer. "Materialism leaves you constantly vulnerable to a world beyond your control"
We all have innate needs--to feel connected, valued, secure, a feeling we're making a difference in the world. Extrinsic values chases a way of life that does a bad job of meeting these needs

Disconnection from Childhood Trauma

Dr. Vincent Felitti was tasked with investigating Kaiser Permanete's, a not-for-profit medical provider, fastest-growing cost--obesity. He thought, what if we try a radical diet. Have people not eat anything, and then provide them with the required nutrients to stay alive. It worked. Vincent saw amazing results. One woman, Susan, went from 408 pounds to 132 pounds. But, there was a problem. After his patients lost the weight they became depressed, anxious, and even suicidal. Susan gained back 37 pounds in three weeks. Vincent asked her what has changed since losing the weight. She thought. When Susan was obese men never looks at her, but once she got to a healthy weight a colleague asked her out. Vincent was curious, when did she initially start to gain weight? Eleven, when Susan's grandfather began to rape her. "Overweight is overlooked, and that's the way I need to be."

Disconnection from Status and Respect

Many of us would expect status and respect to be linked to depression and anxiety. The lower we are on the social totem pole the more depressed we should be, right? It was found in baboons that even the alpha, the top dog, shows high degrees on depression and anxiety also. They are constantly being challenged for the perks of leader. A constant threat of displacement. Which in time, happens to all baboons when they grow old.

Two social scientists studied the same behavior in humans. What they found is the wider the gap between the poor and rich, the higher the society suffers from depression and anxiety. "When the status gap is too big, it creates a sense of defeat that you can't escape from." Today, more than any other time, we have a much wider status gap. "The six heirs to the Walmart fortune own more [wealth] than the bottom 100 million Americans."

Disconnection from the Natural World

Just go outside, damnit.

Disconnection from a Hopeful or Secure Future

Depression causes a shrinking of the future. A fog. People with depression can barely get through the day, let alone see a possible future. So any possibility of a tomorrow becomes less and less visible. This myopia ensures further depression. Without the availability of a secure future an individual gets thrown into a downwards spiral. Depression is a negative feedback loop.

The Role of Genes and Brain Changes

A group of scientists lead by Avshalom Caspi did the most detailed study of genetic based causes of depression. They found a gene, 5-HTT, that does relate having depression. "If you have a particular flavor of 5-HTT, you have a greatly increased risk of depression, but only is a certain environment." So certain genes make us more vulnerable to depression and anxiety, but it doesn't condemn us. Neuroplasticity also plays a role in depression. Our brains are constantly changing, growing, and killing off unused synapses. Just because we are depressed, doesn't mean we'll always be.

Thoughts and Conclusion

"You need your nausea. It is a message. It will tell us what is wrong with you." This is what a doctor told Johann after he ate an apple, coated with pesticides, causing him to almost die. If the doctor just prescribed nausea medication, then Johann would of surely died. It was a symptom, not the illness. Johann describes depression and anxiety exactly in the same terms. We feel terrible, because we need meaning in our lives, we need nature, and we need other people. It's a mourning for natural humanistic needs.

Lost Connections is an interesting take on the concept of non-chemical anti-depressants, and the ailments of modern society.

How Facebook Avoids Ad Blockers

Sun, 24 Nov 2019 00:00:00 GMT

Many sites try to avoid our ad blockers through limiting content or just straight out pleaing. Other companies are looking at encrypting any kind of indicator that screams "AD!" through obfuscation and other fancy techniques--confusing ad blockers. Here we'll look at some interesting techniques Facebook deploys to ensure we view their ads.

What does a Facebook ad look like?

Facebook ads take the form of a card containing the text 'Sponsored' (as shown below).

At first glance blocking these ads seems simple. Look for elements with the text containing 'Sponsored'. Maybe even look at the class names to be more specific. Then, slap on a good-ol' display: none;. Hold up cowboy--it's a little bit more complex than that!

First, Facebook doesn't actually have 'Sponsored' in their HTML. At least, not together as we would think. In the DOM, 'Sponsored' is actually broken up character by character.

Instead of:

<span>Sponsored</span>

In Facebook it (kinda) looks like:

<span>
  <span>S</span>
  <span>p</span>
  <span>o</span>
  <span>n</span>
  <span>s</span>
  <span>o</span>
  <span>r</span>
  <span>e</span>
  <span>d</span>
</span>

Notice the 'kinda' above? Facebook actually doesn't put the text directly in the DOM. Instead, it's embeded in data attributes.

So really it looks like:

<span>
  <span data-content="S"></span>
  <span data-content="p"></span>
  <span data-content="o"></span>
  <span data-content="n"></span>
  <span data-content="s"></span>
  <span data-content="o"></span>
  <span data-content="r"></span>
  <span data-content="e"></span>
  <span data-content="d"></span>
</span>

Obfuscation

This kind of structure seems relatively easy to block. It can even be achieved in a few lines of CSS. We'll write a quick CSS ad blocker! It'll look for a sequence of 'Sponsored' as data attributes, then hide it.

span[data-content="S"]
  + span[data-content="p"]
  + span[data-content="o"]
  + span[data-content="n"]
  + span[data-content="s"]
  + span[data-content="o"]
  + span[data-content="r"]
  + span[data-content="e"]
  + span[data-content="d"] {
  display: none;
}

What's the catch? Well... I'm glad you asked!
To block against this simple ad blocker, Facebook deploys a few techniques.

First, I simplified the true structure of how the 'Sponsored' text is displayed. Remember how Facebook uses data attributes? Well, those span's are actually nested. This is to prevent the adjacency modifier seen in our CSS example +

<span>
  <span>
    <span data-content="S"></span>
  </span>
  <span>
    <span data-content="p"></span>
  </span>
  <span>
    <span data-content="o"></span>
  </span>
  <span>
    <span data-content="n"></span>
  </span>
  <span>
    <span data-content="s"></span>
  </span>
  <span>
    <span data-content="o"></span>
  </span>
  <span>
    <span data-content="r"></span>
  </span>
  <span>
    <span data-content="e"></span>
  </span>
  <span>
    <span data-content="d"></span>
  </span>
</span>

But, this doesn't completely ruin our CSS ad blocker. We can refer to the parent of the data attribute and drill down.

span
  span[data-content="S"]
  + span
  span[data-content="p"]
  + span
  span[data-content="o"]
  + span
  span[data-content="n"]
  + span
  span[data-content="s"]
  + span
  span[data-content="o"]
  + span
  span[data-content="r"]
  + span
  span[data-content="e"]
  + span
  span[data-content="d"] {
  display: none;
}

The next technique, this is the point where it gets particularly interesting, Facebook actually hides 'dummy' DOM nodes between the 'Sponsored' text. These values are entirely random characters, with a random number of DOM nodes between them. Invisible characters.

At this point our CSS ad blocker is completely broken. There is no way for us to possibly code every possible value in CSS. Ugh.

We could try playing around with ids or class names, but these are pretty generic. A lot of content within the Facebook code share similar classes, so there is no unique identifier in finding an ad.

End

We've looked at a few techniques Facebook deploys to prevent ad blockers from... blocking ads. Using data attributes instead of straight text in the DOM, nesting DOM elements to make DOM parsing more difficult, and adding random DOM nodes between characters to obfuscate the output. The next time an ad blocker doesn't completely remove all the ads on a site, try looking at the DOM. There may be some interesting techniques at play to keep the ads flowing through!

On Writing Clean Code

Sun, 21 Jul 2019 00:00:00 GMT

We can all agree that writing clean code is important. It makes it easier to work in a team, and even if we're a single developer, clean code keeps our future selves happy. Ever look at your old code and wonder, "What is this crap?" If you said "no", write more code--the feeling will come. For those who said "yes", let's look at some techniques that will improve your code readability.

Use Good Names

Coming up with good names is hard, but anything is better than using 'foo'. When creating names use something descriptive: what does the variable hold? what is the purpose of that function? Remember, we write code for humans to read!

Without context of your code it's hard to say, "this is what you should be naming things", but there are a few guidelines we can use when choosing names.

Booleans

Booleans are used to split code into two paths (true/false.. yes/no). When naming booleans, it helps to ask a question. For example, we might have some code that looks like:

let content = false;

if (content) {
  ...
}

This is ok, but it really doesn't give any context of what content is. While naming booleans, prefix it with is, are, should, has, etc... Just something that makes the variable asking a question.

let hasContent = true;

if (hasContent) {
  ...
}

Lists/Arrays

Make lists/arrays plural--they can hold multiple values so reflect it in the naming!

let salesOrder = []; // :(
let salesOrderList = []; // :|
let salesOrders = []; // :D Yay!

Don't be afraid of going long

Sometimes a single word doesn't explicitly explain what a piece of code does. As in what a function is supposed to do, or what a variable contains. It's perfectly fine to name something with a sentence, just watch out if we start naming our variables with paragraphs

function doStuff() { ... } // Bad!

function getSalesOrder() { ... } // Better!

function getSalesOrderByLineId() { ... } // Even Better!

function getSalesOrderByItemIdInTheDatabaseThenValidateReturnObject() { ... } // What? Bad!

Let the type-checker do its thing

This mostly applies to programming languages that have type checking. Using the example above with the variable name salesOrderList, don't specify the type of a variable in the name. The type-checker already gives us this information. Switching languages (slightly), let's see an example of this in Typescript.

let salesOrderList: SalesOrder[] = []; // We already know the type!
let salesOrders: SalesOrder[] = []; // Better!

let nameString = "Name"; // :(
let name = "Name"; // :D

Use the features of the language

Aside from taking advantage of a type-checker. Look at making good use of a programming language's other grouping features! What I mean by 'grouping features' are things like class and namespace. There is generally no need to repeat the names of a namespace in a class. Similarly, the same can be applied to repeating class names in a method.

/* It's easy to get lost what's going on. (SalesOrder.SalesOrder.SalesOrder(...)) */
namespace SalesOrder {
  class SalesOrder {
    function SalesOrder() {
      ...
    }
  }
}

/*
 * Following our naming structure, it's extremely easy to figure out what's going on
 * while not repeating ourselves.
 * (Repositories.SalesOrder.GetById(...))
 */
namespace Repositories {
  class SalesOrder {
    function GetById() {
      ...
    }
  }
}

/*
 * This is also perfectly fine, as namespaces generally get include/using/import 'd away
 * to not be seen.
 * (SalesOrderRepository.GetById(...))
 */
namespace Repositories {
  class SalesOrderRepository {
    function GetById() {
      ...
    }
  }
}

Whitespace

No, this isn't tabs vs. spaces. Pick one, then roll with it. What I mean by whitespace is that consistent line-breaks and whitespace between statements of code is extremely valuable. Just like we break logical sections of code into classes/functions/files/etc, we should also separate explicit blocks of code with whitespace.

// Anyone else going cross-eyed? Remember, write code for humans!
function add(a, b) {
  return a + b;
}
function doStuff(a, b) {
  let j = add(a, b);
  if (j > 2) {
    j = 5;
  } else {
    return a;
  }
  for (let i = 0; i < 20; i++) {
    j += i;
  }
  return j;
}

// Much better! Statements are separated by new-lines to give context,
// and makes it a lot easier to read!
function add(a, b) {
  return a + b;
}

function doStuff(a, b) {
  let j = a + b;

  if (j > 2) {
    j = 5;
  } else {
    return a;
  }

  for (let i = 0; i < 20; i++) {
    j += i;
  }

  return j;
}

To sum it up, leave atleast one blank line before and after:

if/else statements
for/while loops
functions/methods/classes/namespaces

and one blank line before:

return statements at the end of functions

Functions/Methods

We can take a lot of useful ideas from functional programming (I give an introduction of function programming here!) when it comes to writing clean code. Let's look at one of these ideas from the functional programming paradigm.

Only do one thing!

Functions/Methods should only do one thing. Living up to this philosophy makes testing functions easier, swapping functions or other functions trivial, and debugging a breeze!

While naming our function, we are good programmers and give a good descriptive name. But, there are a few dead give aways that a function is doing more work than it should if we see or or and in the name.

// Common occurance of OR!
function updateOrCreate() {
  ...
}

// Better!
function update() {
  ...
}

function create() {
  ...
}

Don't just avoid or or and while naming functions--be honest with yourself! It'll help with keeping your code more maintainable!

Finally,

Be Consistent!

The biggest aspect of writing clean code, even if you end up not using any of the styles above, is to be consistent! Keeping you and your team's coding style the same makes it easier to get up to speed with current projects, and any future endeavors.

Leveling Up Your Terminal/Command-Line Navigation

Mon, 17 Jun 2019 00:00:00 GMT

One motivating factor in using a terminal is the productivity gains... that is, once you can sweep the keyboard like an 80's metal guitarist. Getting a few basic keyboard shortcuts/commands down can drastically improve the usability of the terminal. Let's take a look at a few of my favorites.

(I'll be showing off Git Bash in this article, but these commands work in most terminals)

Movement

Move to the end of the input
ctrl + e

Move to the beginning of the input
ctrl + a

Move between each 'word'
ctrl + [arrow left/right]

Deleting

Delete backwards a whole 'word'
ctrl + w

Delete everything
ctrl + u

Open File Explorer

Opening the file explorer at the current location can be super useful. The command varies based on operating system.

(Open file explorer at the current directory. Change '.' to be any location!)

Windows: explorer .
Unix/MacOS: open .

History

Rerun the last command
!!

Get the full history of commands
history

Rerun command from the History
![#number]

End

These are shortcuts/commands I find myself going to daily that make the terminal a pleasure to deal with. Are there any I missed that you love? Let us know in the comments!

Intro to Functional Programming

Sun, 31 Mar 2019 00:00:00 GMT

This post comes from an example I presented at Boise Code Camp 2019 comparing imperative and functional ways of solving problems. The goal was not to teach functional programming in its entirety, but introduce a different way of thinking that is outside of traditional approaches (loops, mutation, etc). Having a different frame of reference adds more tools to the toolbox when faced with a problem.

The foundation of functional programming can be presented in three main ideas:

Immutable Data Structures
Pure Functions
First Class Functions

Let's go quickly into what each of these bullets mean.

Immutable Data Structures

When working in a programming language like JavaScript, we can assign data to variables let myVariable = 5;. But, nothing stops up from reassigning the variable to something else later on myVariable = "Now I'm a string.". This can be dangerous--maybe another function relies on myVariable to be a number, or what if some asynchronous functions are both working on myVariable at the same time! We could run into merge conflicts.

Example

const obj = {
  a: 1,
  b: 2,
};

function addOne(input) {
  return {
    a: input.a + 1,
    b: input.b + 1,
  };
}

const newObj = addOne(obj);

newObj === obj; // false

Pure Functions

Pure functions are side effect free. What does that mean? Well, a function that calculates an output based solely on it's input can be considered a pure function. If our function takes an input, performs a database update, then returns a value, then we contain a side effect in our code--updating the database. Calling the function multiple times might not always return the same result (out of memory, database is locked, etc). Having pure functions is crucial in helping us write bug-free, easily testable code.

Example

function notPureAdd(a, b) {
  return a + new Date().getMilliseconds();
}

function pureAdd(a, b) {
  return a + b;
}

First Class Functions

The term First Class might seem strange, but all it means is that functions can be passed around and used just like we might use other data-types. For example, strings, ints, floats, etc. A programming language that supports first class functions allow us to pass functions into other functions. Think of this like dependency injection. If you've worked with JavaScript first class functions are used everywhere, and we'll touch on them more in the coming examples.

Example

// robot expects a function to be passed in
function robot(voiceBox) {
  return voiceBox("bzzzz");
}

// console.log is a function that logs to the console
robot(console.log);
// alert is a function that shows a dialog box
robot(alert);

Comparing Imperative and Functional Programming

To show a basic comparison between imperative and functional programming let's add the numbers in an array [1, 2, 3, 4] and get its sum.

Imperatively we might write something like:

const list = [1, 2, 3, 4];

let sum = 0;

for (let i = 0; i < list.length; i++) {
  sum += list[i];
}

console.log(sum); // 10

Converting this to be in a functional style, we have one big problem. We mutate sum to have a different value at every iteration of the list. Remember... immutable data structures.

To make this code functional, let's break down how a summation is calculated.

First, we start at some value, which in our case is 0 (see the line let sum = 0;)! Next, we pull out the first item in the array 1 and add it to our sum. Now we have 0 + 1 = 1. We then repeat this step pulling out 2 and adding it to the sum 1 + 2 = 3. This continues on until we have traversed the length of the array.

To visualize this in a different way:

0 + [1,2,3,4] 0 + 1 + [2,3,4] 1 + 2 + [3,4] 3 + 3 + [4] 6 + 4 10

We can think of this algorithm as two separate functions, first we need some way of adding numbers together.

function add(a, b) {
  return a + b;
}

Easy!

Next we'll need some way of looping through an array given to us. Since most functional programming generally relies on recursion instead of loops, we'll create a recursive function that'll loop through our array. Let's look at what that may look like.

function loop(list, index = 0) {
  if (!list || index > list.length - 1) {
    // We're at the end of the list
    return;
  }

  return loop(list, index + 1);
}

In this function we take the list we want to loop through, and an index we'll use to determine the position in the list we're currently at. If we reach the end of the list, or an invalid list is given, then we're done looping. If not, we'll call loop again, incrementing the index. Try adding a console.log(list[index]) inside the loop function, before return loop(list, index + 1);! We should see 1 2 3 4 printed to the console!

To finally sum our array, we'll need to combine both our loop and add functions. Keep in mind our algorithm above while going through this example:

function loop(list, accu = 0, index = 0) {
  if (!list || index > list.length - 1) {
    return accu;
  }

  const result = add(accu, list[index]);

  return loop(list, result, index + 1);
}

We rearranged some arguments in the loop function. Now we have an accu parameter (accumulation), which will keep track of the sum at a given place in the list. We also directly use our add function to get the result of the accu added with the current item in the list. If we console.log(loop(list)); we should get the result 10 printed to the console!

How about we take this a step further? What if we didn't want to sum up the list of numbers, but instead multiply them? Currently we'd have to copy our loop function, paste it, and change add to be something else (multiply maybe?). What a pain! Remember first class functions? We'll we can use that idea here to make our code greatly more generic.

function loop(func, list, accu = 0, index = 0) {
  if (!list || index > list.length - 1) {
    return accu;
  }

  const result = func(accu, list[index]);

  return loop(func, list, result, index + 1);
}

In the example above, the only thing that changed is that we now added a new argument to loop that takes a function. Instead of add, we'll call our passed in function to get a result. Now we can very easily add, multiply, subtract, etc our list.

loop(add, list);
loop(function(a, b) { return a * b; }, list);

We are no longer just looping through our array, but folding our array like paper until we reach a single result. In functional programming this function might be called fold, and in Javascript we see it as reduce!

function reduce(func, list, accu = 0, index = 0) {
  if (!list || index > list.length - 1) {
    return accu;
  }

  const result = func(accu, list[index]);

  return reduce(func, list, result, index + 1);
}

End

We looked at the basics of functional programming, and how breaking down a problem can give us different solutions to the same problem. reduce is seen as the foundation for other operations like map() or filter(). Here is my test for you, how can we implement these two functions only using our reduce() we just created?

Hint

Remember the algorithm for reduce?

0 + [1,2,3,4] 0 + 1 + [2,3,4] 1 + 2 + [3,4] 3 + 3 + [4] 6 + 4 10

What if instead of starting with 0 we start with an [] array instead ?

Answer

Introducing React-Scroll-To v2

Sat, 03 Nov 2018 00:00:00 GMT

The latest version of a React component I maintain just released, v2 of react-scroll-to. First, it started out as a component I needed, but over time a few people started using it. Because it was initially created for my specific use-case it started to show its warts when new features were ask for. The goals for v2 were two-part: introduce a more flexible API and implement some highly asked for features (scroll by a ref and smooth scrolling).

So what is react-scroll-to? React-scroll-to is a pretty simple component. It allows the control of scrolling either the brower's window, or a component (overflow) to a specific point.

We'll look at a few examples to show off what react-scroll-to can do.
(As a note, in this post I'll only be showing render props, but react-scroll-to also supports higher order components. Examples can be found at: https://github.com/ganderzz/react-scroll-to)

Basics

import React, { Component } from "react";
import { ScrollTo } from "react-scroll-to";

export default class MyComponent extends Component {
  render() {
    return <ScrollTo>{({ scrollTo }) => <a onClick={() => scrollTo({ y: 500 })}>Scroll to Bottom</a>}</ScrollTo>;
  }
}

In the component above we're importing the ScrollTo component from react-scroll-to. This is a render prop, so we'll pass a function as its children. ScrollTo's children has an object as its parameter--this is so the consumer of this component can choose, exactly, what properties they care about. Generally we'll only need scrollTo.

scrollTo() is a function, when called, will either:

Scroll the brower's window based on the given parameters (in this case, scroll 500px from the top of the page)
Scroll all <ScrollArea> components, inside <ScrollTo />, to the given parameters (We'll see this later)

Note: react-scroll-to uses absolute positions--the ability to use relative positioning is coming soon!

When a user clicks on the link, in the example, we'll see the window scroll down 500px!

Scroll Area

The <ScrollArea> component gives scrollTo the ability to scroll components, instead of the window.

import React, { Component } from "react";
import { ScrollTo, ScrollArea } from "react-scroll-to";

export default class MyComponent extends Component {
  render() {
    return (
      <ScrollTo>
        {({ scrollTo }) => (
          <>
            <a onClick={() => scrollTo({ y: 500 })}>Scroll to Bottom</a>

            <ScrollArea>My long content...</ScrollArea>
          </>
        )}
      </ScrollTo>
    );
  }
}

Since a <ScrollArea/> component lives as a child component of <ScrollTo />, whenever we call scrollTo(), it'll scroll all of the <ScrollArea /> components. So in this example when the link is clicked only the "My long content..." area will scroll.

But what if we have multiple <ScrollArea /> components?

import React, { Component } from "react";
import { ScrollTo, ScrollArea } from "react-scroll-to";

export default class MyComponent extends Component {
  render() {
    return (
      <ScrollTo>
        {({ scrollTo }) => (
          <>
            <a onClick={() => scrollTo({ y: 500 })}>Scroll to Bottom</a>

            <ScrollArea>My long content...</ScrollArea>

            <ScrollArea>My long content 2...</ScrollArea>
          </>
        )}
      </ScrollTo>
    );
  }
}

In the case where more than one <ScrollArea /> components exist in a <ScrollTo />, both components will scroll.

What if we only want to scroll one of the <ScrollArea /> components?

import React, { Component } from "react";
import { ScrollTo, ScrollArea } from "react-scroll-to";

export default class MyComponent extends Component {
  render() {
    return (
      <ScrollTo>
        {({ scrollTo }) => (
          <>
            <a onClick={() => scrollTo({ id: "content-two", y: 500 })}>Scroll to Bottom</a>

            <ScrollArea>My long content...</ScrollArea>

            <ScrollArea id="content-two">My long content 2...</ScrollArea>
          </>
        )}
      </ScrollTo>
    );
  }
}

By adding an id property to a <ScrollArea /> we are able to reference that component in our scrollTo() function. scrollTo() then takes another field, 'id', that'll scroll any <ScrollArea /> component that matches that id (id's must be unique).

V2 Features

scrollTo and ScrollArea have both existed in v1; let's look at branch new features.

Smooth Scrolling

Smooth scrolling couldn't be simpler. By adding a smooth: true property to the scrollTo() object, react-scroll-to will automatically apply smooth scrolling.

import React, { Component } from "react";
import { ScrollTo } from "react-scroll-to";

export default class MyComponent extends Component {
  render() {
    return (
      <ScrollTo>
        {({ scrollTo }) => (
          <a onClick={() => scrollTo({ x: 200, smooth: true })}>
            {/* Oh yeah, we can scroll by x also! */}
            Scroll to Bottom
          </a>
        )}
      </ScrollTo>
    );
  }
}

Scroll by Ref

Maybe instead of using a <ScrollArea /> component, we have a ref to a component we want to scroll. Or maybe instead we want to scroll a component outside <ScrollTo />'s children. Now we have the ability by providing the ref through the scrollTo() argument object!

import React, { Component } from "react";
import { ScrollTo } from "react-scroll-to";

export default class MyComponent extends Component {
  myRef = React.createRef();

  render() {
    return (
      <ScrollTo>
        {({ scrollTo }) => (
          <a onClick={() => scrollTo({ ref: this.myRef, y: 200, smooth: true })}>
             Scroll to Bottom
          </a>
        )}
      </ScrollTo>

      <div ref={this.myRef}>
        I'm outside ScrollTo!
      </div>
    );
  }
}

Conclusion

V2 of react-scroll-to provides a lot of behind-the-scenes structural changes that'll allow for a better developer experience while implementing new features. We also added many new features that have been in demand. As things solidify, we hope to expose hooks in react-scroll-to to allow even more flexibility.

Check it out: react-scroll-to
Examples: Click Here

React: Controlling Rendering with Keys

Thu, 18 Oct 2018 00:00:00 GMT

key, the property we throw some value into to suppress warnings. This property is used by React to determine when a component is deleted, updated, or created. We generally don't interact much with the key prop--except in loops.

My team recently ran into an issue lately--how do we rerender all child components when a state has changed? The simplest approach... you guessed it, key!

Let's take a look.

class Parent extends Component {
  state = {
    key: true,
    count: 0,
  };

  handleChildUnmount = () => {
    this.setState((prevProps) => ({ count: prevProps.count + 1 }));
  };

  toggleKey = () => {
    this.setState((prevProps) => ({ key: !prevProps.key }));
  };

  render() {
    const { key, count } = this.state;

    return (
      <div>
        <button onClick={this.toggleKey}>Toggle Child Key</button>
        <Child key={key} count={count} onUnmount={this.handleChildUnmount} />
      </div>
    );
  }
}

class Child extends Component {
  componentWillUnmount() {
    this.props.onUnmount();
  }

  render() {
    return <div>Total Renders: {this.props.count}</div>;
  }
}

In this example we are toggling the key prop of our Child component between true and false. We then keep track every time the Child unmounts through a callback to increment the Parent's state. When we toggle the key prop, we will see the counter increment each time. This is, because React uses the key to determine if a component has changed. Since we are changing the key each time React will see our component has updates, and rerender the Child component.

This is the easiest way to cause a rerender of a child component (and all children of the child), and shows the power of understanding thekey prop!

Note: Even if a child component returns false in a shouldComponentUpdate, changing the key prop will cause it to rerender anyway (Try it in the CodeSandbox above!).

Tips on Improving FabricJS Speed

Thu, 11 Oct 2018 00:00:00 GMT

FabricJS is an awesome library that handles Canvas interactions and rendering. Inherently it is a pretty performant library, but recently we ran into an issue where we needed to render ~8mb of json data (10k objects). Given any framework, it is no easy task to render this much data. The biggest culprit while rendering a lot of objects is renders (or rerenders). When the canvas has to show any change, it renders the entire canvas. This includes clearing the canvas, looping through each object, and drawing it. In this post I'll go through some of the techniques we used to improve interaction and rendering speed.

Cut out the basics

FabricJS has a small post about optimizing performance. All great tips, but the one to look at is setting renderOnAddRemove to false. Adding this property to the canvas will prevent Fabric from re-rendering if a shape is added or deleted. This gives huge speed improvements on initial loads while adding a lot of shapes to the canvas.

const canvas = new fabric.Canvas("myId", { renderOnAddRemove: false });

Caution: canvas.renderAll(); will have to be called whenever we want a change to show on the canvas

Enliven over loadFromJSON

loadFromJSON is a really helpful function when we want to deserialize JSON to the canvas, but it comes with some draw-backs. First, loadFromJSON will clear the canvas before it loads the JSON objects. This can be bad if we added shapes to the canvas before loading then JSON. Second, it will call renderAll once the JSON is finished. This is bad when we have additional operations to perform after our JSON object is loaded (ie. adding more shapes or selecting then).

Alternatively we can use a function called enlivenObjects.

const canvas = new fabric.Canvas("myId", { renderOnAddRemove: false }););
// enlivenObjects([array of json objects], [callback])
fabric.util.enlivenObjects([{}, {}, {}], (objs) => {
    objs.forEach((item) => {
        canvas.add(item);
    });
    canvas.renderAll(); // Make sure to call once we're ready!
});

enlivenObjects takes in an array of the serialized FabricJS JSON (found in: [json].objects), and returns the Fabric object representation of it. We use a callback to get the parsed objects. This is similar to how loadFromJSON handles loading behind the scenes! The bonus here is there are no unneeded renders and canvas clearing. We can control when the canvas gets rendered!

Don't Canvas Everything

The more shapes on the canvas, the more work Fabric has to do on a render. One way around this is to take out any shapes that don't need to be manipulated or animated. We achieve this by converting those un-interactive layers to an image canvas.toDataURL("png"); and rendering it as an HTML <img /> tag. Then, overlay the canvas on top of the image; only using the canvas for the interactive bits while showing everything.

React: Not Everything is State

Fri, 05 Oct 2018 00:00:00 GMT

When working with React we get introduced to state as a way if storing component's data. There is another way that generally gets overlooked: class properties.

Example

class AnnoyingButton extends React.Component {
  intervalId = null; // Here!
  id = generateUniqueId(); // Here!

  state = {
    isDisabled: false,
  };

  componentDidMount() {
    this.intervalId = setInterval(() => {
      this.setState(({ isDisabled }) => ({
        isDisabled: !isDisabled,
      }));
    }, 100);
  }

  componentWillUnmount() {
    console.log(`Unmounting ID: ${this.id}`);
    clearInterval(this.intervalId);
  }

  render() {
    return <button disabled={this.state.isDisabled} />;
  }
}

Nothing special about the component; the interesting bits are the id and intervalId variables. We need some way of preventing memory leaks when the component unmounts. In componentDidMount we save the interval's ID to a class property. Then, use the property to clear the interval and console.log the component's unique ID.

You might be thinking, "Why chouldn't we just store this information in the component's state?" React re-renders the component, and any child components, when the state changes. If the render method never uses a piece of the state it could be causing unwanted renders--making your application slower!

When to use class properties: If state needs to be stored, but is never used as a part of the view/render of a component.

Write Software that Evolves

Sun, 29 Jul 2018 00:00:00 GMT

In software development, we can easily get trapped in analysis paralysis. Having the foresight to make all the correct decisions is hard. We make hundreds, if not thousands, of decisions during the lifetime of our software, and we're likely to get something wrong. Instead of trying to get every minutia correct before starting a project, we should aim to write software that can evolve.

Continuous Minimum Viable Product Development

One approach to combat the constant changing of requirements is to strive for continuous minimum viable product (MVP) development. An MVP is the most basic version of a feature or application that satisfies a need. For example, let's say our client wants the ability to view some information. We may only design a page with a table that holds the data (We wouldn't add additional features like filtering or graphs). Notice how I said continuous. This process shouldn't end after the application/feature is released. Keeping improvements incremental and small allows us to be flexible in our requirements. Do no more or less than what's being asked.

Lazy Evaluation

“I’m sure the user would need this feature. It’s easy, I’ll just add it”

This kind of thinking is a killer to flexible software. First, every line of code has a cost. Not only are there time, money, and energy in initially writing the code, but also the maintenance and surface area for bugs create its own cost. Second, the feature added could never be used by the user or just wrong! In the best scenario, this doubles the amount of work adding the feature.

Instead of eagerly evaluating requirements, flexible software works best through lazy evaluation. Wait for the client/stakeholder/user to ask for a feature before implementing it (even on improvements you know they'll ask for). Lazy evaluation has a few benefits. It reduces adding features the user won't use--they asked for it. It also allows us to really understand what the user is really asking for. Instead of creating something then asking, "is this what you want?" we're able to get upfront the ideal process.

Summary

Instead of picking a target and firing--hoping we hit something, combining continuous MVP and lazy evaluation keeps us agile. It allows firing in a direction and incrementally changing course as the target moves. Of course, do your homework and gather requirements beforehand, but aim for software that can evolve over time instead of trying to get it right from the start.

Part Two: Using Typescript with Redux

Sun, 15 Jul 2018 00:00:00 GMT

Last time we went through using Typescript with React, and setup a small counter application. A lot of applications out there use Redux. A common pain-point for me was how to setup Typescript with Redux--it's a common hurdle with my team also. Though Redux is a totally different library, it holds a big share of the state management market in React applications. In part two we'll take a detour from base React, and look at converting our counter to using Redux!

Note: Same with part one, I'm going to assume Typescript, and now Redux, is setup and compiles. This is a write-up on integrating types, and less on how to setup a project.

Actions

We'll start out creating a few actions for our counter.

// Action Types
export const INCREMENT = "INCREMENT";
export const DECREMENT = "DECREMENT";

export type ActionTypes = typeof INCREMENT | typeof DECREMENT;

export interface IAction {
  type: ActionTypes;
  payload: IPayload;
}

export interface IPayload {
  amount: number;
}

// Action Creators
export function increment(amount: number): IAction {
  return {
    type: INCREMENT,
    payload: {
      amount,
    },
  };
}

export function decrement(amount: number): IAction {
  return {
    type: DECREMENT,
    payload: {
      amount,
    },
  };
}

Going from top to bottom. We start out creating a few action types: INCREMENT and DECREMENT. This will allow us to reuse these strings as types, and get rid of any 'magic strings'. Creating action types improves our code so we only have one place to update this value if our type should change. Additionally, reduces bugs that can occur due to human error (eg. we accidently put 'inCREMENT' or 'increment' instead of 'INCREMENT').

Moving on, we hit a Typescript type and a few interfaces. In ActionTypes we use a union type to say, "we can use any of these types". This will come in handy later. Next, we define a general interface for our action creators. We provide the required Redux type property that reuses ActionTypes. To keep different actions similar, we'll use payload to deliver a 'value' we want our reducer to work on. For the counter, we'll use IPayload which has one property amount which is a number. We'll use this to set the amount we'll either increment or decrement the count.

Finally, we'll create an action creator for both increment and decrementing our counter. These functions are pretty straightforward. They are both functions that take a number, amount, and returns an IAction.

Reducer

export const defaultState = {
  count: 0,
};

export function rootReducer(state = defaultState, action: IAction) {
  switch (action.type) {
    case INCREMENT:
      return {
        count: state.count + action.payload.amount,
      };

    case DECREMENT:
      return {
        count: state.count - action.payload.amount,
      };

    default:
      return state;
  }
}

I won't spend too much time on the reducer as Typescript doesn't play much role here (in this example). We'll export our defaultState to use later!

Component

interface IStateToProps {
  count: number;
}

interface IDispatchToProps {
  increment: typeof increment;
  decrement: typeof decrement;
}

type AllProps = IStateToProps & IDispatchToProps;

class App extends React.Component<AllProps> {
  private handleClick = (event: React.MouseEvent<HTMLButtonElement>) => {
    const type: string = event.currentTarget.title;

    if (type === "decrement") {
      this.props.decrement(1);
    } else {
      this.props.increment(2);
    }
  };

  public render() {
    return (
      <div>
        <button title="decrement" onClick={this.handleClick}>
          -
        </button>
        {this.props.count}
        <button title="increment" onClick={this.handleClick}>
          +
        </button>
      </div>
    );
  }
}

export const ConnectedApp = connect<IStateToProps, IDispatchToProps>(
  (state: typeof defaultState) => ({
    count: state.count
  }),
  {
    increment,
    decrement
  }
)(App);

In this example we're using a library react-redux--making it easier to connect React components to Redux. Starting out, we create two interfaces that we'll use both as App's props and in the connect() function at the bottom of the code.

IStateToProps we tell Typescript what the mapped state will be named. In our case we'll keep the name count.
IDispatchToProps we define what actions our component will get. Using typeof we can easily tell Typescript to reuse the implied type definition of increment and decrement (our actions).

Next, we create a new type that combines both IStateToProps and IDispatchToProps. This is more for convenience as we see in App's prop definition. We could of also used class App extends React.Component<IStateToProps & IDispatchToProps> and avoided the need for AllProps. Combining all the props to a type becomes valuable when using multiple lifecycle hooks (shouldComponentUpdate(nextProps: AllProps)), or multiple functions that work off the props!

The App component is pretty similar to our part one example, so we'll skip this and look at the connect() function.

connect() is a generic type that can take three types connect<IStateToProps, IDispatchToProps, IProps>(). Going from left to right--first is the type definition for stateToProps. This is the connecting component's props we're mapping the Redux state to. Second, the type definition for dispatchToProps. This is the connecting component's props we're mapping Redux actions to. Lastly, we're not using it in this example, but we can provide the props of our component we're connecting.

We've successfully converted our counter to Redux, and provided useful types also!

Generic Type Arguments in JSX Elements

Sat, 02 Jun 2018 00:00:00 GMT

Typescript recently released generic type arguments for JSX in their 2.9 release. It's a mouthfull, but what does that mean for us? A common use-case I'm excited for is allowing consumers of libraries to extend a component's props. Using [dynamic components]({% post_url 2017-07-26-injecting-react-tag-types %}) we'll look at allowing our components to be extended even more.

What Are Generic Type Arguments?

As shown in the Typescript release notes, generic type arguments are a way to create components using Typescript's generics syntax. Below is a side-by-side comparison of the old way vs. using generic type arguments.

The Old Way:

// Notice color isn't defined as a prop, and will error out normally
function Div(props: { value: string }) {
  const { value, ...rest } = this.props;

  return <div {...rest} />;
}

// Using spread, we can trick Typescript into ignoring that color will be a prop
// on Div
function App() {
  return <Div {...{ color: "red" }} />;
}

Generic Type Arguments:

// Notice our new generic on the component
function Div<T extends object>(props: { value: string } & T) {
    const { value, ...rest } = props as any; // spreading on generics not yet supported

    return <div {...rest} />
}

interface IAdditionalProps {
    color: string;
}

// We can tell typescript our Div element has additional properties!
function App() {
    // Generic Type Arguments!
    return <Div<IAdditionalProps> color="red" value="TEXT!!!" />
}

And the same can be used with class components:

// Notice our new generic on the component
class Div<T extends object> extends React.Component<{ value: string } & T> {
    public render() {
        const { value, ...rest } = this.props as any;

        return <div {...rest} />
    }
}

interface IAdditionalProps {
    color: string;
}

// We can tell typescript our Div element has additional properties!
function App() {
    return <Div<IAdditionalProps> color="red" value="TEXT!!" />
}

Dynamic Elements

Let's say we have a MenuItem component that could be overloaded with either a Router link component, or a html a tag. One way we might write this...

interface IProps {
  tag: React.ReactNode;
  children: React.ReactNode;
}

function MenuItem({ tag, children, ...rest }: IProps) {
  const Tag: React.ReactType = tag || "a";

  return <Tag {...rest}>{children}</Tag>;
}

MenuItem works perfect fine as a component, but when it's time to add additional properties, Typescript will yell. For example, the a tag needs a href prop. We don't want to hardcode href, because we can inject any type of element through the tag prop (React Router, button, etc).

<MenuItem tag="a" href="http://google.com">Click Me!</MenuItem> // Error because href isn't defined in IProps!
<MenuItem tag={Link} to="/home">Home</MenuItem> // Error because to isn't defined in IProps!

We can fix our errors using generic type arguments.

interface IProps {
  tag: React.ReactNode;
  children: React.ReactNode;
}

function MenuItem<T extends object>(props: IProps & T) {
  const { tag, children, ...rest } = props as any;
  const Tag: React.ReactType = tag || "a";

  return (
      <Tag {...rest}>
          {children}
      </Tag>
  );
}

Now the consumer of our MenuItem component can tell us what additional properties are needed!

<MenuItem<{ href: string }> tag="a" href="http://google.com">Click Me!</MenuItem> // Success!
<MenuItem<{ to: string }> tag={Link} to="/home">Home</MenuItem> // Success!

Through generic type arguments for JSX, we are able to make our component more reusable. Users can extend components to allow additional props. Great!

Part One: Using Typescript with React

Wed, 16 May 2018 00:00:00 GMT

Finished Example: Click Here

Learning Typescript with React can be challenging, and in my case, cursing Microsoft and throwing any on every variable. The goal of this series is to document what I've learned while developing applications in React, and trying hard to shove in Typescript. Like many things, the initial learning curve may be staggering, but adding a type-checker repays dividends once the gears start turning. One thing to note: this isn't a post about setting up Typescript. We'll assume a tsconfig.json exists, and compiles our code to valid JavaScript.

We'll go through part one by creating a counter, and adding types where needed.

App

Starting out, we have a scaffolding of our application.

// Note, Typescript requires the whole React package to be imported.
// More information can be found: https://stackoverflow.com/a/37491916
import * as React from "react";

class App extends React.Component {
  public render() {
    return (
      <div>
        test
      </div>
    );
  }
}

Looks like a valid React class component, but a few Typescript differences stand out right away. First, because React lib doesn't have a default export, Typescript requires us to import the whole package (import * as React from "react";). Second, all React methods are defined as public (private or protected will not work), as seen in the render method. We can remove the public keyboard, and the component will work the same. I like to explicitly define scope of my methods to help differentiate between my methods and React's. Generally, I define my methods as private unless otherwise needed. This enforces the scope of the method to just the component, and prevents unwanted side-effects.

State

We'll need a way of storing the state of the counter. Let's implement this.

// Note, Typescript requires the whole React package to be imported.
// More information can be found: https://stackoverflow.com/a/37491916
import * as React from "react";

interface IState {
  count: number;
}

class App extends React.Component<{}, IState> {
  public readonly state = {
    count: 0
  };

  public render() {
    return (
      <div>
        {this.state.count}
      </div>
    );
  }
}

A lot is happening here, so we'll break it down change-by-change.

Interface

interface IState {
  count: number;
}

First, we create a new interface that defines the shape of our component's state.

Notice that as a practice we start the interface name with an uppercase "I". This is borrowed from OOP languages, like C#, to allow us to better identify a variable vs type vs interface.

Another practice I've adopted: define Typescript types in PascalCase, and Javascript variables in camelCase. Yet another helpful naming scheme to prevent trying use a type definition as executable code!

Moving on, we define our component's state as having one field, count. In Typescript there is no difference between a float 0.0001 and an int 10. To say something is 'number-like', we give it the type number.

Class Definition

class App extends React.Component<{}, IState> {

React.Component (also React.PureComponent) are generic types allowing us to provide the shape of the component's props and state. Component comes with a couple predefined properties (children and ref to name a few). Because App doesn't have any props, we'll use an empty object. The React Typescript definition combines the type we pass in with the default Component type, so even with an empty object, the inherited component props will still be available (eg. children and ref). For our component's state, we'll tell Typescript we want to use our state shape defined in IState.

To break it apart:

Define a component with just state: React.Component<{}, IState>
Define a component with just props: React.Component<IProps>
Define both state and props: React.Component<IProps, IState>

Defining State

public readonly state = {
  count: 0
};

Finally, we define the state for the component. Remember, so far we've only told Typescript what the shape of our state is. This is where we define its actual value in React. Because state is needed by React, we define it as public. Also, since we don't want anyone mutating the state directly, we then add readonly. This will throw a Typescript error whenever we try to reassign state directly to a value (eg. this.state.count = this.state.count + 1; // Error!). Next, we define our public readonly variable to have the name state, and assign it an object that matches the shape we defined in IState. Since we defined React.Component with IState as our state shape, Typescript knows that the state should have a count field with a number value.

Adding Events

Let's finish our counter by adding some buttons, and a click event that either decrements or increments the count.

// Note, Typescript requires the whole React package to be imported.
// More information can be found: https://stackoverflow.com/a/37491916
import * as React from "react";

interface IState {
  count: number;
}

class App extends React.Component<{}, IState> {
  public readonly state = {
    count: 0
  };

  private handleClick = (event: React.MouseEvent<HTMLButtonElement>) => {
    const type: string = event.currentTarget.title;

    this.setState(({ count }) => ({
      count: type === "decrement" ? count - 1 : count + 1
    }));
  };

  public render() {
    return (
      <div>
        <button title="decrement" onClick={this.handleClick}>
          -
        </button>
        {this.state.count}
        <button title="increment" onClick={this.handleClick}>
          +
        </button>
      </div>
    );
  }
}

The big change is the addition of a new method.

private handleClick = (event: React.MouseEvent<HTMLButtonElement>) => {

We create a new private method called handleClick that will take care of our button click events. Notice that since React uses synthetic events--we have to use one of React's types. The event was triggered by a click of the mouse, so we'll use React.MouseEvent. React.MouseEvent is a generic type that takes the type of element the event is triggered from. In our case, it's the default HTML button element (defined as HTMLButtonElement). We finish off by incrementing or decrementing the count based on the title of the button.

Our counter is now complete with TypeScript types!

To be continued in part two...

Reusable Components: Factory Components

Tue, 10 Apr 2018 00:00:00 GMT

Beware the mega component. Mega components contain around 50 props--when the stars align, only certain values produce specialized output. For example, let's assume we have a <IdentityInput /> component which provides user login using only a fingerprint. Nifty, eh?
Our component has a few properties: <IdentityInput onSuccess={login} onFail={showError} fingerprint={value} humanOnly /> allowing for only human fingerprints, and provides a few callbacks for onSuccess and onFail.

A few months go by and our company, Component Co., finds out there are a lot of humans out there trying to login, but are missing fingerprints! Great, we'll update our component to allow for eyeball scans.

<IdentityInput onSuccess={login} onFail={showError} value={value} isEyeballEnabled isFingerprintEnabled humanOnly />

After many failed attempts to login to our system the boss of Component Co., a cyborg without eyeballs or fingerprints, demands that we provide a password input field. Once again, the IndentityInput component gets updated to have the request.

<IdentityInput
  onSuccess={login}
  onFail={showError}
  value={value}
  isEyeballEnabled
  isFingerprintEnabled
  showPasswordField={this.state.isCyborg}
  humanOnly={!this.state.isCyborg}
/>

Just from this contrived example, we can see that allowing for ever-growing mega components can start to be a problem. For one, we lose single-responsibility. Over time our component does multiple things which causes a barrier of entry penalty when new developers start using the component. Second, it provides weird combinations of secret password props in components. "If I have these props, it does this one thing. But, don't set that string prop there or everything breaks!" Third, we'll have to write our class/function in a way to handle all the edge cases and props--probably requiring way too many if-statements.

One solution to this problem is to have a factory component, very much like the factory design pattern. We'll keep individual components small, performing a single function, but then create a parent component that then decides what component we should render.

For example:

function FingerPrint(props) {
  return <div {...props}>Super Awesome Fingerprint Scanner</div>;
}

function EyeballScanner(props) {
  return <div {...props}>Super Ok Eyeball Scanner</div>;
}

function PasswordInput(props) {
  return <div {...props}>Super Lame Password Input</div>;
}

/**
 * Factory Component
 */
function IdentityFactory(props) {
  const { type, ...rest } = props;

  switch (type) {
    case "finger":
      return <FingerPrint {...rest} />;

    case "eyeball":
      return <EyeballScanner {...rest} />;

    case "password":
      return <PasswordInput {...rest} />;

    default:
      console.warn(`Invalid Indentity type "${type}". Abort!`);
      return null;
  }
}

Now, when we want to use the IdentityFactory component we can switch between the different input types, but also provide props relevant to just that component. It'll allow us to modify single-responsibility components with ease.

render() {
  return (
    <div>
      <IdentityFactory type="finger" humanOnly />
      <IdentityFactory type="eyeball" humanOnly />
      <IdentityFactory type="password" />
    </div>
  );
}

Global Component Registration

Fri, 08 Dec 2017 00:00:00 GMT

Introduction

Often, I find myself looking through open-source projects to see how they solve issues. Not bugs, but problems in code that cause repetition or excessive boilerplate. Modals have given me problems, specifically when having to create a specialized modal for different workflows. They are awkward. Modals, in the DOM, live outside of the scope of the current workflow. And, part of their state usually lives outside of the modal itself (hide/show). I came accross an interesting solution to the modal problem while looking through Insomnia's code. This is a different post than what I normally do. I'll just be posting code as an example, and filling in the explaination through comments. Hopefully this will work as a reference, and starting point to play around with the idea.

Code

// ModalHandler.js
const modals = {};

/*
 * This function takes in a component, and then adds a
 * reference to it through a friendly named key->value.
 */
export function registerModal(component) {
  if (!component) {
    return;
  }

  modals[component.name] = component;
}

/*
 * show() takes the component we want to show, and some additional
 * arguments. We'll then call the 'show' function on the component.
 * This allows us to 'activate' a component anywhere, but invert
 * control to the relative component.
 */
export function show(component, ...args) {
  const elem = modals[component.name];
  if (elem.show && typeof elem.show === "function") {
    return elem.show(...args);
  }

  console.warn(`show() function is missing from ${component.name}.`);
}

// App.jsx
import React, { Component } from "react";
import { registerModal } from "./ModalHandler";

class Base extends Component {
  render() {
    return (
      <div>
        <MyApp />
        {/*
          This component is pretty regular except for this next bit.
          We'll pass in registerModal() to the component's ref we'll
          show later on
        */}
        <Modal ref={registerModal} />
      </div>
    );
  }
}

import React, { Component } from "react";
import { show } from "./ModalHandler";
import Modal from "./Modal";

class MyApp extends Component {
  showModal = () => {
    // Will call the .show() function
    // on the Modal component
    show(Modal);
  };

  render() {
    return <button onClick={this.showModal}>Show Modal</button>;
  }
}

// Modal.jsx
import React, { Component } from "react";

class Modal extends Component {
  state = {
    isOpen: false,
  };

  // This is the show() function that'll be invoked
  // when this component is passed to ModalHandler.js' show() function
  show = () => {
    this.setState({ isOpen: true });
  };

  render() {
    if (!this.state.isOpen) {
      return null;
    }

    return (
      <div>
        Modal!
        <button onClick={() => this.setState({ isOpen: false })}>Close</button>
      </div>
    );
  }
}

Encapsulating State with Functional Children

Thu, 14 Sep 2017 00:00:00 GMT

import Alert from "../../../../components/Alert.astro";

Update (3/20/2023): Since writing this post the community has called this technique "Render Props".

There is a technique for creating reusable components that got missed in my last post, Tips on Creating Reusable Components, that I'd like to talk about. That is, components that have functions as children. This is a great tool that mirrors higher order components, in that it lets us abstract away reusable states. We'll start out with an example.

Breaking down functional children

import React from "react";

class Booer extends React.Component {
  constructor(props) {
    super(props);

    this.state = {
      test: "...",
    };
  }

  componentDidMount() {
    setTimeout(() => {
      this.setState({
        test: "BOO!",
      });
    }, 1000);
  }

  render() {
    // Using children as a function!
    return this.props.children(this.state.test);
  }
}

function Timer(props) {
  return <Booer>{(test) => <div>{test}</div>}</Booer>;
}

Booer is a component that after 1000ms, updates its state to say "Boo!". Nothing special. The power in functional children comes in play in the render method. Instead of treating this.props.children as a variable, we pass a long some state which gets injected into the children prop. Moving to the Timer component, we see something a little odd. The Booer component takes a function with an argument, test, being that state we passed into this.props.children. We are then free to return any valid React children in the function. This let's us reuse state for different visual components! In the case of the Timer component, it will show a div with "...". Once 1000ms is complete, the contents will be replaced with "Boo!".

Toggle Component

The first example is a nice way to show functional children, but let's make something a little more practical. Like the title suggestions, how about a component that keeps track of a toggle! This may look something like:

import React from "react";

class Toggle extends React.Component {
  constructor(props) {
    super(props);

    this.state = {
      isToggled: false,
    };

    this.toggle = this.toggle.bind(this);
  }

  toggle() {
    this.setState((prevState) => ({
      isToggled: !prevState.isToggled,
    }));
  }

  render() {
    const { isToggled } = this.state;

    return this.props.children(isToggled, this.toggle);
  }
}

function ToggleButton() {
  return (
    <Toggle>
      {(isToggled, toggle) => (
        <button onClick={toggle}>{isToggled ? "ON" : "off"}</button>
      )}
    </Toggle>
  );
}

Looking at it, the Booer component is pretty similar to out new Toggle component. They both handle some state, then pass it to this.props.children() as function argument. In the case of Toggle, we are now passing two arguments. First, our isToggled state. Second, a class method that will toggle the isToggled state. this.toggle will be useful for a consumer to control events.
Looking at the ToggleButton component, it's pretty simple to wire out a button that has toggle ability, while making its state reusable! What if we want a toggle checkbox? We can just swap out the <button> JSX tags for <input type="checkbox">!

Conclusion

Functional children is yet another technique for creating reusable components. It helps us move presentational components away from stateful logic (ie. Dumb/Smart components or Containers/Components).

Tips on Creating Reusable Components

Fri, 08 Sep 2017 00:00:00 GMT

Introduction

A huge selling point of React is its use of composable, reusable components. Everything is built off the idea of V = F(d), or view/UI is created by some function acting on data/state. How do we create more advanced user interface? Well, just add more functions to the party (For example V = G(F(E(S(d))))). That's cute, why does this matter? Thinking of our components as functions, even if we use class, will help us create more reusable components. It even helps us write super helpful utility functions called Higher Order Components.

We'll look at ways to improve our reusability and composition of components by using an example component a long the way. For this article, we'll use a component that adds an Icon to a button.

For example,

class IconButton extends React.Component {
  render() {
    <Button onClick={this.props.onClick}>
      <Icon /> {this.props.text}
    </Button>;
  }
}

And to consume the button,

<IconButton text="Click Me!" onClick={() => alert("Click!")} />

Not bad.. easy to use, and to the point. But, some part of me thinks this could be better. Let's walk through a few suggestions on making this component more reusable.

Keep it Simple, Jack

Continuing on the topic of thinking of components as functions, keep components simple. Components that do too many things are dangerous. They are easy to break, and a pain to maintain. Instead, split functionality into separate components, then compose those components to make something functional. This makes it really easy to maintain features, and to swap out functionality when requirements change.

Going to the IconButton example, we really don't need an IconButton component. What if tomorrow we need an IconInput button? We not only have two separate, but pretty similar components to maintain! We can fix this by using composition. What we really want is something that 'adds an icon' to a component. Let's make a new component called IconAdder.

class IconAdder extends React.Component {
  render() {
    return (
      <div>
        <Icon /> {this.props.component}
      </div>
    );
  }
}

to consume it

<IconAdder
  component={<Button onClick={() => alert("Click!")}>Click Me!</Button>}
/>

IconAdder allows us to throw any ol' component we want into it, and it'll add an Icon to it. Nice.

Hello There, Children!

One thing I come across a lot is the overuse of component properties. Components should almost never be used as properties. It ends up making components hard to use, and in the end, we are fighting with React. In React, every component has a property called children (props.children). This says, whatever we pass between this component's tags, we'll insert here. Let's see an example props.children in the IconAdder component.

class IconAdder extends React.Component {
  render() {
    return (
      <div>
        <Icon /> {this.props.children}
      </div>
    );
  }
}

to consume it

<IconAdder>
  <Button onClick={() => alert("Click!")}>Click Me!</Button>
</IconAdder>

The <Button> component will be inserted in IconAdder's {this.props.children}! Much better!

Injecting HTML Types

I wrote an article on this subject here already so I'll be brief.

As someone consuming a component, I want as little pollution of my code as possible. Pollution in this case could be anything: event handlers, code size, or even HTML elements. In the case of our IconAdder component, a parent <div> wrapper gets added to every component using it. It would be great if we could get rid of the div, and just make it our child component. Well... we're in luck. We can specify a tag property, and then use that property. This lets the end-user be in control of their DOM structure.

class IconAdder extends React.Component {
  render() {
    const { tag, onClick, children } = this.props;
    const Tag = tag;

    return (
      <Tag onClick={onClick}>
        <Icon /> {children}
      </Tag>
    );
  }
}

to consume it

<IconAdder tag={Button} onClick={() => alert("Click!")}>
  Click Me!
</IconAdder>

Another benefit of using a 'tag' property, is let's say that we want to support React Router's <Link> component, but we also need to support the classic HTML <a> tag. We can easily swap these two out by just changing the 'tag' prop!

Allow Extension

Nothing grinds my gears like getting a fresh new component, but realizing I want to make the font bold. So, I add a quick style={ { fontWeight: 800 } } to the component, refresh, and nothing changes. (Warning: what is about to be shown requires a transpiler).

We should allow our components to be reasonably editable, while protecting what we need to. This can be done by the rest operator.

Right now, our IconAdder component won't accept a style, className, or title prop. Oh yeah, and what about in the future if we need to use IconAdder on a <a> tag. We'll need to support href also. Let's use the rest operator to support all of these properties!

class IconAdder extends React.Component {
  render() {
    const { tag, onClick, children, ...rest } = this.props;
    const Tag = tag;

    return (
      <Tag onClick={onClick} {...rest}>
        <Icon /> {children}
      </Tag>
    );
  }
}

to consume it

<IconAdder
  tag={Button}
  onClick={() => alert("Click!")}
  style={{ fontWeight: "800" }}
  title="A button for clicking">
  Click Me!
</IconAdder>

...rest will grab whatever properties we haven't taken off in the destructuring (const { a, b, c} = this.props;), and assign it, in this case, to a variable called rest. We then apply all those properties to our <Tag> component by destructuring the rest object into the individual props. As shown in the consumption of IconAdder, we can now add whatever other properties we want!

Conclusion

These are a few tips I use when creating components to keep them easier to consume, and extend. In summary, think of every component as a function. It will consume some input, and produce an output. The children property is your friend, use it when it makes sense! Dynamically injecting the component type can turn multiple similar components, into one highly reusable component. Finally, allow components to receive extra props, and have the properties/styles override the base implementation when possible.

Introduction to Higher Order Components

Thu, 17 Aug 2017 00:00:00 GMT

Introduction

Think of Higher Order Components (HOC) like Pacman. As Pacman consumes his smaller looking dot counterparts, Pacman gains superpower abilities. Like ghost eating! HOC's work similarly... minus ghosts.
A HOC consumes a base component, applies some new ability or super power, then spits out a new modified base component. To help show the power of HOC's, lets create one that does a simple check. If a component doesn't have children, show an empty component. When children are present, we'll display them.

withEmptyState()

First, lets define our base component.

function Hello(props) {
  return <div>Hello, {props.children}!</div>;
}

Before jumping straight into the HOC, what are we trying to achieve? We want to pass our <Hello /> component into some function, lets call it withEmptyState(), which creates and returns a new component. This new component will either: show <Hello /> if the new component has children, or will return null.

function withEmptyState(component) {
  return function (props) {
    // Start new stateless functional component
    if (props.children) {
      return component(props);
    }

    return null;
  };
}

Pretty simple, but extremely powerful! All this function does is take a component, then returns a new stateless functional component. Inside, we check the props. Does this component have children? If yes, return our originally passed in component using our new component's props (We'll see how this ties in soon). If no children exist, don't render anything.

But how would I use withEmptyState?

const HOC = withEmptyState(Hello);

class MyContainer extends React.Component {
  render() {
    return (
      <div>
        HOC 1: <HOC />
        <hr />
        HOC 2: <HOC>WORLD!</HOC>
      </div>
    );
  }
}

Our first instance of <HOC /> wouldn't render anything, as we haven't gave it children.

The second <HOC>WORLD!</HOC> would render our <Hello> component; we would see "Hello, WORLD!".

The End

Higher Order Components allow us to separate common functionality into their own functions, so we don't have to add duplication between components. They also allow us to decouple functionality!

Injecting Dynamic Elements to Components

Wed, 26 Jul 2017 00:00:00 GMT

Introduction

Let's say we're working on an UI component library using React JS. We make a super awesome looking button, maybe even the best button in the world. But suddenly, our computer shuts off without saving our component!
Like Tenacious D, we create a tribute to the button which looks like:

class AwesomeButton extends Component {
  render() {
    const { children, ...other } = this.props;

    return <button {...other}>{children}</button>;
  }
}

Everything is working great. We create buttons all over the place <AwesomeButton onClick={doStuff}>Click ME</AwesomeButton>.

The next day, the boss comes over, "This button is amazing, let's make a button link to Google!"
Easy enough, we create a new component that instead uses an anchor tag.

class AwesomeButtonLink extends Component {
  render() {
    const { children, ...other } = this.props;

    return <a {...other}>{children}</a>;
  }
}

Weeks later, another programmer walks over, "Hey, we're converting to using React Router. Can we get a button that can use the Link component?"
Mumbling under your breath, we create yet another Awesome component.

class AwesomeButtonReactRouterLink extends Component {
  render() {
    const { children, ...other } = this.props;

    return <Link {...other}>{children}</Link>;
  }
}

We have ourselves a problem. Every time there is a new request we have to create new components that are very similar, just using slightly different render elements. What if the company decides to re-brand. Instead of blue, we are a red company now. Little changes to the visuals of these AwesomeButton components need to be updated individually. Think DRY! Is there a better way of doing this? Stay tuned.

Dynamically Injecting Elements

What if the consumer of a component could define its base element? Let's look at the example below:

class AwesomeButton extends React.Component {
  render() {
    const { children, tag = "button", ...other } = this.props;
    const Tag = tag;

    return <Tag {...other}>{children}</Tag>;
  }
}

So we have this new property called tag. Tag will be our way of passing in an element/component into AwesomeButton. If the es6 destructing looks different, let me explain. We will pull out the tag prop from this.props. If no value is defined for tag, we will set its default value to be "button" (A Button HTML element).
The next line, const Tag = tag; is so we can fulfill what React's JSX considers a component. All components must be uppercase, where html elements need to be lowercase. Since we are using then variable tag, JSX will always treat the incoming values as a component. So, we have to uppercase our variable.
We now render the prop Tag as our element. Whatever tag equals, that will be our element!

A few examples:

<AwesomeButton onClick={doSomething}>Click Me!<AwesomeButton>

Will render the default button. <button onClick={doSomething}>Click Me!</button>

<AwesomeButton tag="a" href={`/myPage`}>Click Me!<AwesomeButton>

Will render using an anchor tag <a href={'/myPage'}>Click Me!</a>

<AwesomeButton tag={Link} to={`/myPage`}>Click Me!<AwesomeButton>

Will render using a React Router Link component <Link to={'/myPage'}>Click Me!</Link>

Neat! But why is this happening?

JSX Transformations

Our JSX, in the render function, gets transformed into plain jsx functions that the browsers can use. With this in mind, our AwesomeButton's JSX gets transformed into a React.createElement() function with the element name as the first argument.
With the help of our good friend Babel, let's see what different components compile to!

First, let's look at a simple component that just renders a div with the text "test".

class AwesomeButton extends React.Component {
  render() {
    return <div>test</div>;
  }
}

Compiled Example - Click Me!

If we look in the render method, we can see what our JSX actually compiles to.

Well that's cool. So our div element just gets defined as the first parameter of React.createElement. I wonder what happens if we try this with our element injecting AwesomeButton?

class AwesomeButton extends React.Component {
  render() {
    const { children, tag = "button", ...other } = this.props;
    const Tag = tag;

    return <Tag {...other}>{children}</Tag>;
  }
}

<AwesomeButton>Click Me!</AwesomeButton>

Looking at the render method in AwesomeButton:

Woah, our Tag variable just gets put where the element is! This is exactly the same to how components are treated in JSX. They get ploped straight into the first argument of React.createElement. Now, when the boss asks for a new feature in AwesomeButton, we only have to change this one implementation of the component. All consumers of the component might use it vastly differently, but we are able to keep our code DRY and highly reusable!

Intro to FlightJS

Tue, 17 Nov 2015 00:00:00 GMT

This post is part of the archive. These are mainly random posts that were written throughout the years in no coherent order.

FlightJS

FlightJs isn’t the new kid on the block. This little framework has gone unnoticed in Github-land for years. Taken from the FlightJS Github: “Flight is a lightweight, component-based JavaScript framework that maps behavior to DOM nodes.” Reworded, we use reusable components that listen for event calls. These events then in turn perform actions on the DOM or manipulate pieces of our code. Today we will get started with FlightJs, and show how simple it is to use. Though this is an introduction guide, I will assume that we have a fair proficiency with HTML, CSS, and JavaScript.
Getting Started

In this Intro to FlightJS guide we will do what many intro framework guides do, make a counter. Let’s get to work.
Head over to the FlightJS Github, and install FlightJS using your favorite method.
HTML code:

<h1>FlightJS Counter</h1>
<div class="”counter”">
  <h2 class="”counter-total”">0</h2>
  <div class="”counter-function”">
    <a href="”#subtract”" class="”counter-subtract”">-</a>
    <a href="”#add”" class="”counter-add”">+</a>
  </div>
</div>

Counter

To get started, let us create a FlightJS component. Since we will be creating a counter, we’ll create a Counter component.

var Counter = flight.component(function() {
   this.defaultAttrs({});
   this.after(“initialize”, function() {
   });
});

We did a few things in the example above. First, we created a new Flight component called Counter. Next, we defined that we have no default attributes to the Counter component (this will change soon). Attributes provide two big benefits: Component attributes create private variables for a component.

Secondly, attributes give us a way to assign unique data to each instance of a component. Lastly, we have this weird this.after(“initialize”) thing going on at the end. This is where a lot of the power comes from. Flight will execute the function we provide, as the second argument, after the initialize function has ran (initialize is an internal flight function) . Basically we’re telling Flight that once it gets itself in order, let us do what we need to.

So what does a counter need? We need a total number that will be counted on. Oh yeah, and some buttons, that when clicked, either add or subtract one from the total. Let’s add this to our JavaScript.

var Counter = flight.component(function() {
   this.defaultAttrs({
      "subtractSelector": ".counter-subtract",
      "additionSelector": ".counter-add",
      "count": 0
   });
   this.subtract(function() {});
   this.add(function() {});
   this.after(“initialize”, function() {
     this.on("click", {
        "subtractSelector": this.subtract,
        "additionSelector": this.add
     });
   });
});

First we added some attributes. These attributes provide us a DOM element for our subtract and add buttons—named subtractSelector and additionSelector respectively—and defines our starting number count. We then created some stubbed functions for once the selector’s event is triggered. Finally, an event handler is created. this.on(“”) creates an event binding it to whatever we define within the quotes. In this case, we are waiting on a click event to be performed on our DOM selectors subtractSelector and additionSelector. Once a click is recognized, the corresponding function is called. (this.subtract() or this.add())

Continuing, here is our finished code:

var Counter = flight.component(function() {
   this.defaultAttrs({
      "subtractSelector": ".counter-subtract",
      "additionSelector": ".counter-add",
      "count": 0
   });
   this.subtract = function() {
      this.attr.count--;
   }

   this.add = function() {
      this.attr.count++;
   }

   this.uiDisplayCount = function() {
      this.$node.find(“h2.counter-total”).html( this.attr.count );
   }

   this.after("add subtract", function() {
      this.uiDisplayCount();
   });
   this.after(“initialize”, function() {
     this.uiDisplayCount();
     this.on("click", {
        "subtractSelector": this.subtract,
        "additionSelector": this.add
     });
   });
});

Finally we get functionality. The subtract and add function perform a -1 or +1 on the total count depending on which event is triggered. Once we perform these actions on our count, we have no way of displaying the new information. This is where this.uiDisplayCount plays its role. From any jQuery enthusiast, this function is straight forward. Take our count attribute, and insert it into the html of .counter-total. But, what is this.$node? This.$node is a property given to us from Flight that grabs a jQuery object of the DOM this component is attached to. Later on we will attach the Counter component to the DOM, and see how this plays out. Going to the next function, we tell our component to execute the uiDisplayCount function after the add or subtract functions are done being executed.

Now there is one thing missing, how do we actually attach this to the DOM?
Counter.attachTo(“.counter”, { count: 100 });

Going back to before, our this.$node property would return a jQuery object of our .counter, $(“.counter”). As we can see by the second parameter, we can also change what our default attributes are once we attach the component. This helps enforce the modular code Flight preaches. We can change the attributes to fit whatever the situation.

Counter.attachTo(“.counter”, { count: 100 });
Counter.attachTo(“.counter-new”, {
                   count: 0,
                   subtractSelector: ".new-subtract"
                });
Counter.attachTo(".counter-new-new", {
                   subtractSelector: ".s",
                   additionSelector: ".a"
                });

We Did It

And that is it, we completed our counter! We can see from this little example, Flight gives us some powerful tools in creating modulated code without the need to learn new paradigms. As always, there is much more Flight can do. For additional information on Flight check out their Github.

Counter Example

Here is our finished product: http://codepen.io/ganderzz/pen/pjNdNq