Forem: Jacob Paris

A tech interview that doesn't suck

Jacob Paris — Fri, 09 Jul 2021 12:09:53 +0000

One of the many major things the tech industry is bad at is job interviews.

No other profession has so little correlation between candidates who are good at interviews and good at the job they are interviewing for. Most tech interviews focus on testing skills that have nothing at all to do with the kind of work the candidate would be doing day-to-day.

Good tech interviews are equally accessible to self-taught, bootcamp, or college graduates, and don't prefer developers who have enough free time to dedicate to drilling code trivia.

Good tech interviews favour candidates who are:

Comfortable solving problems autonomously
Able to recognize gaps in their knowledge
Learn things as they need to know them
Able to maintain their code as requirements change

Instead of white-boarding, code challenges, or testing knowledge of algorithms, I prefer to test candidates by giving them a small take-home TODO list application, written any way they want, followed by a live-coding segment where they add three small features.

Writing code and then adding features to that code models exactly what developers are expected to do on the job. Developers who have the time to practice LeetCode questions aren't better at writing TODO applications than developers who don't. Stanford has a class teaching how to pass the google exam, but Stanford students don't get an advantage here.

TODO applications are the most common tutorial, so almost every developer has interacted with one at some point. They don't require complex algorithms which are only taught in universities, and there are so many unique ways to build them depending on the developer's preferences, skills, and choices.

If you're hiring Frontend engineers, Backend engineers, DevOps engineers, or QA engineers, a TODO application can be written to stress the important skills for each role.

This is the spec I've used for dozens of interviews, made generic enough to allow the candidate shape the application to best demonstrate their abilities.

The Take Home Project

Imagine the business has asked you to build a simple todo list application for the web.

Requirements

The user should be able to view a list of tasks
Each task should contain a title
The user should be able to create a task
The user should be able to edit a task
The user should be able to mark a task completed

Try to spend no more than 3 hours of work on this assignment. If some areas lack polish, it will be reviewed with the understanding that there was a narrow time constraint.

Use whatever tools, frameworks, and languages that you are most comfortable with. There are no extra points for using the same tech stack that we use. The more confident you are with the tools you've chosen, the more impressive your application will be. If you excel in a particular area, choose an architecture that allows you to demonstrate that.

The application can be server side, client side, or both
Data can be persisted to a database, to local storage, or not at all
Tests can be end-to-end, integration, unit, or none at all

Create a repository on your preferred source control host (GitHub, Bitbucket, GitLab, etc) and commit your code to it, along with a README.md file that explains how to install and run the app. These instructions could be as simple as "clone the repo, run npm install, run npm start" but some projects take longer to set up.

When you're finished, email the interviewer with a link (and invite if the repository is private).

The Follow-Up Interview

Most candidates are nervous in interviews regardless of their confidence level on the job. Try to understand that getting or not getting the job will change the course of their career in one direction or the other.

Start the interview with a few minutes of small-talk to establish a bit of rapport and get the candidate more comfortable speaking on camera.

If you haven't already confirmed whether the candidate is legally able to get the job, do that now. Even if the requirements were listed explicitly in the job posting, don't assume it's been read or understood. In general, hiring contractors, even from out-of-country, is far easier than hiring employees and you'll have fewer questions to ask.

For employees, you should determine if they're legally allowed to work in your country. For example, whether or not they're a citizen or a permanent resident or if they're on a work visa. If they're on a work visa, see how long it's eligible for and when it's going to expire. If you're looking to hire someone who will last a year or more at your company but their visa is due to expire in six months, that's something you want to find out sooner rather than later.

Ask where they're currently living. This may not be the city they have listed on their resumé or online profiles or any other documentation you've seen so far. It's important to make sure that the hours they intend to work are compatible with the rest of the team. Even if you're fully asynchronous, it's good to have an idea of when they can be expected to be online.

I'd also recommend you ask what timeframe they would be looking to start once hired. Some candidates will be able to start right away and others might need weeks to transition from their current job, especially if they're relocating.

The Live-Coding Segment

Being able to see how people maintain code they've written themselves is a great signal for a developer who knows what they're doing

To maintain code is to modify it to handle a changing set of requirements.

Have the candidate share their screen as you move into the live-coding portion of the interview. It's a good idea to remind them to turn on Do not Disturb mode so that no notifications appear while they're sharing. If they have a large screen, encourage them to zoom in or increase font size so their code is legible.

Be prepared to walk them through allowing screen sharing permissions if they haven't already allowed those.

I start by having them walk through the code, pointing out anything notable in their implementation

They may have chosen to use a simple non-scalable architecture because that's all that the requirements of this demo project demanded. They also could have chosen to over-engineer the code as a demonstration of how they would handle a more complex project. Either decision is rational

Be careful about prodding these questions on your own so you don't hint at preferring one decision over the other. If the candidate feels like they've already made a mistake, they're less likely to perform as confidently in the interview as they would on the job.

Time-boxing this portion of the interview is a good idea. 45 minutes for the whole segment gives 15 for each task, and you can warn them if they're spending too long on any particular one.

Exercise 1: Permanently delete all completed tasks

Add a button that deletes all the tasks that have been marked as complete.

The usual solution here is to replace the list of tasks with a new array that contains only the incomplete tasks.

An easy way to make the new array is using Javascript's native array filter

const incompleteTasks = tasks.filter((task) => !task.completed)

The candidate might prefer stepping through the list of tasks in a loop to build the new array manually.

const incompleteTasks = []
for (const task of tasks) {
  if (!task.completed) {
    incompleteTasks.push(task)
  }
}

Another solution would be to remove the completed tasks directly from the list without making a new array. This can be tricky because they're stepping through the list one by one but also removing tasks from it, so it's easy to accidentally skip an item. If the candidate presses the button with two tasks in a row marked complete, and it fails to delete the second one, this is usually the reason why.

for (let i = 0; i < tasks.length; i++) {
  if (task.completed) {
    tasks.splice(i, 1) // Remove task number i
    i-- // If we deleted task 4, task 5 will slide up into its spot, so we need to check task 4 again next
  }
}

Exercise 2: Sort tasks in descending order

Sort tasks in descending order, so that new items are added to the top of the list instead of the bottom.

If the candidate is not currently storing dates on each task, that's the first step, but it's up to them to determine that. They'll have to add dates to any new tasks they're adding plus any they might have stored to show up by default (if any).

There are a few ways to cheat here that should be discouraged. At the moment, every new task appears at the bottom of the list. That makes it look like it's already sorted in ascending order. The candidate might be tempted to render tasks.reverse() or to add new tasks to the beginning of the array instead of the end.

This only works by coincidence, and as soon as it's possible to add tasks with past or future dates, this fake sorting will break.

The usual solution is using javascript's native sort method. After giving this question to dozens of candidates I've concluded that no one remembers how this method works. To me, this question is an exercise on whether the candidate is able to look up documentation to patch their knowledge on anything they're missing, which is an incredibly valuable skill to screen for.

Sort works by comparing two tasks (A and B) in the list and returning -1, 1, or 0, depending on whether task A should be sorted before, after, or equally with B.

tasks.sort((a, b) => {
  if (a.dateCreated < b.dateCreated) return -1
  if (a.dateCreated > b.dateCreated) return 1

  return 0
})

Using ternary is common here. It's not a big deal if they don't handle the 0 case for identical dates.

tasks.sort((a, b) => {
  return a.dateCreated < b.dateCreated ? -1 : 1
})

If the dates are stored as a number (for example, a timestamp rather than a date), they might just subtract them. I'm less fond of this but it's incredibly common.

tasks.sort((a, b) => {
  return a.dateCreated - b.dateCreated
})

When candidates implement the sort method incorrectly, common mistakes are to compare a - b directly, instead of a.dateCreated - b.dateCreated, or to return true or false instead of 1 or -1. Nudge them toward the documentation if they're making these sorts of mistakes. Sometimes candidates try too hard not to look anything up during the interview even if they would be quick to do so on the job, so extra encouragement can help.

When candidates implement the sort method correctly, the most common mistake here is to accidentally sort the wrong way first. If their sort doesn't appear to work the first time, it might be sorting into ascending order (which looks like nothing has changed). Most candidates will test swapping the order on their own, but feel free to suggest that if they seem confused.

The second most common mistake is forgetting that the sort method mutates the original array. If they've built all their code from scratch, this probably won't be an issue, but frameworks like React and Vue will throw errors if they mutate state variables. There are a few ways to clone the list of tasks before running sort, including Array().concat(tasks).sort, tasks.slice().sort, [...tasks].sort, or by chaining sort after a map or filter operation. If they're having trouble with this one, explain the problem, but give them time to find their own solution.

Exercise 3: Split the tasks into two lists

Split the tasks into two lists, with incomplete tasks on top, completed tasks on the bottom, such that marking a task as complete moves it from one list to the other.

It's up to you as the interviewer whether you require the sorting to still be in effect for this exercise. It's simpler if you don't, but optional.

The ideal implementation is also the simplest: keep one main array of tasks, and render two lists filtered to either complete or incomplete.

That might look something like this

const completeTasks = tasks.filter((task) => task.complete)
const incompleteTasks = tasks.filter((task) => !task.complete)

The more challenging implementation, which I've seen several candidates attempt but never complete within the time allowed, is to maintain two separate lists of tasks and move items from one to the other when marking as complete or incomplete. If they start to run out of time, I would suggest the simpler solution, but give them time to come to that conclusion on their own. The ability to realize when they're going down the wrong path and re-evaluate their chosen solution is a good skill to have, and this is a good place to watch for it.

The Developer's Guide to Hoisting

Jacob Paris — Wed, 01 Jul 2020 20:34:15 +0000

Languages like Java and the C Family are compiled – that is, the code we write is not the code that gets executed. Compilers read, parse, disassemble, analyze, and eventually, reassemble the code into a series of instructions that the processor can understand.

Javascript is not[1] one of these languages.

If you ask a javascript runtime engine (like V8, which powers Chrome, Slack, VS Code, the occasional Mustang, and Figma) to run a bit of code, it will execute it line by line top to bottom in much the same way a human might read it.

If I were to start talking about the milk protein casein, you would be hard pressed to follow the conversation, and for good reason too. First of all, this is a technical article about Javascript. Second of all, I don't introduce that topic for another several paragraphs.

In the same way that you, a human, are reading this article from top to bottom with no expectation that you've read the words you haven't read yet, an interpreted language like Javascript reads your code from top to bottom with no expectation that it's read the code it hasn't read yet.

Therefore, the code

console.log(cheese) // ! Error
let cheese = 'mozzarella'

would predictably be met with the error 1: Uncaught ReferenceError: cheese is not defined

In our universe, cheese is defined as a dairy product formed by the coagulation of milk proteins, and has been defined as such since 8000 BCE. But in the universe created by Javascript to run our code, a parser on line 1 is equally as confused at the unknown variable as a primitive 9000 BCE human would be faced with a plate of gouda[2].

Aside: For those readers studying in preparation for a technical interview, it is at this point in the interview where you present a surprise dish of camembert, or, for extra credit, brie.

To eliminate some of the confusion, Javascript has some optimizations in place.

Before Javascript starts trudging through each line of code, it does a quick scan for anything interesting that might be useful to know in advance. One thing Javascript finds particularly interesting is when a variable is declared with the var keyword.

For example, this code

console.log(cheese) // undefined
var cheese = 'mozzarella'

unintuitively does not result in an error at all.

Unlike let and const, the var keyword is hoisted. Hoisting means that Javascript will make note of it on its initial scan before running the code. By the time your code is running, it actually looks like this:

var cheese
console.log(cheese) // undefined
cheese = 'mozzarella'

You may be thinking such questions as "But why?" and "So it doesn't hoist the assignment?" and "How does that help anything?"

These are all excellent questions and I hope one day someone smarter than I can come up with a reasonable answer.

Until then, variable hoisting is more or less useless, and you can rest easy knowing that all the effort involved in dealing with this particular bit of trivia consists entirely of learning it exists.

Luckily for Javascript, and for those who enjoy actually doing something with the concepts they learn, var declarations aren't the only thing that gets hoisted.

Of the five ways to write functions in javascript, the named function declaration is the only one that is hoistable.

const sausage = slice('cacciatore')

function slice(sausage) {
  return sausage.split('')
}

Once javascript is done looking for var keywords to hoist, it embarks on the much more useful task of hoisting all the named function declarations.

Any function declared in the form function name() { } will be accessible throughout its entire scope, and that has opened the doors to new ways of writing code.

Some developers enjoy listing their module exports at the highly visible top of the file, and letting the implementation details settle down to the bottom where they can be easily ignored.

export default {
  create,
  read,
  update, 
  delete // [3]
}

function create() { … }
function read() { … }
function update() { … }
function delete() { … }

If ever there was a need for two functions to call one another, hoisting makes that possible too

// Flips a switch at $0.25 a flip until it runs out of money
function turnOn(quarters) {
  if (quarters > 0) {
    turnOff(quarters - 1)
  }
}

function turnOff(quarters) {
  if (quarters > 0) {
    turnOn(quarters - 1)
  }
}

[1] While Javascript is traditionally an interpreted language and not a compiled one, that fact has been getting less and less true as time goes on. Currently, the plan is to compile it just-in-time during the first interpretation. The second time a block of code is read, Javascript is instead reading the compiled instructions for performance reasons.

[2] Assuming you used era-appropriate dishware and cheese can be isolated as the only new concept being introduced, to reduce statistical noise

[3] Javascript treats delete as a reserved keyword, but CRUR doesn't roll of the tongue quite so nicely

How To For Loop Through Anything in JS

Jacob Paris — Tue, 07 Apr 2020 23:48:37 +0000

There are now four ways to open a for loop in javascript

For of
For await of
For in
Classic For

While they differ a bit on speed and the variables they declare implicitly, the actual body of the for loop doesn't change much between the different methods.

The easiest way to loop through an array is with the for…of loop

const fruits = ['apple', 'banana', 'cherry']

for (const fruit of fruits) {
  console.log(fruit)
}

// apple
// banana
// cherry

We're not limited to arrays though, since all iterators work the same in javascript. That means we can just as easily loop through a string

for (const letter of "javascript") {
  console.log(letter)
}

// j
// a
// v
// a
// s
// c
// r
// i
// p
// t

Many emojis are stored as multiple codepoints, and some emojis are created by joining multiple other emojis.

For…of will iterate over them one by return, returning every 👨 in a 👨‍👩‍👧‍👦

for (const person of "👨‍👩‍👧‍👦") {
  console.log(person)
}

// 👨
// 👩
// 👧
// 👦

We can use the return keyword to break out of a function early. In a loop, we can use the continue keyword to break out of the current iteration and start the next iteration immediately.

const sequence = [0, 1, 2, 3, 4, 5]

for (const number of sequence) {
  if (isOdd(number)) continue

  console.log(number)
}

// 0
// 2
// 4

Loops also have the break keyword, which will cancel not only the current iteration but also the rest of the loop

const sequence = [0, 1, 2, 3, 4, 5]

for (const number of sequence) {
  if (number >= 3) break

  console.log(number)
}

// 0
// 1
// 2

At the end of every iteration, the current scope is discarded and a new one is opened, so it's ok to use const or let at the start

for (const item of items)
// or
for (let item of items)

If you try to use await inside a loop, the execution will pause until the promise resolves and then it'll proceed as usual. To allow the loops to proceed concurrently, you can either await the promises before starting the loop or using for await of to do the same thing

for (const x of await Promise.all(arrayOfPromises))
// or
for await (const x of arrayOfPromises)

In javascript, objects are not strictly iterable. If you want to loop through the keys of an object, you can either use for in or convert the keys to an array

const hashMap = {
  abcd: { … },
  abce: { … },
  abcf: { … },
  abcg: { … },
  abch: { … }
}

for (const key of Object.keys(hashMap)) {
  const value = hashMap[key]
}
// or 
for (const key in hashMap) {
  const value = hashMap[key]
}

If the only thing we need the key for is to access the value, we can skip a step and loop through the values directly

for (const value of Object.values(hashMap) { … }

If we need both key and value, my preferred method is to use Object.entries, which returns a [key, value] pair, and destructure them right in the head the loop

for (const [key, value] of Object.entries(hashMap)) { … }

Since arrays are just objects with numeric keys, we can use that same syntax to get the index of our array elements inside our loop

for (const [i, element] of Object.entries(array)) { … }

To run a loop a specific number of times, we can create an array with that many elements and then loop through it.

Iterators skip over empty array slots, so we need to fill it with at least undefined first, and then optionally map its index

const array = Array(25).fill() // [ empty, empty, empty, …]
// or
const array = Array(25).fill().map((_, i) => i) // [ 0, 1, 2, … ]

for (const i of array) { … }

The other option is to use the classic for loop syntax. This gives you the most control at the cost of readability.

for (let i; i < 25; i++) { … }

XState Text Formatting Part 3

Jacob Paris — Tue, 07 Apr 2020 21:31:08 +0000

In the previous article, we modelled a set of buttons that would allow the user to align text to the left, center, right, or justified alignments. To view the previous entry in the series, read XState Text Formatting Part 2

In this article, we will explore what happens when the user presses the return/enter key.

Word processors allow the user to create lists. Lists can be either unordered (bulleted) or ordered (numbered). Unlike the alignment, however, we can also opt out of either state and use regular paragraphing. That gives us three distinct states for this feature:

Paragraph
Numbers
Bullets

Here we have two toggle buttons: one of which will toggle numbers (and deselect bullets if it was selected), and the other of which will toggle bullets (and deselect numbers if it was selected). That's not something we can model by lifting state up to the parent, so the events will have to be on each child.

Example: https://xstate.js.org/viz/?gist=1a27cf4ddb397f593a7008769e3e69ed

References

Constructing the user interface with state charts (Addison Wesley, 1999)

XState Documentation

XState Text Formatting Part 2

Jacob Paris — Sun, 05 Apr 2020 16:34:59 +0000

This is part 2 of a series on modelling UI components in XState. To view the previous entry in the series, read XState Text Formatting Part 1

In the previous article, we explored using a parallel state machine to track three distinct formatting features of a word processor: bold, italic, and underline

Each of those buttons operated independently of one-another. In this article, we'll look into modelling how a word processor would let a user select the text alignment. There are four possible states of the alignment

Left
Center
Right
Justify

While the alignment operates independently of the bold, italic, and underline states, the alignment directions are not independent of one-another.

They act like a group of radio buttons, where selecting one inherently unselects another, in the same way that enabling 'bold.on' unselects 'bold.off'. For that reason, we can model them as finite states.

By clicking any of the left, right, center, or justify buttons, we want to transition to that state. There is no un-selecting here though, so each state will have only three transitions pointing to each of the other states

Example: https://xstate.js.org/viz/?gist=364dea11f6cc0e1692ca139085f41fae

There is a many-to-many relationship between these states. We can simplify this model by understanding two things about it:

Every state is connected to every other state
A transition with a specific event always terminates at the same state

Those facts allow us to lift events up from the individual sub-state to the parent state, and model it as four one-to-one relationships. Now no matter which state it is in, the RIGHT event will transition to the 'align.right' state and so on for the rest of them.

This state chart is functionally identical to the previous, with one exception: clicking LEFT while in the 'align.left' state will now cause a self-transition. Any entry action on the state will fire again on such a self transition, which might not be expected behaviour, but for most cases shouldn't be an issue.

Example: https://xstate.js.org/viz/?gist=b020d1096efd3dbc3aa9868894604392

The next part in the series is here at XState Text Formatting Part 3

References

Constructing the user interface with state charts (Addison Wesley, 1999)

XState Documentation

Modelling parallel states in XState

Jacob Paris — Sun, 05 Apr 2020 02:19:31 +0000

The number of states in a system can grow rapidly as features are added, and without proper state management it can get unwieldy quickly. Consider a word processor. They offer three distinct ways to format text.

Bold
Italic
Underlined

Each of these buttons can be toggled on or off, independently of any other. Since each button has 2 states, and there are 3 buttons, that gives us 2^3 = 8 permutations of these three variables

Kyle Shevlin created a fun site to help demonstrate how quickly these can get out of hand here at Heard You Like Booleans

When the user toggles the bold button, we want that to move from either a non-bold state to a bold state, or the reverse. We can model this with a BOLD action that transitions from unformatted to bold and vice versa.

The same pattern can be applied to the italic and underlined states, as well as every permutation thereof.

To try it out, you can walk through the machine here with the XState Visualizer

https://xstate.js.org/viz/?gist=287ae37cfc1db9c5c098ea3ae4057a60

Modelled this way, the complexity of such a simple set of states is very clear, and this represents one of the shortcomings of both finite state machines and classic boolean state handling. What happens when we want to extend this? A user of our word processor should be able to align text to the left, right, centered, or justified. We'd end up with 32 distinct, finite states.

State Charts are an extension of the finite state machine, allowing us to store extended state within the diagram.

Looking back at our model, we have 3 independent toggle buttons. While changing one affects the final state we end up in, it does not affect the state of either of the two other buttons. State charts give us the opportunity to model them independently with parallel states.

Parallel states differ from classic states in that the machine is in every state at once. The default state is simultaneously format.bold.off, format.italic.off, and format.underlined.off

The simplicity of this approach is even more apparent once we add the transitions between states

Example: https://xstate.js.org/viz/?gist=b9a8e4db654cea07fe2080bd56b6cdc7

The next part of this series is here at XState Text Formatting Part 2

References

Constructing the user interface with state charts (Addison Wesley, 1999)

XState Documentation

How to Center Anything in CSS

Jacob Paris — Thu, 02 Apr 2020 20:22:51 +0000

CSS is full of nuances that can be pretty confusing for beginners. Over the last 20 years, developers have had to come up with many methods for building out layouts, and as the language evolves we have better and better solutions.

I recently made a tweet that mashed together several of these solutions into one single unusable broken class, so now in a more helpful manner I'm going to explain the real patterns to use

Jacob Paris 🇨🇦

@jacobmparis

hey everyone I finally solved centering things in CSS

03:36 AM - 01 Apr 2020

The Text Align Method

To center all the text within a container, you can use the css rule text-align: center;

This will apply to all inline elements — that is, anything that flows like text

<div style="text-align: center">
  This will center all inline elements

  <br />

  <span>
    Spans are inline elements by default
  </span>

  <br />

  <div style="display: inline-block;">
    Inline blocks are also affected
  </div>
</div>

Example here: https://codepen.io/jacobparis/pen/BaNEbVQ

The Line Height Method

To center text vertically, you can use the vertical-align: middle; rule. It's important to note that this only aligns characters within their line height. For example, you can use this rule to set text to superscript or subscript positioning, but it still flows the same.

If you want to center text vertically within its container this way, you'll need to make sure the line-height property has the same height as the container.

<div style="height: 200px; text-align: center;">
  <span style="vertical-align: middle; line-height: 200px;">
    This will center all inline elements
  </span>

  <div style="display: inline-block;">
    Inline blocks are also affected
  </div>
</div>

Example here: https://codepen.io/jacobparis/pen/RwPOdza

The Background Position Method

This only works for images (and SVG!) that you want to set as backgrounds to other elements. For <img /> tags, you can use any of the methods that work on divs.

The rule here is background-position: center;

<div style="
  height: 300px;
  background-image: url('http://placekitten.com/200/200');
  background-repeat: no-repeat;
  background-position: center;
"/>

Example here: https://codepen.io/jacobparis/pen/rNVbgBO

The Margin Auto Method

Block elements are max width by default, so horizontally centering doesn't mean anything until you set its width explicitly.

An artificially narrow div defaults to the left, (or right in RTL scenarios), but you can force it center with margin-left: auto; margin-right: auto;

A common shorthand for the same margin is margin: 0 auto; and since we don't care about vertical margin here nothing stops us from doing margin: auto; either

<div>
  <div style="max-width: 300px; margin: 0 auto;">
    This is a centered div
  </div>
</div>

Example here: https://codepen.io/jacobparis/pen/RwPOOwR

The Position Absolute Method

Of all the methods, this is the most extreme. Instead of letting the browser calculate where the element should be at all, we're setting it explicitly.

Important here is that if you want to center something within a container, the container must have position: relative;. That's what tells the absolute position what to base its coordinates off of.

position: absolute;
left: 0;
right: 0;
top: 0;
bottom: 0;

Essentially, you're anchoring the edges of your element to the edges of its container, which makes it exactly the same size. If you then set the width or height explicitly AND use the Margin Auto Method, it ends up suspended between the edges

If you only want horizontal or vertical centering, you can leave out the other axis

<div style="height: 500px; position: relative;">
  <div style="
      position: absolute;
      left: 0;
      right: 0;
      bottom: 0;
      top: 0;
      width: 100px;
      height: 200px;
      margin: auto;">
    This is an absolutely positioned centered div
  </div>
</div>

Example here: https://codepen.io/jacobparis/pen/RwPOOwR

The Absolute Offset Method

The trouble with the previous method is you need to set the width and height explicitly. But what if your content changes dynamically? We have another solution!

Instead of setting all four corners, only set left: 50%; and top: 50%;. That will position the top left corner of your element in the center of its container.

Then you can use CSS Translate to shift the child by half of its own width and height up and to the left, landing in perfectly in the center

<div style="height: 200px; position: relative;">
  <div style="
      position: absolute;
      left: 50%;
      top: 50%;
      transform: translate(-50%, -50%);">
    This is an absolutely positioned centered div with dynamic position
  </div>
</div>

Example here: https://codepen.io/jacobparis/pen/bGdJJJm

The Flexbox Method

Flexbox is the biggest game-changer to ever hit CSS, and it makes centering a snap.

The key to flex is to understand that parent elements are responsible for laying out their children. If you try to make every element position itself, you're gonna have a bad time.

Since a flex parent is responsible for its children's position, it doesn't matter whether they're inline or block elements. That makes no difference anymore. Instead of inline and block, think in terms of flex-parents and flex-children

The element with display: flex; is the flex-parent, and it only controls direct children, not further descendants.

<div style="
  height: 300px;
  display: flex;
  justify-content: center;
  align-items: center;
">
  <div>
    This is a flex-child
  </div>
  <span>
    This is a flex-child
  </span>
  <div>
    This is a flex-child
  </div>
</div>

Example here: https://codepen.io/jacobparis/pen/poJBBpq

The Grid Method

CSS Grid is extremely powerful but more advanced than I'd like to get into today. If you just want to center items, the pattern is pretty close to flexbox — just change it to display: grid;

If there were one single element here, it'd be perfectly centered (and that goes for flexbox too)

<div style="
  height: 300px;
  display: grid;
  justify-content: center;
  align-items: center;
">
  <div>
    This is a flex-child
  </div>
  <span>
    This is a flex-child
  </span>
  <div>
    This is a flex-child
  </div>
</div>

Example here: https://codepen.io/jacobparis/pen/poJBBpq

Grid (Place Items)

One other thing I'd like to note is the place-items: center; property, which works on CSS Grid like a combination of justify-content, align-items, and text-align all at once

display: grid;
place-items: center;

Async Functions from Start to Finish

Jacob Paris — Sun, 29 Mar 2020 02:23:39 +0000

Functions

A function is a block of code that can be called and executed at will

function setTitle() {
  document.title = 'Async, Await, and Promises'
}

This gives us a function named setTitle. To execute it, call it by name with parentheses after, like setTitle()

Before:

After:

Arguments

Functions can also have arguments, which are variables you pass into a function when you call it.

function setTitle(title) {
  document.title = title
}

setTitle('Async, Await, and Promises')

This makes functions much more reusable, since you can call it with any value you want

setTitle("Who me?")
setTitle("Yes you.")
setTitle("Couldn't be")
setTitle("Then who?")

Callbacks

When you call a function, sometimes it can call back to another function

The setTimeout function accepts two arguments: a callback function, which it executes when it's finished waiting, and a delay, which is the number of milliseconds to wait

function setTimeout(callback, delay)

We can use this to call our original setTitle function automatically after one second.

function setTitle() {
  document.title = 'Async, Await, and Promises'
}

setTimeout(setTitle, 1000)

This works since we're setting the title explicitly, but if we try to pass it in as an argument it just clears the title, shown below

function setTitle(title) {
  document.title = title
}

setTimeout(setTitle, 1000)

What happened? Since the callback (setTitle) is executed by the function (setTimeout) we don't have control over what arguments setTitle is called with.

So instead of passing setTitle as our callback, we can make our callback a wrapper function instead

// Pattern 1: Named Function
function wrappedSetTitle() {
  setTitle('Async, Await, and Promises')
}
setTimeout(wrappedSetTitle, 1000)

// Pattern 2: Anonymous Function
setTimeout(function () {
  setTitle('Async, Await, and Promises')
}, 1000)

// Pattern 3: Arrow Function
setTimeout(() => {
  setTitle('Async, Await, and Promises')
}, 1000)

// Pattern 4: Inline Arrow function
setTimeout(() => setTitle('Async, Await, and Promises'), 1000)

Now setTimeout will wait until 1000 milliseconds have passed, then invoke our wrapper function which calls setTitle with a title of our choice

Promises

We saw how to create functions and use them as callbacks

A Promise is a class that executes a callback and allows you to trigger other promises when the callback completes or fails.

function promiseTimeout(delay) {
  return new Promise((resolve) => {
    setTimeout(() => resolve(), delay)
  }).then(() => {
    setTitle('Async, Await, and Promises')
  })
}

promiseTimeout(1000)

There's a lot going on here, so we'll break it down from the inside out

First, setTimeout waits until the delay is up, then triggers the callback by running the Promise's resolve() function

The callback to a Promise is defined by chaining a method called .then(callback)

Right now it seems like it's just a more complicated way of writing callbacks, but the advantage comes in when you want to refactor

function promiseTimeout(delay) {
  return new Promise((resolve) => {
    setTimeout(() => resolve(), delay)
  })
}

promiseTimeout(1000)
  .then(() => setTitle('Async, Await, and Promises'))

The .then() method always returns a promise. If you try to return a regular value, it will return a promise that resolves instantly to that value

Since it returns a promise, you can chain .then() onto the result indefinitely

So either of these patterns are valid

promiseTimeout(1000)
  .then(() => {
    setTitle('Async, Await, and Promises')
    setTitle('Async, Await, and Promises')
    setTitle('Async, Await, and Promises')
  })

promiseTimeout(1000)
  .then(() => setTitle('Async, Await, and Promises'))
  .then(() => setTitle('Async, Await, and Promises'))
  .then(() => setTitle('Async, Await, and Promises'))

If the callback passed to .then() is a promise, it will wait for the promise to resolve before executing the next .then()

promiseTimeout(1000)
  .then(() => setTitle('One second'))
  .then(() => promiseTimeout(5000)
  .then(() => setTitle('Six total seconds'))

Constructor

One way to create a Promise is through the constructor. This is most useful when you're wrapping a function that uses non-promise callbacks.

const promise = new Promise((resolve, reject) => {
  resolve(data) // Trigger .then(callback(data))
  reject(error) // Trigger .catch(callback(error))
})

To use a real-world example, Node.js has a method for loading files called readFileAsync that looks like this

fs.readFileAsync('image.png', (error, data) => { })

If we want to turn that into a promise, we're going to have to wrap it in one.

function getImage(index) {
  return new Promise((resolve, reject) => {
    fs.readFileAsync('image.png', (error, data) => {
      if (error) {
        reject(error)
      } else {
        resolve(data)
      }
    })
  })
}

Tip: Node.js includes a promisify method that transforms a function that uses traditional callbacks to one that returns a promise. The implementation is exactly like the example above.

Class Method

Another way to create a promise is use the static class methods

Promise.resolve('value') will return a resolved promise. It will immediately begin to execute the next .then() method it has, if any.

Promise.reject('error') will return a rejected promise. It will immediately begin to execute the next .catch() method it has, if any.

function getProducts() {
  if(!isCacheExpired) {
    return Promise.resolve(getProductsFromCache())
  }

  // The built-in method fetch() returns a promise
  return fetch('api/products') 
    .then(response => response.json())
    .then(products => {
      saveProductsToCache(products)

      return products
    })
}

Imagine you're trying to download a list of products from an API. Since it doesn't change very often, and API requests can be expensive, you might want to only make API requests if the list you already have is more than a few minutes old.

First we check if the cache has expired, and if not we return a promise resolving to the products we've already saved to it.

Otherwise the products are out of date, so we return a promise that fetches them from the API, saves them to the cache, and resolves to them.

Catch

While .then() triggers when a previous promise resolves, .catch() triggers when a previous promise either rejects or throws an error.

If either of those happen, it will skip every .then() and execute the nearest .catch()

fetch('api/products') 
  .then(response => response.json())
  .then(products => {
    saveProductsToCache(products)

    return products
  })
  .catch(console.error)

If .catch() returns anything or throws another error, it will continue down the chain just like before

Async Functions

To make writing promises easier, ES7 brought us the async keyword for declaring functions

A function declared with the async keyword always returns a promise. The return value is wrapped in a promise if it isn't already one, and any errors thrown within the function will return a rejected promise.

Usage

This is how to use it in a function

async function getProducts() { }

const getProducts = async function() => { }

const getProducts = async () => { }

And in a method:

const products = {
  async get() { }
}

Return

Whenever an async function returns, it ensures its return value is wrapped in a promise.

async function getProducts() {
  return [
    { id: 1, code: 'TOOL', name: 'Shiny Hammer' },
    { id: 2, code: 'TOOL', name: 'Metal Corkscrew' },
    { id: 3, code: 'TOOL', name: 'Rusty Screwdriver' },
    { id: 1, code: 'FOOD', name: 'Creamy Eggs' },
    { id: 2, code: 'FOOD', name: 'Salty Ham' }
  ]
}

getProducts()
  .then(products => {
    console.log(products)
    // Array (5) [ {…}, {…}, {…}, {…}, {…} ]
  })

Throw

If an async function throws an error, it returns a rejected promise instead. This can be caught with the promise.catch() method instead of wrapping the function in try/catch statements

async function failInstantly() {
  throw new Error('oh no')
}

failInstantly()
  .catch(error => {
    console.log(error.message)
    // 'oh no'
  })

In a regular function, you need to catch errors using the classic try/catch statement syntax

function failInstantly() {
  throw new Error('oh no')
}

try {
  failInstantly()
} catch (error) {
  console.log(error.message)
  // 'oh no'
}

Await

The other difference between regular functions and async functions is that async functions allow the use of the await keyword inside.

Await works like the .then() method, but instead of being a chained callback, it pulls the value out of the promise entirely.

Consider the previous example

getProducts()
  .then(products => {
    console.log(products)
    // Array (5) [ {…}, {…}, {…}, {…}, {…} ]
  })

And the same with await

const products = await getProducts()

console.log(products)
// Array (5) [ {…}, {…}, {…}, {…}, {…} ]

It's important to remember that since await can only be used inside async functions (which always return a promise) you can't use this to pull asynchronous data out into synchronous code. In order to use await on a promise you must be inside another promise.

React Hooks: UseEffect, UseMemo, UseCallback

Jacob Paris — Sun, 29 Mar 2020 01:35:09 +0000

React ships with a whole bunch of hooks that can be a bit tough to grasp when you're learning them all at once. This post should help you understand the differences and use-cases of three of them.

UseEffect

A pure component only interacts with itself and its children. Any time you need to interact with the world outside your component, you are dealing with side-effects.

React gives us a handy hook for dealing with these. the React.useEffect hook lets us specify a function that deals with external forces, provide a second function to clean up after it, and drop a list of dependencies so we can re-run the effect when one of the dependencies change.

Examples of useEffect

Updating the page title

This effect will run the first time the component is rendered, and then only ever run again if the title has changed.

const [title, setTitle] = React.useState("Hooks 101");

React.useEffect(() => {
    document.title = title;
}, [title]);

Fetching data from an API into local state.

Since our state changing will not affect the list of products that is returned, we can pass an empty array [] as our dependency so that the effect will only run when the component is first mounted.

const [products, setProducts] = React.useState([]);

React.useEffect(() => {
    getProducts()
    .then(products => {
        setProducts(products);
    })
}, []);

Fetching data from an API into local state, based on a query.

If we have a query or filter to modify the set of API data we want, then we can pass it as a dependency to make sure that React runs this effect every time the component renders using a new query.

const [products, setProducts] = React.useState([]);
const [query, setQuery] = React.useState("");

React.useEffect(() => {
    getProducts({name: query})
    .then(products => {
        setProducts(products);
    })
}, [query]);

Dispatching a Redux action.

If your GET action already reduces into your Redux state, then you don't need to maintain any of that locally.

By passing products.length as a dependency, you only run this

const dispatch = Redux.useDispatch();
const products = Redux.useSelector(state => state.products);

React.useEffect(() => {
    dispatch(GetProducts())
}, []);

UseMemo

Unlike useEffect, React.useMemo does not trigger every time you change one of its dependencies.

A memoized function will first check to see if the dependencies have changed since the last render. If so, it executes the function and returns the result. If false, it simply returns the cached result from the last execution.

This is good for expensive operations like transforming API data or doing major calculations that you don't want to be re-doing unnecessarily

Example of useMemo

const posts = Redux.useSelector(state => state.posts);

const tags = React.useMemo(() => {
    return getTagsFromPosts(posts)
}, [posts]);

UseCallback

This is a special case for memoizing functions. Since javascript compares equality by reference, the function you create the first time a component renders will be different than the one created in subsequent renders.

If you try passing a function as props or state, this means that it will be treated as a prop change every single time. By wrapping it in useCallback, React will know that it's the same function. You can still add a dependency array to trigger a recalculation if the dependencies change.

A strong use-case here to avoid child component re-renders

Example of useCallback

Every time this component renders, it will also trigger a whole re-render of the Button component because the removeFromCart function is unique every time.

const dispatch = useDispatch();

const removeFromCart = () => dispatch(removeItem(product.id));

return (
    <Button onClick={removeFromCart}>Delete</Button>
);

Replacing our callback with this will avoid that problem entirely. Now the Button will only re-render when our product ID changes, so that it will function to remove the new product from our cart.

const removeFromCart = React.useCallback(() => {
    dispatch(removeItem(product.id))
}, [product.id]);

Charting a contact form in XState

Jacob Paris — Wed, 25 Mar 2020 06:36:26 +0000

State machines have been around forever, and still there's no better way to graphically represent application logic

By offloading your application state management into a platform-agnostic library like XState, you can render it out into a chart, use it to generate automated tests, avoid framework lock-in, and get all the benefits that a finite state machine can offer.

Here we'll step through some progressively more featureful examples of a state machine for a form. None of these are more correct than the others — instead, each represents a specific set of business logic and it's up to you to decide what level of state you want to support for your application.

Submit only with no validation

The most basic form has no client side validation.

The user hits submit. If the submission succeeds, we let the user know their submission has been received. If the submission fails, we allow them to retry.

The logic here is all focused around the submission of the form, rather than the time spent filling out the form. Since there's no required fields, and no conditions that stop us from submitting, all states up until the submitting state are identical from this machine's point of view.

With a machine like this, any validation would be done server-side, and an invalid form would cause the submit to fail and transition to a failure state.

// View in the XState Visualizer
// https://xstate.js.org/viz/?gist=6e7e6b7258c805c85ea273b03172605d

const formMachine = Machine({
    id: 'form',
    initial: 'editing',
    context: {
      retries: 0
    },
    states: {
      editing: {
        on: {
          SUBMIT: {
            target: 'submitting'
          }
        }
      },
      submitting: {
        on: {
          RESOLVE: 'success',
          REJECT: 'failure'
        }
      },
      success: {
        type: 'final'
      },
      failure: {
        on: {
          RETRY: {
            target: 'submitting',
            actions: 'incrementRetries'
          }
        }
      }
    }
  }, {
    actions: {
      incrementRetries: assign((context, event) => context.retries + 1)
    }
  })

Submit only if input is valid

Even in a world where server-side validation is free and easy, we're still going to want some basic client side validation. It doesn't make sense to allow users to submit empty forms, so let's add one input.

Consider a form with a single input for a message, and we want to ensure that the message is at least ten characters long before submitting.

There are a few new requirements our machine needs to implement in order to support that feature:

a context value for the message
an INPUT event that caches our message text in the machine context
a guard on the SUBMIT event that stops the transition if our message is empty or too short

// View in the XState Visualizer
// https://xstate.js.org/viz/?gist=365c0512bcdd1d187a8fda64f4211daa

const formMachine = Machine({
    id: 'form',
    initial: 'editing',
    context: {
      retries: 0,
+     message: ''
    },
    states: {
      editing: {
        on: {
          SUBMIT: [
+           {
+             target: 'editing',
+             cond: 'isMessageTooShort'
+           },
            {
              target: 'submitting'
            }
          ],
          INPUT: {
            target: 'editing',
            actions: 'cache'
          }
        }
      },
      …
    }
  }, {
    actions: {
      cache: assign((context, event) => event),
      incrementRetries: assign((context, event) => context.retries + 1)
    },
+   guards: {
+     isMessageTooShort: (context) => context.message.length < 10
+   }
  })

Inputs with an error state

Forms that fail without telling you why are categorically inelegant. At the very least, we should know which input is invalid.

To do this, we'll use a parallel nested state machine.

Since a parallel nested machine is in every state at once, we give it one state for each input whose validation we care about.

Each of those states contains yet another machine (not parallel this time) with the state of the input: either valid or error

If this sounds complicated to you, that's because it is. State charts give an accurate representation of the complexity of a system. This is just exposing how complex forms actually are.

The good news is, once you're familiar with the pattern it's a copy paste job to extend it to new inputs.

// View in the XState Visualizer
// https://xstate.js.org/viz/?gist=28dfc6298fc233eb10a5ff8795570ce3
…
editing: {
  on: {
    SUBMIT: [
      {
+       target: 'editing.message.error',
        cond: 'isMessageTooShort'
      },
      {
        target: 'submitting'
      }
    ],
    INPUT: {
      target: 'editing',
      actions: 'cache'
    }
  },
+ type: 'parallel',
+ states: {
+   message: {
+     initial: 'valid',
+     states: {
+       valid: {},
+       error: {}
+     }
+   }
+ }
},
…

Inputs with specific error states

A well designed form will tell you not only which field is invalid, but exactly what's wrong with it too. The trick to that is another state machine inside in the error state of an input

For demonstration purposes, we'll add a new guard isMessageEmpty to show how we can target specific error states

// View in the XState Visualizer
// https://xstate.js.org/viz/?gist=28dfc6298fc233eb10a5ff8795570ce3
…
editing: {
  on: {
    SUBMIT: [
+     {
+       target: 'editing.message.error.empty',
+       cond: 'isMessageEmpty'
+     },
      {
        target: 'editing.message.error.tooShort',
        cond: 'isMessageTooShort'
      },
      {
        target: 'submitting'
      }
    ],
    INPUT: {
      target: 'editing',
      actions: 'cache'
    }
  },
  type: 'parallel',
  states: {
    message: {
      initial: 'valid',
      states: {
        valid: {},
        error: {
+         initial: 'empty',
+         states: {
+           empty: {},
+           tooShort: {}
+         }
        }
      }
    }
  }
},
…

Forms with multiple inputs

Lets try a real-world scenario. Imagine a contact form on your website, where clients can pitch jobs.

We can imagine several inputs would be required

Name - required
Email - required, formatted like an email
Website - not required
Budget - required, must be a positive number at least $1000
Deadline - required, must be future date at least three days away
Message - required, must be at least 10 characters long

These are general business requirements, so there's lots of room for flexibility here.

We can copy and paste our message state for each of these form fields, and add the additional error states we want to track.

states: {
+ name: {
+   initial: 'valid',
+   states: {
+     valid: {},
+     error: {
+       initial: 'empty',
+       states: {
+         empty: {}
+       }
+     }
+   }
+ },
+ 
+ email: {
+   initial: 'valid',
+   states: {
+     valid: {},
+     error: {
+       initial: 'empty',
+       states: {
+         empty: {},
+         badFormat: {}
+       }
+     }
+   }
+ },
+ 
+ budget: {
+   initial: 'valid',
+   states: {
+     valid: {},
+     error: {
+       initial: 'empty',
+       states: {
+         empty: {},
+         badFormat: {},
+         tooLow: {}
+       }
+     }
+   }
+ },
+ 
+ deadline: {
+   initial: 'valid',
+   states: {
+     valid: {},
+     error: {
+       initial: 'empty',
+       states: {
+         empty: {},
+         tooEarly: {}
+       }
+     }
+   }
+ },

  message: {
    initial: 'valid',
    states: {
      valid: {},
      error: {
        initial: 'empty',
        states: {
          empty: {},
          tooShort: {}
        }
      }
    }
  }
}

It would not be wrong to forego the nested error type state when the only type is empty, and instead have valid and empty as two sibling states. I've found keeping a consistent error pattern is easier to grok in my own head, but your mileage may vary.

We get away easy with the website input, because any input we don't need to validate doesn't need to be part of the state machine.

Next, lets implement the guards for these inputs

guards: {
  isNameEmpty: context => context.name.length === 0,

  isEmailEmpty: context => context.email.length === 0,
  isEmailBadFormat: context => !context.email.includes('@'),

  isBudgetEmpty: context => context.budget.length === 0,
  isBudgetBadFormat: context => !context.budget.match(MONETARY_VALUE_REGEX),
  isBudgetTooLow: context => parseFloat(context.budget) < 1000,

  isDeadlineEmpty: context => !context.deadline,
  isDeadlineTooEarly: context => context.deadline <= THREE_DAYS_FROM_NOW,

  isMessageEmpty: context => context.message.length === 0,
  isMessageTooShort: context => context.message.length < 10
}

You can decide for yourself how fine-grained the validation should be. If you want different language on the website for a budget that's a little under or way under, add a new state and a new guard to accommodate that.

There are real names in the world that are only a single character long, and it's not unrealistic to have special characters or even a number in a valid name, so don't go overboard on trying to catch bad formats there. That's one extra state to track and at least one segment of the population you'd be excluding.

Emails are impossible to accurately validate client-side, and especially not with regex. Maintaining that it has at least one @ is about the safest check you can do.

Once you're happy with your guards, we can put them together and add the conditional transitions on the SUBMIT event

SUBMIT: [
+ {
+   target: 'editing.name.error.empty',
+   cond: 'isNameEmpty'
+ },
+ {
+   target: 'editing.email.error.empty',
+   cond: 'isEmailEmpty'
+ },
+ {
+   target: 'editing.email.error.badFormat',
+   cond: 'isEmailBadFormat'
+ },
+ {
+   target: 'editing.budget.error.empty',
+   cond: 'isBudgetEmpty'
+ },
+ {
+   target: 'editing.budget.error.badFormat',
+   cond: 'isBudgetBadFormat'
+ },
+ {
+   target: 'editing.budget.error.tooLow',
+   cond: 'isBudgetTooLow'
+ },
+ {
+   target: 'editing.deadline.error.empty',
+   cond: 'isDeadlineEmpty'
+ },
+ {
+   target: 'editing.deadline.error.tooEarly',
+   cond: 'isDeadlineTooEarly'
+ },
  {
    target: 'editing.message.error.empty',
    cond: 'isMessageEmpty'
  },
  {
    target: 'editing.message.error.tooShort',
    cond: 'isMessageTooShort'
  },
  {
    target: 'submitting'
  }
],

And that's it! We've now mapped out a robust contact form with field level validation, that can't end up in impossible states and allows for retry on failure.

Check out the completed chart on XState Visualizer

Talk TV Tutorial: Watch Youtube Streams and Chat with React

Jacob Paris — Tue, 10 Sep 2019 01:02:41 +0000

In this tutorial I'm going to show you how to bootstrap a React project from scratch using NPM and Webpack, integrate Google Login, grab data from the Youtube API, and deploy your code to Netlify

We will be building an application that shows a list of active Youtube Live Streams and lets the user watch them.

Part 2 will include adding a custom serverless websocket based chat that your users can use to talk with one another while watching the videos.

The complete demo can be found here: TalkTV on Netlify

If you get an error saying the application is not authorized, I just didn't bother submitting it to Google for verification since it's a demo app. You can safely skip it.

The codebase can be found here: TalkTV on GitHub

Getting Started

First we need to create a new repository for our project, so head over to GitHub. Thanks to Microsoft we can now create free private repositories, so you can keep your code secret if you like.

My Github is about 70/30 private/public, which used to be just a ratio and now is pretty close to the actual quantity.

Once you're set up, click that green button in the top right and get the address to clone your repo to your local computer.

Now some people like to make a local repository on their computer with git init and then set the upstream path to point to GitHub — and that works, at least for people who learned how to do it that way.

I choose the easier method:

git clone https://github.com/JacobParis/talktv.git

With your repository set up on your local machine, open it up in your IDE of choice and we're ready to start!

Install Dependencies

React can be a little tricky to get going if you aren't familiar with modern build tooling. CreateReactApp was created to solve this issue, but it's very opinionated and locks away a lot of useful configuration options. Gatsby and Next.js are two other popular options, but I'll walk you through setting up your own.

npm init

Initializing npm will create a package.json file that will store a list of our dependencies and our build scripts.

When we install packages, the --save flag will make sure they get added under dependencies in the package.json file. If we do --save-dev instead, they'll be added under devDependencies.

Later, anyone using this repository can install all packages with a simple npm install

First we install React. npm i is shorthand for npm install

npm i --save react react-dom react-router-dom styled-components

Then webpack, which we'll use to compile and bundle our project

npm i --save-dev webpack webpack-cli

And Babel, which transforms the easy code we write into the complicated code that works on everyone's devices

npm i --save-dev babel-loader @babel/core @babel/preset-env @babel/preset-react

Some plugins to read our HTML and CSS

npm i --save-dev css-loader html-webpack-plugin mini-css-extract-plugin

And a loader for our SCSS code (optional)

npm i --save-dev node-sass sass-loader

You're also going to want to create a .gitignore file with the following line. This will stop git from tracking our packages as if they were our own code.

node_modules

Configuring Webpack

There are a lot of resources out there for learning webpack, including this excellent article by David Gilbertson which taught me pretty much everything I know.

I've been carrying the same boilerplate webpack configuration file forward for a while now, so feel free to steal it here. Create a webpack.config.js file in your root directory and copy this code into it.

Building the app

To get started, we need some HTML and Javascript. We'll start with the most basic index.html file, which we'll place in an app directory to keep it separate from the configuration boilerplate.

<!DOCTYPE html>
<html>
    <head>
        <title>📺 Talk TV</title>
        <link href="https://fonts.googleapis.com/css?family=Montserrat&display=swap" rel="stylesheet">
    </head>
    <body>
        <div id="root"></div>
    </body>
</html>

Check through Google Fonts and pick a font you like. They're all free for both commercial and non-commercial purposes. Replace the <link /> tag with one you're happy with, then create a new app/index.js file in the same directory.

This is where we start working with React, but we'll want to keep it as simple as possible for now. Our goal is to get something functional displayed on-screen before we start fleshing out the product.

import React from "react";
import ReactDOM from "react-dom";

function App() {
    return (
        <h1> 📺 Talk TV</h1>
    );
}

ReactDOM.render(<App />, document.getElementById("root"));

Head back to our package.json file and add a new build script. We'll be able to build our app with the command npm run build no matter what we change this script to be later. Right now it's not very important if you'd prefer to type npx webpack instead, but some of our later scripts are going to be more complicated and I prefer consistency across the board.

"scripts": {
    [...]
    "build": "npx webpack"
}

NPX is a utility by npm that lets you execute packages without installing them globally. If you run the command npm i -g webpack, it will add the webpack command to your PATH. While this normally won't cause any issues, it forces you to use the same version of webpack for every project on your machine. Using npx allows your project to remain agnostic of the machine it's running on.

Modify our .gitignore file to add our dist directory

dist
node_modules

Run our new build script and you should see a number of files appear inside the dist directory. If so, success! We're ready to test our site live.

npm run build

Running Locally

If we open up our index.html file in a browser, everything should work fine for now, but routing won't work well later once we implement that. Luckily the team at Zeit has created the excellent serve package for spawning a quick webserver on our local machine.

We'll call it with the -s flag to hint that we're running a single page application, which will continue to serve our index.html file instead of giving us 404 errors.

Add a serve script to our package.json file and then run it.

"scripts": {
    [...]
    "serve": "npx serve -s dist"
}

npm run serve

Navigate to localhost:5000 (or any other port you may have chosen) in your browser, and see what we see!

Running on Netlify (Optional)

Local is great for development, but there isn't much of a point building a site if nobody else gets to use it. I recommend Netlify a hundred times over for hosting static websites for free. When I started using it, it was the clear winner in the category. Nowadays, GitHub Pages is a very strong contender and is likely even easier to set up since you're already using GitHub for your repository.

I'll be using Netlify because it's great at what it does and it's what I'm used to.

Feel free to skip this section if you aren't interested in public hosting or if you want to set up on your own. Otherwise, head on over to Netlify and log in or sign up!

Create a new site from Git

Choose GitHub, or any other VCS provider you may be using

Give Netlify permission to access your code

Now every time you commit and push the changes you've made to your application, and Netlify will automatically start deploying them.

And once it's ready you can see it live at the URL

Create the Login Scene

Okay! So when a user gets to our site, they need to be prompted to log in. We can map that flow with a simple flowchart like this

Arrives on Site:
  - Is logged in:
      Show Gallery Scene
  - Is not logged in:
      Show Login Scene:
        - Prompt for login
        - If successful, refresh

By refreshing after login, we avoid setting up any duplicate routing commands. The user simply goes through the normal flow a second time with the access to get to the right place.

The minimal implementation here is an isLoggedIn state that will show either scene. We don't even need to implement the login yet. One thing at a time.

Create a scenes folder and a login.js file inside. This will be a super simple scene to start.

import React from "react";

 export default function() {
    return (
        <h1> Please log in! </h1>
    );
}

And then back in our index.js we import the scene and set our state

import LoginScene from "./scenes/login";

function App() {
    const isSignedIn = false;

    return isSignedIn ? (
        <h1> 📺 Talk TV</h1>
    ) : <LoginScene />;
}

Rebuild, and the app should greet you with our new scene!

Test by changing isSignedIn to true and see if you get the old homepage. That means everything is working so far!

Start building our UI

You can follow this section as loosely as you want — it's your app to make look however you want. Functionally the next thing we need to do is implement the actual google authentication, but for that we need a button. And if we're making buttons already, we might as well make them look nice.

Make a new folder to store our components. These will be reusable combinations of HTML and CSS, so we avoid a lot of rewritten code. I like Styled Components for this because it shoves your own code reuse in your face. You become very encouraged to use the same components again rather than making another one that's almost identical.

In components/containers.js add this code:

import styled from "styled-components";

export const Container = styled.div`
    padding: 2rem;
    display: flex;
    justify-content: center;
`;

This is a small flex container that will center any elements placed within it. We'll wrap our Login scene text with it

import { Container } from "../../components/containers";

export default function() {

    return (
        <Container>
            <h1> Please log in! </h1>
        </Container>
    );
}

If you rebuild you should see some center aligned text!

Change the font

But Times New Roman is ugly, so it's time to set our actual font. If you'll remember our index.html file has a Google Font import in the header for Montserrat. If you used a different font you'll want to do that here too.

Beside our index.html and index.js files lets make an index.scss file. This will hold our global application styles that we don't want to leave up to the component.

html {
    font-family: 'Montserrat', sans-serif;
}

body {
    margin: 0;
}

And then at the very top of our index.js we need to import it.

import "./index.scss";

It might seem weird to import a CSS file, but this import is how webpack is able to find it and process it into regular CSS. Webpack starts at our entry point (index.js) and then branches through every import in every file connected to it.

Create a card component

Having styled text in the center of your screen works for a very minimalist aesthetic, but I'm feeling more fond of a dedicated card to greet our new users. Add a new component called cards.js

import styled from "styled-components";

export const Card = styled.div`
    color: #333;
    background-color: #fff;
    border: 1px solid black;
    border-radius: 0.5rem;
    padding: 1.5rem;
    width: 90%; 
    max-width: 300px;
    text-align: center;
`;

Here we have a container with a nice border, rounded edges, centered text and it grows to 90% of its parent width to a maximum of 300px. On really narrow devices, like portrait smartphones, this gives us a nice 5% margin on either side.

I was playing around here for a little bit and I also decided to add two more components in the same file

A subtle dividing line for our card

export const Divider = styled.hr`
  width: 50%;
  opacity: 0.2;
  margin-bottom: 2rem;
  margin-top: 0;
`;

And a large icon for our logo, which is just an emoji

export const Icon = styled.p`
    font-size: 10rem;
    margin: 0;
    user-select: none;
`;

Go back to our login.js and replace our please log in plea with our new components.

import { Card, Divider, Icon } from "../../components/cards";

export default function() {
    return (
        <Container>
            <LoginCard />
        </Container>
    );
}

function LoginCard() {
    return (
        <Card>
            <header>
                <Icon>📺</Icon>
                <h1>Talk TV</h1>
            </header>
            <Divider />
            <div>
                PLEASE LOG IN
            </div>
        </Card>
    );
}

You could easily just add the LoginCard contents directly in our Container, but I like to separate distinct components as much as I can. If you run it, your site should be looking almost like this. I actually forgot to take a screenshot here so I'm a bit ahead of you.

The biggest change I think should be the blue border, which we'll handle now.

Adding a theme config file

When you reuse the same colours, styles, and sizes throughout your app, it can be hard to keep them consistent if you change them all later. Luckily, Styled Components makes it really easy to keep a central store of our application styling.

Create a new file called app/theme.js next to our index files, and add some basic styles to it

export default {
    background: '#ffffff',
    baseFontColor: '#000000',
    baseFontSize: '16px',
    baseRadius: '1rem',
    primary: '#2196f3', // MD Light Blue 500
}

Back in our card component, we can access the Theme file like any other bit of javascript

import Theme from "../theme";

And then replace our border styles with this

border-radius: ${props => Theme.baseRadius};
border: ${props => `1px solid ${Theme.primary}33`};

The argument to that function is called props because Styled Components lets us access the props in our styles. We don't need that right now, so you can replace it with () => or _ => like people often do when they don't need arguments.

If you rebuild, you should be looking like my last screenshot there now!

Adding a Login button

Now we still don't have an actual clickable button, so we'll want to create a new components/button.js file. Buttons are some of the most versatile components out there, so instead of building one from scratch I stole a component from a previous project which I will provide for you to steal also!

Here I make significant use of the props argument I mentioned above, for example in this line:

cursor: ${props => props.disabled ? "not-allowed" : "pointer"};

And you can trigger that by adding the prop attribute.

<Button disabled>NOT ALLOWED</Button>

In our login.js file, once again replace our please log in text with a component. It might seem odd to do everything in little bite sized steps like this, but using text placeholders for components solves the problem that every part of our app is going to depend on something else downstream.

It's better to focus on getting one dependency working at a time and then moving on to build the next step.


import { Button } from "../../components/button";

function LoginCard() {
    return (
        <Card>
            <header>
                <Icon>📺</Icon>
                <h1>Talk TV</h1>
            </header>
            <Divider />
            <Button primary>LOG IN</Button>
        </Card>
    );
}

And now we have a button!

Google Authentication

With our button in place to change our isLoggedIn state and the mechanics to change our route based on the state, all that's left to do is tie them together by integrating Google auth. It isn't too difficult but it can be tough to navigate the docs and API Console and get where you need to be.

Head on over to the Google API Console and click the New Project button in the top left

Once your project is created, go to OAuth Consent Screen in the left sidebar and set our Application Name and Authorized domain.

We're going to need two sets of keys. In order to log in, we will need oAuth2 keys. In order to pull data from the Youtube API, we will need an API key. Go to Credentials -> Create Credentials -> OAuth Client ID

Select Web Application, put in our application name again and then add our javascript origins. Google will reject requests that don't come from a verified origin. We'll want to add both our Netlify URL and our localhost origin for development.

Now in Dashboard -> Enable APIs and Services search for the Youtube Data API

Add a new API Key. We'll use this to connect to the Youtube API.

If you head back to Credentials, you can see both our API Key and our Client ID ready to go

Integrating into the app

In order to connect to the Google API, we need to import the Google JS API into our project. There are a number of ways to do this but the easiest by far is to simply include it in the <head> tag of our index.html file at the root of our app.

<head>
    <title>📺 Talk TV</title>
    <link href="https://fonts.googleapis.com/css?family=Montserrat&display=swap" rel="stylesheet">
    <script src="https://apis.google.com/js/api.js"></script>
</head>

Next we need to add our keys to our index.js file. I like to keep these constants just above the main App declaration.

const CLIENT_ID = ASDFASDFASDFASDF;
const API_KEY = QWERQWERQWERQWER;

function App() {

Before we can use the Google API, we need to initialize it. One way to do this would be to check its status before each method call, and if needed initialize first, but that is a lot of unnecessary checking.

Due to the way React works, we can track its ready status in a state, and choose to only render the app when Google is ready. None of our child components can call the API unless they're rendered, so we shouldn't run into issues.

When we included the API into our <head> tag, it exposed the global keyword gapi to all of our javascript files, and we'll use that to interact with it.

In our index.js make a new function called Preloader and change the ReactDOM render method at the bottom of the file to call the preloader instead.

function Preloader() {
    const [isGoogleReady, setGoogleReady] = React.useState(false);

    return isGoogleReady ? <App /> : <div>Loading...</div>;
}

ReactDOM.render(<Preloader />, document.getElementById("root"));

By switching isGoogleReady from true to false you will see either the app or the loading screen.

Since the google API is outside of our component, we'll want to wrap the code that interacts with it inside a useEffect hook. We initialize the API and then set our state when it's ready

React.useEffect(() => {
    const authPromise = gapi.auth2.init({
        clientId: CLIENT_ID,
    });

    authPromise.then(() => {
      setGoogleReady(true);
    });
}, []);

return isGoogleReady ? <App /> : <div>Loading...</div>;

If you run this now, you should see the Loading screen appear briefly before the main app does. If so, great! But there are still two issues with our code.

The first is that sometimes our component will load for the first time and the Google API could already be initialized. If that's the case, we don't need to redo it.

We can test for this by the presence of the auth2 field in the gapi object. Update our initial state declaration with the following:

const wasGoogleReady = !!gapi.auth2;
const [isGoogleReady, setGoogleReady] = React.useState(wasGoogleReady);

The second issue is that by the time we finish initializing, our component might have re-rendered already. When a component re-renders, it's a completely new function in a new context that can't use our old state variables, so trying to set them will cause an error. React has very descriptive errors that will let you know exactly when this is the case, we can solve it now anyway.

The useEffect hook supports a return argument of a second function to return when the component unmounts. This lets us clean up any unfinished business, but in particular we'll use it here to break our promise.

React.useEffect(() => {
    const isSubscribed = true;

    const authPromise = gapi.auth2.init({
        clientId: CLIENT_ID,
    });

    authPromise.then(() => {
      if (isSubscribed) setGoogleReady(true);
    });

    return () => isSubscribed = false;
}, []);

We track a variable that remembers if we are still subscribed to the result of this promise. If not, we just don't anything with the results.

Wiring up the Login Button

In login.js, I decided to make a new hook just to reduce the verbosity of the gapi declaration. This is entirely optional but I think it makes for some cleaner code.

function useAuth() {
    return gapi.auth2.getAuthInstance();
}

We'll now make a callback to trigger a sign in attempt and pass it down to our button

export default function() {
    const onLogin = React.useCallback(() => useAuth().signIn(), []);

    return (
        <Container>
            <LoginCard onLogin={onLogin} />
        </Container>
    );
}

And we'll grab the prop in our arguments and pass down to the button

function LoginCard({onLogin}) {
    return (
        <Card>
            <header>
                <Icon>📺</Icon>
                <h1>Talk TV</h1>
            </header>
            <Divider />
            <Button primary onClick={onLogin}>LOG IN</Button>
        </Card>
    );
}

Now if we rebuild and click our button, we should be passed through Google Auth

And then once we log in, refresh the page and it should now take us through the flow to our homepage

Perfect! One last thing — we should make it automatically refresh after logging in. Replace your onLogin callback with this

const onLogin = React.useCallback(() => useAuth().signIn().then(() => {
    // Refresh after sign-in
    location.reload();
}), []);

Adding a header

We won't be able to test the login refresh properly until we have a sign out button, so next we'll build a header component that includes one.

Make a new file called app/components/header.js and add a basic layout.

import React from 'react';
import styled from 'styled-components';

const Container = styled.div`
    display: flex;
    justify-content: center;
    position: relative;
`;

const HeaderText = styled.h1`
    margin: 0.25rem 0;
`;

export function Header() {
    return (
        <Container>
            <HeaderText> 📺 Talk TV </HeaderText>
        </Container>
    )
}

and then add it to our home.js

import { Header } from "../../components/header";

export default function() {
    return (
        <div>
            <Header />
            <h1> Welcome home, logged in user!</h1>
        </div>
    );
}

I didn't take a screenshot before I added the Sign Out button, but we should be pretty close to this now.

The Sign Out Button

Back in our header.js component add an actions section for our button and implement a callback. This should be pretty familiar, since it's more or less the same code for our login button back in home.js.

import { Button } from "../components/button";

const HeaderActions = styled.div`
    position: absolute;
    right: 1rem;
    top: 0.25rem;
    bottom: 0;
`;

function SignoutButton() {
    const signOut = React.useCallback(() => useAuth().signOut().then(() => {
        // Refresh after signout
        location.reload();
    }), []);

    return (
        <Button inverted onClick={signOut}>Sign Out</Button>
    );
}

function useAuth() {
    return gapi.auth2.getAuthInstance();
}

And then we'll add it to our render return

export function Header() {
    return (
        <Container>
            <HeaderText> 📺 Talk TV </HeaderText>
            <HeaderActions>
                <SignoutButton />
            </HeaderActions>
        </Container>
    )
}

Now if you rebuild it should look like that last screenshot. Click the sign-out button and you should end up on the login scene, ready to log back in without needing to refresh.

Loading...

It's painfully obvious how ugly our loading spinner is, so now is a good time to upgrade it. Luckily the React community has created a number of packages we can use.

Install the react-loader-spinner package

npm i --save react-loader-spinner

and make a new component called loading.js

import React from "react";
import { Container } from "./containers";
import Loader from "react-loader-spinner";
import Theme from "../theme";

export function Loading() {
    return (
        <Container>
            <Loader
                type="Bars"
                color={Theme.primary}
                height={100}
                width={100}
            />
        </Container>
    )
}

Add it to our index.js where our loading text used to be

import { Loading } from "./components/loading";

return isGoogleReady ? <App /> : <Loading />;

Implementing the Youtube API

Our authentication flow is complete, which means our next step is to start pulling data in from youtube. We don't actually have permission to access anything yet since we didn't request it on login, so we'll fix that first.

Near the top of your login.js file add a constant declaring which scope we want to use. This is a set of permissions that we'll let the user consent to on sign-in.

const YOUTUBE_SCOPE = "https://www.googleapis.com/auth/youtube.readonly";

and then update the sign in function to use it

const onLogin = React.useCallback(() => useAuth().signIn({
    scope: YOUTUBE_SCOPE
}).then(() => {

Log out and back in and it'll ask to get some basic read only permissions to your Youtube account.

Head over to home.js and we'll request a list of live videos from the youtube API. I'm always pretty heavy on the console.logs when adding new code, especially when it comes to an API I've never used before. Add this to the bottom of the file

function getVideos() {
    return new Promise((resolve, reject) => {
        gapi.client.youtube.search.list({
            "part": "snippet",
            "eventType": "live",
            "maxResults": 12,
            "q": "game",
            "type": "video"
        }).then(response => {
            console.log("GET VIDEOS", response);
            const items = response.result.items;

            if(items) {
                resolve(items);
            } else {
                reject();
            }
        }).catch(error => {
            console.log("ERROR VIDEOS", error);
            reject();
        });
    });
}

and then implement it with our same subscribed effect pattern we used earlier

export default function() {
    React.useEffect(() => {
        let isSubscribed = true;

        getVideos().then(videos => {
            if (isSubscribed) {
                console.log(videos);
            }
        });

        return () => isSubscribed = false;
    }, []);

Run that and check your log to see if you get an array of videos. If so, great! If you don't update the login scope (like I forgot to the first time) then you'll get this error

Displaying the Videos

You can design this part any way you want, but I'll just go through the way I built mine step by step

Make a new component called app/components/youtube.js

First we'll need a container to hold them. I'm going to use Flex, but Grid is another viable option. I'm choosing flex because we don't need to structure the elements in specific rows and columns.

If we just used inline-block elements, we could run out a long line of videos that'd wrap to the next line and work perfectly on every resolution. Flex lets us do the same thing, but also expand each element to take up empty space.

All of these will be going into the same file.

import styled from "styled-components";

export const BoxGrid = styled.ul`
    display: flex;
    flex-wrap: wrap;
    padding: 1rem;
`;

We'll want a clickable container for each video thumbnail. It's possible to add a click listener on the element, but then we need to add our own tab index and it's easier to just use elements designed for navigation. Like links.

import { Link } from "react-router-dom";
import Theme from "../theme";

const Container = styled(Link)`
    max-width: 100%;
    flex: 1 0 280px;
    border-radius: ${props => Theme.baseRadius};
    margin: ${props => Theme.baseRadius};
    position: relative;
`;

Each thumbnail will need an image

const Thumbnail = styled.img`
    width: 100%;
    border-radius: ${props => Theme.baseRadius};
    border: ${props => `1px solid ${Theme.primary}33`};
`;

And below each thumbnail we want to be able to display the title and a watch now button

import { Button } from "./button";

const Details = styled.div`
    padding: 0.5rem; 
    flex: 0;
    justify-content: space-between;
    align-items: center;
    display: flex;
`;

const Title = styled.span`
    font-weight: bold;
`;

const Action = styled(Button)`
    flex: 0;
`;

Then we put them together in a component

function YoutubeThumbnail({id, thumbnail, title}) {
    return (
        <Container to={`/watch/${id}`}>
            <Thumbnail src={thumbnail.url} />
            <Details>
                <Title>{title}</Title>
                <Action inverted>WATCH</Action>
            </Details>
        </Container>
    );
}

Finally, we'll want to export an array of our thumbnails based on the data we got from the API

import { Loading } from "./loading";

export function YoutubeGallery({videos}) {
    const hasVideos = videos && videos.length;

    return hasVideos ? videos.map(video => (
        <YoutubeThumbnail
            id={video.id.videoId}
            thumbnail={video.snippet.thumbnails.medium}
            title={video.snippet.channelTitle}
        />
    )) : <Loading wide/>;
}

In our Home scene, we'll import these components and update our effect to put the API data into state

import { BoxGrid, YoutubeGallery } from "../../components/youtube";

export default function() {
    const [videos, setVideos] = React.useState([]);

    React.useEffect(() => {
        let isSubscribed = true;

        getVideos().then(videos => {
            if (isSubscribed) setVideos(videos);
        });

        return () => isSubscribed = false;
    });

    return (
        <div>
            <Header />
            <BoxGrid>
                <YoutubeGallery videos={videos} />
            </BoxGrid>
        </div>
    );
}

Which should look like this when you're all done

The Watch Scene

If you're paying close attention, you'll notice that each thumbnail now links to /watch/${id}

That route doesn't exist yet, but it's about to.

Add a new file in scenes/watch.js and give it a basic component so we can test our routing

import React from "react";

export default function() {
    return (
        <span>Watch Scene!</span>
    );
}

And then add it to our route definitions in index.js

import WatchScene from "./scenes/watch";

<Switch>
    <Route path="/watch/:id" component={WatchScene} />
    <Route path="/watch" component={HomeScene} />
    <Redirect from="/" to="/watch" />
</Switch>

Clicking on any of our thumbnails should give us this now

Lets give our components/youtube.js file one more export

export const VideoFrame = styled.iframe.attrs(({id}) => ({
    width: 560,
    height: 349,
    frameborder: "0",
    allowFullScreen: true,
    src: getEmbedURL(id)
}))`
    border-radius: ${props => Theme.baseRadius};
    border: ${props => `1px solid ${Theme.primary}33`};
`;

function getEmbedURL(channelId) {
    return `https://www.youtube.com/embed/${channelId}`;
}

and then add it to our watch scene to complete this half of the project

import { Header } from "../../components/header";
import { Container } from "../../components/containers";
import { VideoFrame } from "../../components/youtube";

export default function() {
    const channelId = document.location.pathname.split('/').pop();

    return (
        <div>
            <Header />
            <Container>
                <VideoFrame id={channelId} />
            </Container>
        </div>
    );
}

Conclusion

In this tutorial, we've built an application that lets a user log in with their google account, view a list of active live streams, and choose one to watch

In part 2 we'll build our own chat system that the users of your site can use to communicate while watching the videos

The demo for the completed product can be found here: Talk TV on Netlify

A Twitter Bot for Passive ❤️s

Jacob Paris — Fri, 02 Aug 2019 00:36:49 +0000

Paste this into your browser console (or make a plugin with Scriptish) and posts will ❤️ themselves automatically as you scroll

setInterval(() => {
  const heart = document.querySelector(`[data-testid="like"]`);
  if(heart) heart.click();
}, 1408);

Or paste this into the address bar

javascript:setInterval((heart=document.querySelector(`[data-testid="like"]`)) => {heart && heart.click();}, 1500);

disclaimer: Automated likes are against Twitter ToS

second disclaimer: don't go to anyone's profile or you'll look like a stalker

Forem: Jacob Paris

A tech interview that doesn't suck

The Take Home Project

The Follow-Up Interview

The Live-Coding Segment

Exercise 1: Permanently delete all completed tasks

Exercise 2: Sort tasks in descending order

Exercise 3: Split the tasks into two lists

The Developer's Guide to Hoisting

How To For Loop Through Anything in JS

XState Text Formatting Part 3

References

XState Text Formatting Part 2

References

Modelling parallel states in XState

References

How to Center Anything in CSS

The Text Align Method

The Line Height Method

The Background Position Method

The Margin Auto Method

The Position Absolute Method

The Absolute Offset Method

The Flexbox Method

The Grid Method

Grid (Place Items)

Async Functions from Start to Finish

Functions

Arguments

Callbacks

Promises

Constructor

Class Method

Catch

Async Functions

Usage

Return

Throw

Await

React Hooks: UseEffect, UseMemo, UseCallback

UseEffect

Examples of useEffect

Updating the page title

Fetching data from an API into local state.

Fetching data from an API into local state, based on a query.

Dispatching a Redux action.

UseMemo

Example of useMemo

UseCallback

Example of useCallback

Further Reading

Charting a contact form in XState

Submit only with no validation

Submit only if input is valid

Inputs with an error state

Inputs with specific error states

Forms with multiple inputs

Talk TV Tutorial: Watch Youtube Streams and Chat with React

Getting Started

Install Dependencies

Configuring Webpack

Building the app

Running Locally

Running on Netlify (Optional)

Create the Login Scene

Start building our UI

Change the font

Create a card component

Adding a theme config file

Adding a Login button

Google Authentication

Integrating into the app

Wiring up the Login Button

Adding a header

The Sign Out Button

Loading...

Implementing the Youtube API

Displaying the Videos

The Watch Scene

Conclusion