DEV Community: Sveta Slepner

GitHub Actions - A Beginner's Guide to Automating Your Development Process

Sveta Slepner — Mon, 06 Feb 2023 16:25:36 +0000

As a front-end developer, I was never really drawn to the "DevOps" side of my day-to-day work. The major reason is that up until now, in all of the places I have worked in, we've been using Jenkins. And while it's a powerful tool no doubt, it sure is unwelcoming and hard to get started with.

But in recent years GitHub has stepped into the game and in 2018 released "GitHub Actions", a platform for creating custom, automated development workflows directly within the GitHub ecosystem.

Whether you want to create a CI/CD pipeline or automate GitHub-related flows like opening a PR, adding automated comments, or sending a Slack notification each time someone merges a commit to master, GitHub Actions can help you create these processes and save you time and effort. And the best part is how straightforward it is!

In this guide, we'll cover the basics of GitHub Actions and show you how to get started with them. We'll go through the process of setting up a simple workflow and explain some of the key concepts you need to know. By the end, you'll be able to use GitHub Actions to automate your own workflow and take your productivity to the next level!

First, some GitHub Actions terminology

Well, the name might be GitHub Actions, but let's put that aside for one second. What we're actually running are workflows. A workflow is a collection of jobs that are triggered by an event.

Here's an example of a simple workflow's structure:

As you can see, this workflow is running two jobs. A job is a set of steps that are executed in sequence. Each step of a job can be an action. An action is an individual step within a job that can perform a variety of tasks such as running a script, building an application, deploying code, or running tests.

Setting up a workflow

GitHub actions and workflows are written in YAML, a language that is a superset of JSON and is considered easier on the eye. You'll notice that indentations are used instead of curly brackets.

For GitHub to recognize your .yml files as workflows you have to store them inside the following folder of your repository: .github/workflows/[workflow-name].yml

You can add a workflow manually by pushing your own files, or going to the "Actions" tab in your repo and either clicking on "set up a workflow yourself" or selecting one of the available templates GitHub suggests.

Once you have at least one workflow, you'll be able to manage them from the same page, as well as dispatch, re-run failed jobs, and view the status of previous runs.

Understanding the workflow's structure

Let's examine this basic workflow that says hi to the person who initiated the run and then runs some tests, and understand the different parts that it's constructed from.

name: CI

on:
  push:
  pull_request:

jobs:
  unit-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install
        run: npm install  
      - name: Run unit tests
        run: npm test
  e2e-tests:
      runs-on: ubuntu-latest
      steps:
        - uses: actions/checkout@v3
        - name: Install
          run: npm install  
        - name: Run unit tests
          run: npm e2e

First, we need to define the workflow's settings. We can see that this workflow has three properties: name, on, and jobs.

name is simply the workflow's name. It's not mandatory, however, I still recommend adding one, so it'll be easier to manage your workflows in the "Actions" tab.

on defines the trigger of the workflow. You can set one or more. For instance, in the example shown above, the workflow will run whenever a pull request is opened or a push to any branch occurs.

If you want to make your trigger more specific, you can provide extra parameters. Each trigger event is different, so let's have a look at some examples.

1. A push to specific branches

on:
  push:
    branches: 
      [master, test]

In this one, we want the workflow to run on a push event, but only when the branch name equals the ones we provide using the branches property. In this case, it's "master" or "test". If we push something to a branch named "test2", nothing will happen.

By the way, in YAML arrays can be defined with square brackets or like so:

on:
  push: 
    branches:
      - master
      - test

This is the exact same thing! You might see both styles in use, and it's up to your preference.

Anyway, we can be even more specific, for instance, mention only branches that start with tests/:

on:
  push: 
    branches:
      - tests/**

Or do the opposite and accept all branches but ignore everything that starts with tests/ by using branches-ignore instead of branches

on:
  push: 
    branches-ignore:
      - tests/**

2. Scheduled workflow

on:
  schedule:
    - cron: '0 6 * * *'

We can make our workflow run automatically on a scheduled basis, using the schedule trigger. In this example, the workflow will run every day at 6:00 AM. You can see that schedule receives an array, so you can add multiple cron settings if you wish.

3. Manual workflow dispatch

Another common trigger is workflow_dispatch which allows us to manually trigger the workflow directly from the GitHub Actions UI. It can even be configured to require parameters that can be later accessed by our actions.

on:
  workflow_dispatch:
    inputs:
      name:
        type: string
        default: Sveta
        required: true
        description: 'A name passed from the caller workflow'

jobs:
  print:
    runs-on: ubuntu-latest
    steps: 
      - name: Print the name
        run: echo "Hi there, ${{ inputs.name }}"

This is what it looks like inside the GitHub UI:

There are many more possible triggers and configurations, so going to the documentation is the best place to learn more.

ℹ️ Note

When you see an expression wrapped with ${{}} know that it's a way to access a variable's value, as seen in the example above. This is the way to get context information (like which branch we're on), secrets, our workflow's input values, and more.

run: echo "Hi there, ${{ inputs.name }}"

Let's get things running: the "jobs" property

So up until now, we set up a trigger to our workflow, but now let's get into what the workflows are actually doing - running jobs that trigger our actions!

When creating a workflow you can set it to run one or more jobs.

Unless configured otherwise, jobs run in parallel and don't depend on previous jobs to finish first.

In the scenario above, our workflow runs two jobs: "unit-tests" and "e2e-tests", and while the workflow is activated, the jobs will run simultaneously. We will see later how we can create dependencies between jobs.

To define a job, we first give it an id (can be anything we like), and then we need to provide it with some configuration.

There are 2 mandatory parameters:

runs-on : This configures the job's runner. Runners are virtual machines (VMs) used to run the tasks defined in our jobs. GitHub provides hosted runners for each operating system (Linux, macOS, and Windows). You can see the full list of available runners here, as well as their specifications. If you require more granular control over your VM, you can self-host your own runners. One use case for using self-hosted runners is resource utilization. If you need to run your actions on stronger machines, explore this option.
steps - Here we list the array of actions the job will execute. The steps are executed one by one. We will go over actions in the next section.

Some notable optional parameters:

name - Just like with workflows, it is not mandatory to provide a name for your job, but it's useful for visualization of your flow.
needs - Remember that we said that jobs don't depend on each other, and run in parallel? But we can create this dependency by using the "needs" param. Let's see the example below:

jobs:
  unit-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install
        run: npm install  
      - name: Run unit tests
        run: npm test
  e2e-tests:
      runs-on: ubuntu-latest
      steps:
        - uses: actions/checkout@v3
        - name: Install
          run: npm install  
        - name: Run unit tests
          run: npm e2e
  send-slack-notification:
      needs: [unit-tests, e2e-tests]
      runs-on: ubuntu-latest
      steps:
        - uses: actions/checkout@v3
        - name: Send notification
          uses: rtCamp/action-slack-notify@v2
          env:
            SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK }}
            SLACK_CHANNEL: team-ci
            SLACK_TITLE: Finished running tests
            SLACK_MESSAGE: 'Hooray :rocket:'

We can see that the last job, send-slack-notification requires unit-test and e2e-tests to finish, since we want to send that slack notification only when both of these jobs are done executing.

1. if - We can add a condition to our job that will allow us to set it to run only if some condition/s are met. For instance, let's say that our workflow can be triggered by both push and pull_request events, but we want to run a specific job in this flow that will only run if the trigger was specifically a "push" event.

name: Test
on: 
  push:
  pull_request:

jobs:
  print-something-on-push:
    if: github.event_name == 'push'
    runs-on: ubuntu-latest
    steps:
      - name: Print
        run: echo "This job runs on push only".
  print-always:
      runs-on: ubuntu-latest
      steps:
        - name: Print
          run: echo "This job always runs".

2. outputs - A job can produce an output that can later be accessed by other jobs (combined with needs of course, as we have to wait for that job to resolve first). The output is an object, so you can pass any number of parameters that you want.

name: Job outputs test
on:
    workflow_dispatch:
        inputs:
            version:
                description: "Version"
                required: true
                type: string
jobs:
    prepare-version-id:
        runs-on: ubuntu-latest
        outputs:
            version_w_hyphens: ${{ steps.replace-string.outputs.replaced }}
        steps:
          - uses: frabert/replace-string-action@v2
            id: replace-string
            with:
              pattern: '\.'
              string: ${{ inputs.version }}
              replace-with: '-'
          - name: "print"
            run: echo ${{ steps.replace-string.outputs.replaced }}
    print-stuff:
        needs: [prepare-version-id]
        runs-on: ubuntu-latest
        steps:
          - name: "print version id from another job"
            run: echo ${{needs.prepare-version-id.outputs.version_w_hyphens}}

In this example, we have a workflow that expects a string input called version on dispatch.

Then, let's imagine that we need this version for multiple usages, and some of them require us to replace the dots in the string with hyphens.

prepare-version-id:
    runs-on: ubuntu-latest
    outputs:
       version_w_hyphens: ${{ steps.replace-string.outputs.replaced }}

We can see that prepare-version-id defines the outputs object, with one item - version_w_hyphens which returns the value of the step that was responsible for replacing the dots with hyphens. Actions can return output as well, but more on that later. Then inside the other job called print-stuff we can access this value by calling needs.[job-id].outputs.[outpus-key] and in our case needs.prepare-version-id.outputs.version_w_hyphens.

Now to the star of the show: Actions

As we stated before, jobs run an array of steps, where each step executes an action, where an action is a set of commands or tasks. There are 3 kinds of actions you can work with.

1. Using open-sourced actions

For the most part, there's a high probability that someone already has created a solution for at least some of the tasks you wish to accomplish. For instance, if you need to send a slack notification, publish to GitHub pages, upload an artifact, and so on, the community has got you covered.

steps:
  - name: Checkout
    uses: actions/checkout@v3

This is an example of one of the most useful public actions there are, that allows you to checkout to the branch that's in the workflow's context (or to another one if you wish). All you have to do in order to use such an action is to create a step with the uses property and provide the action's location, ie [github-user]/[repo]@[version].

You can specify a specific version, for example @v3 in that case, or simply refer to the latest possible version by using @master (though then you're opening yourself to be affected by bugs or breaking changes).

That's it. You don't have to actually install or configure anything.

Some actions might expect some input parameters (or have some optional ones). In that case, all you have to do is to add the with: property to the step and pass the required values.

steps:
- uses: frabert/replace-string-action@v2
  name: Replace string
  id: replace-string
  with:
    pattern: '\.'
    string: ${{ inputs.version }}
    replace-with: '-'

Some actions might also return some sort of output. For instance, in this example, we use this action to run some regex expression on a string, so naturally, we need the result. To do that we will need to provide an id to the step, so we can access it later by calling steps.[step-id].outputs.[key].

steps:
  - uses: frabert/replace-string-action@v2
    id: replace-string
    with:
      pattern: '\.'
      string: ${{ inputs.version }}
      replace-with: '-'
  - name: "print replaced value from previous step"
    run: echo ${{ steps.replace-string.outputs.replaced }}

⚠️ You should use caution with 3rd party actions as they may contain malicious code or vulnerabilities that can compromise the security of your project and lead to a data breach or other negative consequences. Make sure to check if the action is properly maintained and has a community base.

2. Running shell commands

We can also run our own code, by running shell commands. The default depends on the kind of runner you're using. For instance, for Linux (ubuntu) it would use bash. You can change the shell type by providing an explicit one. See all the possible shells here.

steps:
  - name: Run install
    run: npm install
    shell: bash #an optional setting

To run a multiline script, we can use a pipeline, like so:

steps:
  - name: Run install and test
    run: |
        npm install    
        npm test

In case we want our action to provide an output that can be accessed by other actions, we have to run the following command:

- name: Set output
  run: echo "{name}={value}" >> $GITHUB_OUTPUT

We can set as many as we want. Accessing the values from other steps follows the same convention as mentioned in the previous section.

steps:
  - id: example
    run: |
      echo "animal='Dog'" >> $GITHUB_OUTPUT  
      echo "name='Fluffy'" >> $GITHUB_OUTPUT
  - name: Print
    run: |
      echo "Animal type: ${{steps.example.outputs.animal}}"
      echo "Animal name: ${{steps.example.outputs.name}}"

3. Running an action from a file

Let's say we have a custom-made action that we use in multiple workflows and we don't want to repeat writing. In that case, we can create an action.yml file and store it inside our repo inside the following path: .github/actions/[action-id]/action.yml.

Here's an example action that's using the composite action method where you can create an action with the regular YML syntax and run one or more steps:

name: 'My Action'
description: 'An example of a custom action'
inputs:
  message:
    description: 'A message to print'
    required: true

runs:
  using: composite
  steps:
    - run: echo Hello ${{ inputs.message }}.
      shell: bash

Then we can refer to it by calling it like this:

name: My Workflow
on: push
jobs:
  print-message:
    runs-on: ubuntu-latest
    steps:
    - name: Print message
      uses: ./.github/actions/my-action
      with:
        message: 'Hello, world!'

There are other methods to create actions, where you create the action.yml file just to set up the input and output params and the script itself is written in other languages of your choice (JS, python, shell, and more). You can read about it here.

Some other action settings

Actions have some other parameters that are worth mentioning. Of course, the name parameter, which again will make it easier to follow in the log, but the most useful one is if. We already discussed it as a possible parameter for jobs, but actions can also be limited to running only on condition.

One of the useful conditions we can check for is the job's status. For instance, send a failure message to Slack, but only when the job has failed. See the full list of status checks here.

steps:
  ...
  - name: The job has succeeded
    if: ${{ success() }}
    run: # do something if all the previous steps have finished successfuly
  - name: The job has failed
    if: ${{ failure() }}
    run: # do something if the job has filed

Another useful action property is continue-on-error. By default, if one step of a job failed, it will cause the entire job to end with the "failure" status. However, sometimes we might want to not count this failure as part of the whole job's status. In that case, we can pass this property to make the run ignore this step's status.

steps: 
  - name: Ignore my failure
    continue-on-error: true

Testing our workflow

So now that we have a workflow, how do we actually test it? Well, it's simple and tricky at the same time. To be able to run a workflow its file must either exist on the master/main branch or use a trigger that occurs when pushing to the branch we're writing our action on.

If the workflow happens to have a worflow_dispatch trigger and we want to try some changes, we can apply them to a branch, add initiate the workflow from our branch.

There is also another way that allows you to run actions locally on your machine, but it's a little trickier to set up. You can read about it here.

And that's it! These were the basics of what you need to know to get started with GitHub actions. Hope you will find it useful!

Understanding the difference between useMemo and useCallback

Sveta Slepner — Sun, 05 Feb 2023 20:23:13 +0000

React library provides us two built-in hooks to optimize the performance of our app: useMemo & useCallback. At first glance, it might look like their usage is quite similar, so it can get confusing about when to use each. To clear that confusion, let’s dig in and understand the actual difference and the correct way to use them both.

Functional components have a problem

Functional components are great. Their combination with hooks allows for much more code reusability and flexibility than Class components. However, they do have one problem: A functional component is the same as the render function we used to have in class components. It’s a function that is being re-run on any prop/state change.

It means that:

A. If a function is called inside the component, it will be re-evaluated, again and again, on every re-render.

B. If a function is created inside the component is passed to a child component, it will be recreated, meaning the pointer will change, causing the child to re-render or call the function unnecessarily (depending on the situation).

To tackle the problem and prevent the possible performance issue, React provides us with two hooks: useMemo and useCallback.

useMemo

Let’s start with the first problem and see how we can prevent evaluating functions unnecessarily.

In the following demo, we have a component with two states: one store a number, and the other one a boolean. We need to do some calculation on the number we have in our state, so we call our plusFive function and render the result.

const plusFive = (num) => {
  console.log("I was called!");
  return num + 5;
};
export default function App() {
  const [num, setNum] = useState(0);
  const [light, setLight] = useState(true);
  const numPlusFive = plusFive(num);
  return (
  ...

If you open the console, you’ll see that plusFive is called whether we click on “Update Number” which sets a new number, or “Toggle the light” which updates the boolean state (and has nothing to do with numPlusFive).

So how can we prevent this from happening? By memoizing plusFive ! Until we will receive a new number, the function will not be called. The calculation is skipped, and we will receive the result immediately.

We will do that by using useMemo , and it will look like this:

const numPlusFive = useMemo(() => plusFive(num), [num]);

useMemo receives two parameters: A function that returns our function call, and an array of dependencies. Only when one of the dependencies is changed, our function will be called again. useMemo returns the results of that function execution and will store it in memory to prevent the function from running again if the same parameters were used.

Go ahead and see for yourself (don’t forget to open the console):

useCallback

Now that we know how to prevent re-evaluating functions, let’s see how we can prevent functions created inside components from being recreated on every render.

In the demo below, we have a child component () that receives as a prop, a function we created inside the parent component (). Note this function is being used inside a useEffect hook, and since it’s listed as useEffect’s dependency, it’s being called again. Yes, even when we change other states or receive props, not related to our “plusFive” function.

const App = () => {
  const [num, setNum] = useState(0);
  const [light, setLight] = useState(true);
  const plusFive = () => {
    console.log("I was called!");
    return num + 5;
  };
  return (
    <div className={light ? "light" : "dark"}>
      <div>
        <SomeComp someFunc={plusFive} />
  <button onClick={() => { setLight(!light); }}> Toggle the light </button>
      </div>
    </div>
  );
}
const SomeComp = ({ someFunc }) => {
  const [calcNum, setCalcNum] = useState(0);
  useEffect(() => {

    // In this scenatio, someFunc will change on every render, so this useEffect will run.
     setCalcNum(someFunc());
  }, [someFunc]);
return <span> Plus five: {calcNum}</span>;
};

To prevent our function from being recreated and change pointers on each render round, we can use useCallback. This React hook receives two parameters: A function and an array of dependencies:

const plusFive = useCallback(() => {
  console.log("I was called!");
  return num + 5;
}, [num]);

This hook lets us preserve the function, and it will be recreated only when one of its dependencies changes.

Here’s the working demo:

But Wait! Don’t misuse these hooks!

While these two hooks provide a solution to a real problem, they may get misused very easily and even cause more harm.

For instance, there is no need to memoize a function that’s doing some basic calculation (like in the demo). Only use useMemo whenver you’re trying to prevent re-running expensive functions, that run a lot of time, or using a lot of resources. Why? Because useMemo keeps in memory the results of the functions execusion, and it might potentially grow big and ironically harm the performance of your App.

With useCallback things might get even worse: when not using useCallback, your old function will be garbage collected, but with useCallback it will stay in memory, in case one of the dependencies will be right again to return that old function version.

So when is it right to use useCallback ? When you actually see that not using it harms your performance, or will result in an unneccery heavy function execution (imagine in the useCallback demo, that this function performs an API call, and not just adding numbers. This is something worth preventing).

To summarise:

useMemo keeps a function from being executed again if it didn’t receive a set of parameters that were previously used. It returns the results of a function. Use it when you want to prevent some heavy or costly operations from being called on each render.

useCallback keep a function from being re-created again, based on a list of dependencies. It returns the function itself. Use it when you want to propagate it to child components, and prevent from a costly function from re-running.

The Complete Guide to Front-end Developer Interviews

Sveta Slepner — Wed, 01 Feb 2023 19:11:55 +0000

Interviews are hard, especially technical interviews where you’re expected to think, solve, and analyze all while the interviewer stares at you. But what people don’t realize is that being interviewed is basically just another skill, and skills can be honed with the right information and practice.

So if you’re on your job hunt as a Front-end developer right now, you’ve come to the right article, as this one will tell you all you need to know to be prepared!

About a year and a half ago, the company I used to work for was shut down, and all 100 employees found themselves seeking a new place. I worked there for more than 9 years, so starting a job hunt was unsettling. I knew that my JS skills are (probably) fine, but I didn’t know what to expect during technical interviews.

So based on my own experience, the experiences of my colleagues who shared the same fate, as well as my current practice as an interviewer myself, I decided to write down this article. It is my hope that it will help you prepare, and take away some of the concerns you might have about what awaits you.

What Kind of Questions Should You Expect?

Each company has its own interviewing strategy, but in the end, most of them fall under the same categories, and it doesn’t matter if you’re interviewing to GAFAM or a small tech company. These are the most common topics you’ll be interviewed about:

Javascript Questions

Well, as a front-end developer you obviously should know Javascript already, but you’re also expected to understand how it works and behaves. It doesn’t matter if in your day-to-day you work with Angular/React/Vue, you are expected to know the basics.

Some example questions could be:
A. Explain what the event loop is
B. Explain what a Promise is
C. Closure and Context questions (what is “this”)
D. What is the difference between an arrow function and a regular function?
E. Implement Array.prototype.map/reduce
F. What is a debounce/throttle function? Implement them.
G. Javascript prototypal inheritance questions

Some helpful resources:
5 Typical JavaScript Interview Exercises
Learning Advanced JavaScript
Javascript Garden
Eloquent Javascript

Algorithms

It is true that it’s unlikely you’ll ever need to traverse a binary tree while working as a Front-end developer (there are exceptions of course). But nonetheless, algorithm questions are very popular in interviews (especially if your goal is to work at GAFAM).

Array or Object related questions

Example:

Reverse a string
Write a function that checks if a word is a palindrome
Given a string of characters, return the character that appears the most often.
BFS/DFS questions (traversing a tree)

Example:

Write a function that solves a maze (the maze is a multidimensional array- with values of 0 — wall, 1 — floor, 2 — exit). The function receives a start coordinate and should return whether you can get out of the maze.
Linked List

Example:

Reverse a linked list
Find the nth node from the end of the linked list

You should also probably refresh your knowledge about the difference between Recursion and Iteration and about Time and Space complexity.

Some helpful resources:
40 Problems, Solutions, and Explanations
JavaScript Algorithms and Data Structures Masterclass — (Note: This one is no doubt the best Udemy course ever created, especially if you don’t have a degree in Computer Sciences, or if you need a refresher about algorithms and data structures).
Codewars (or any other equivalent site, like HackerRank or LeetCode).

What To Pay Attention To When Solving an Algorithm Question

A. Don’t rush to solve, it’s ok to ask for a few minutes to think.

B. When you do start solving, it is highly recommended that you talk about what you’re doing, even if you’re not sure about your thoughts. The examiner usually looks to understand your process of thinking. It is not always necessary to reach a perfect and working solution. If you’re not comfortable talking aloud, or just not used to it, practice at home by solving some example questions.

C. If you can, you should first write your plan of action in words or pseudo-code. This will show the interviewer that you do not rush to solve things and that you can plan.

D. If you get stuck at the beginning, don’t panic! Start with the simple things. Think about input and output. Solve edge cases.

E. Pay attention to the code effectiveness of your solution. If you understand that the complexity is not really good, say it out loud, and try together with the examiner to reach a better solution.

F. It’s totally fine to ask questions. A good examiner will try to help you reach a solution.

G. You’re usually expected to solve these type of questions on a whiteboard/piece of paper. Since it’s not how we usually write code, you may find it’s harder to think like this. This is again something that worth practicing beforehand!

React/Angular/Vue (Home) Assignment

Some places will require you to build some sort of a simple app using a specific framework/library. Depending on the company, it can either be a home assignment, or you’ll have to do so while in the companies office. If it’s the latter, bring your own laptop, so you can use your own familair IDE and operating system.

In most cases, you’ll be given some sort of public API and be required to work with it in some way.

This is done to see the way the candidate writes actual code, so here are some things to pay attention to:

A. Keep your code clean. Use indentation, provide meaningful variable names, remove unused code.

B. Use best practices of the given framework.

C. Think about things like:

Debounce requests sent to the server.
Prevent server calls when < 3 characters are typed.
Take care of edge cases like missing information from the API.

D. Your CSS skills are important too! Be comfortable with using Flexbox (don’t use float to align containers 😉).

Logic Questions

I admit. I really dislike this type of question myself. I don’t understand how they can help anyone evaluate your value as a developer. But some companies still ask them…
You can’t really prepare for these ones (maybe read about some common questions?), but just know that they do exist.

Example:
You are standing in a room with three light switches. The switches all correspond to three different light bulbs in a nearby room that you cannot see into, but you can go in one time only. With all the light switches starting in the off position, how can you find out which switch connects to which light bulb?

Talking About Yourself

Last but not least, there’s a part where you need to talk about your past experience.

If you’re applying to your first job as a developer, make sure to have some project you’re passionate about or maybe contribute to some open-source library.

Be ready to discuss the nitty-gritty. For example, why did you choose library A instead of B?

If this isn’t your first rodeo, you will need to talk about a feature or product that you were responsible for at work. In details. The Interviewer would also likely want to hear about your personal contribution to the team.

You should practice this conversation with a friend so that you have feedback! It would be so much easier for you if you come prepared.

And Most Importantly: A Failed Interview does NOT Define You!

Remember, a failed interview doesn’t say anything about how good a developer you are. As I mentioned in the beginning, interviewing is a skill of its own. In your day-to-day life, you have StackOverflow and co-workers at your disposal, and you’re not expected to write code on a piece of paper. Interviews are simply not something you’re used to doing, so you need to try it a few times to grasp how it’s done. Prepare and study, but don’t be hard on yourself if you don’t pass. Try to learn something from each interview, and eventually, you will succeed!

Good luck! :)

Cover photo by Christina @ wocintechchat.com on Unsplash

Getting Started With Three.js

Sveta Slepner — Tue, 31 Jan 2023 21:46:18 +0000

The ability to render 3D objects in the browser opens up many exciting possibilities for creating interactive experiences. Whether you’re looking for a new way to showcase products on your e-commerce site, creating stunning landing pages, or maybe even developing a game.

Since handling WebGL directly (JavaScript API for rendering interactive 2D and 3D graphics within any compatible web browser) can be complex, libraries, such as three.js, provide a simplified way to deal with rendering, animating, and interacting with 3D objects, while doing all the heavy lifting behind the scenes.

With that being said, three.js itself can still be a little overwhelming for developers who have never dealt with 3D before. Hopefully, this article will get you up to speed and present the necessary basis, that may assist you even if you’ll require more advanced features later on.

What does it take to render a simple cube?
The reason why working with 3D for a web developer might be confusing at first, is that even a simple task such as rendering a cube requires some knowledge in 3D jargon.

If for instance, someone tells you, the web developer, to render a red box, I bet what you have in mind is “ok, I’ll create a div, use some CSS to size, place, and color it”. Pretty straightforward.

However, to do the same in 3D will require you to:
A. Create something called a “scene”
B. Define a cube geometry
C. Create a material and attach it to the cube (to make it red)
D. Create a camera
E. Add lighting
F. Tell three.js to render all that

The scene

In three.js, a scene is like a container that holds all the objects used to render our 3D image. Think about a theatre stage, where we place the actors, the set, and the lighting.
In the same manner, we assign 3D objects and lighting to a scene.

// Creating a scene
const scene = new THREE.Scene();
const geometry = new THREE.BoxGeometry(10, 10, 10);
const material = new THREE.MeshStandardMaterial({ color: 0xff0000 });
const cube = new THREE.Mesh(geometry, material);

// Assigning a 3D object to our scene
scene.add(geometry);
const directionalLight = new THREE.DirectionalLight(0xffffff, 1);
directionalLight.position.set(0, 2, 10);

// Adding a light source to our scene
scene.add(directionalLight);

And just like we might have multiple stage sets in our theatre, each showing a different play, we can create multiple scenes and switch between them, or render them simultaneously.

Source: https://threejs.org/examples/?q=camera#webgl_camera

3D geometry

A 3D geometry is basically a set of instructions for “how to create a 3D shape”. It consists of faces, edges, and vertices.

Source: https://en.wikipedia.org/wiki/Polygon_mesh

Luckily, three.js provides us with some built-in geometry classes, such as BoxGeometry, SphereGeometry, CylinderGeometry, and so on.

For example, to create a simple box, all we need to do is to provide the width, height, and depth. We don’t need to delve into the complexities of defining all the faces ourselves.

The size unit used in three.js represents meters, so 1 unit = 1 meter.

const geometry = new THREE.BoxGeometry(10, 10, 10);

Source: https://en.wikipedia.org/wiki/Shape

In case you’re not happy with the existing geometries or need to create your own geometry classes, it is very possible. You can see some examples provided by three.js here.

Materials

Imagine holding two cubes in your hands, one made from glass, and the other from concrete. Both maybe have the same shape, but they look different and have distinct physical attributes such as reflectiveness, surface, and opacity.

In the 3D world, we use materials to define such attributes for our 3D objects.

With three.js we can either create our own materials with the built-in Material classes (such as MeshMatcapMaterial or MeshLambertMaterial), each has its own attributes, or load materials externally using MaterialLoader.

// A basic material, just coloring our cube red
const material = new THREE.MeshStandardMaterial({ color: 0xff0000 });

Texture maps are also worth mentioning. These are image files that can be used to define much more detailed materials, and make them look real. There are many types of texture maps, such as “diffuse map” which defines the colors, or the “normal map” which defines the surface of our object. Typically multiple texture maps are applied together. This great article explains each texture map in detail.

Multiple texture maps are used to define the realistic texture of a ball of grass and soil

Mesh

A mesh is an object representing part of the model. It contains a geometry and its material. A 3D model can be constructed from multiple meshes.

Each highlighted part is a mesh. All meshes combined define the model.

const geometry = new THREE.BoxGeometry(10, 10, 10);
const material = new THREE.MeshStandardMaterial({ color: 0xff0000 });
const cube = new THREE.Mesh(geometry, material);

Loaders

Sometimes we would like to import 3D models from existing files created by 3D modeling programs, and not create them from scratch. For that, we can use loaders, which are functions that are responsible for loading such files and converting them into three.js objects.

There is a different loader for each separate type of 3D file. For instance, loading a GLTF file would look like this:

import { GLTFLoader } from "three/examples/jsm/loaders/GLTFLoader.js";

const loader = new GLTFLoader();
loader.load(
    // resource URL
    'https://somesite.com/3dmodels/fox.gltf',
    // called when the resource is loaded
    function ( gltf ) {

        scene.add( gltf.scene );
    },
    // called while loading is progressing
    function ( xhr ) {

        console.log( ( xhr.loaded / xhr.total * 100 ) + '% loaded' );

    },
    // called when loading has errors
    function ( error ) {

        console.log( 'An error happened' );

    }
);

Did you notice that the GLTFLoader class is not imported from the “three” packages directly but from some mysterious “examples” folder? This is because loaders are not part of the core three.js library, but an extension. Despite the misleading name (“examples”), this folder contains some official extensions, that are maintained together with the base package.

The idea is that if you’re not happy with one of them, or need some extra features, you can simply copy these files to your project and modify them as you see fit. Of course, you can also use loaders or other extensions made by other developers.

Camera

A camera is like a window to our scene. Without a camera defined, we simply see nothing. When defining a camera we create what is called a “frustum” — a mathematical term for a four-sided rectangular pyramid with the top cut off.

const perspectiveCamera = new THREE.PerspectiveCamera(
  50, // fov — Camera frustum vertical field of view.
  width / height, // aspect — Camera frustum aspect ratio.
  1, // near — Camera frustum near plane.
  2000 // far — Camera frustum far plane.
);

There are multiple types of cameras in three.js, but the two most useful ones are the perspective camera and the orthographic camera.

Perspective camera — In this mode, depth perception is emulated in order to reflect the way the human eye perceives the world. For example, if one cube is positioned closer to us than the other, it will appear to be larger. This is the most common camera you’ll probably use.

Orthographic camera — With the orthographic camera, there is no depth perception, so no matter where the object is placed in the scene, it will look the same size. This is useful for isometric games, for instance.

An isometric video game using an orthographic camera

Lighting

Just like in real life, without lights, our scene would become pitch black.

Three.js has multiple built-in light sources we can use and even combine to create the perfect setting.

It’s worth noting that some light classes support casting shadows, while some don’t, and it depends on their physics. For instance, “Dynamic Light” is a light that gets emitted in a specific direction. This light will behave as though it exists infinitely far away and the rays produced from it are all parallel. A common use case for this is to simulate daylight. Since it’s a one-directional light, it can emit shadows.

The AmbientLight on the other hand is a light that globally illuminates all objects in the scene equally. Since every spot in the scene receives the same amount of light, AmbientLight can’t be used to cast shadows.

When defining a light we would usually provide color and intensity.

const directionalLight = new THREE.DirectionalLight(0xffffff, 1);
directionalLight.position.set(0, 2, 10);

Lights can also come from external sources, like HDR files (An HDR is a 360-degree high dynamic range image wrapped around a 3D model.)

Shadows

Casting shadows is a pretty expensive calculation, so in three.js it’s turned off by default. In order to support it we will need to:

A. Turn on shadow support for the renderer (see next section about what a renderer is). We will also need to provide a type of shadow map, each provides a little different effect and calculation efficiency. See the details here under “Shadow Types”.

renderer.shadowMap.enabled = true;
renderer.shadowMap.type = THREE.PCFSoftShadowMap;

B. Tell each individual mesh if it should emit and/or receive shadows.

cube = new THREE.Mesh(geometry, material);
cube.castShadow = true;
cube.receiveShadow = true;

C. Allow the light source to cast a shadow. We also should provide the shadow map size and bias, which modifies the shadows pixelation.

const spotLight = new THREE.SpotLight(0xffffff, 1);
// make it cast shadows
spotLight.castShadow = true;
spotLight.shadow.mapSize.width = 1024;
spotLight.shadow.mapSize.height = 1024;
spotLight.shadow.bias = -0.0001;

Renderer

The render class is used for… well… rendering all of the scene components into the canvas element. This one is pretty straightforward.

// define the renderer
  renderer = new THREE.WebGLRenderer({ antialias: true, alpha: true });
  renderer.setPixelRatio(window.devicePixelRatio);
  renderer.setSize(window.innerWidth, window.innerHeight);

  // append the rendered to the dom
  document.body.appendChild(renderer.domElement);

  // render the scene
  renderer.render(scene, camera);

You will need to provide the desired canvas size using the setSize property, and the pixel density of the device. Note that in a case where the size of the canvas is responsive and depends on the page size, we should update the renderer and camera on window resize.

function onWindowResize() {
  camera.aspect = window.innerWidth / window.innerHeight;
  camera.updateProjectionMatrix();
  renderer.setSize(window.innerWidth, window.innerHeight);
}

Animating

More often than not, we’re not going to use three.js just to render one static 3D image. We would want the user to interact with the scene or create animations. To make three.js re-render the canvas, we would need to call renderer.render(scene, camera); each time.

If our changes are frequent, however, for instance when we add an auto rotation effect to our scene, we can simply do something like this:

function animate() {
   // Schedual the next update
   requestAnimationFrame(animate);
   // Some other changes that should occur on animate
   // for instance, here we can rotate the cube a litle on every frame
   cube.rotation.x += 0.01;
   cube.rotation.y += 0.01;
   // re-render
   renderer.render(scene, camera);
}
animate();

This is also required to support loaded 3D files which come with their own animation.

Camera controls

Camera control is another type of extension that adds a layer of interactivity to our scene, allowing the users to zoom in and out, rotate the scene or even navigate within it.

Let’s take as an example one of the more common camera controls: the orbit controls, which just by defining them lets the user rotate and zoom into the scene.

const orbitControls = new OrbitControls(camera, renderer.domElement);
Orbit controls have some other neat features out of the box, like adding autorotation to the scene.

Note that you will have to add orbitControls.update() to your animate function in order to support it.

Mouse events

Three.js essentially rendered a canvas, and as such, picking up mouse events is trickier than what you might be used to.

So what happens if you need to track clicks or hover over a 3d object? That’s what the Raycaster class is for. Raycasting is used for working out what objects in the 3d space the mouse is interacting with.

Here’s a basic example of how to pick up clicked on objects:

 // Raycaster
  const raycaster = new THREE.Raycaster();
  const pointer = new THREE.Vector2();

  function intersect(pointerPos) {
    raycaster.setFromCamera(pointerPos, camera);
    return raycaster.intersectObjects(scene.children);
  }

  window.addEventListener("click", (event) => {

    // calculate pointer position in normalized device coordinates
    pointer.x = (event.clientX / window.innerWidth) * 2 - 1;
    pointer.y = -(event.clientY / window.innerHeight) * 2 + 1;

    // calculate objects intersecting the picking ray
    const intersectedObjects = intersect(pointer);

    if (intersectedObjects.length > 0) {
      // do something with the objects our mouse intercted with
    }
  });

And a demo, so you can see it in action:

And that should cover all the basics. Hopefully, three.js makes a little more sense now!

Extra read

https://discoverthreejs.com/ — An amazing free online three.js book and guide. A great resource to learn from.
https://threejs.org/examples — the three.js documentation is not beginner-friendly, but it does worth using the examples section to get ideas and learn about more complex topics.