Sveta Slepner Blog RSS Feed

7 Ways I'm Utilizing the Power of AI as a Front-end Developer

Mon, 06 Jan 2025 00:00:00 GMT

It's hard to believe Chat GPT was introduced to our lives merely two years ago. I'm old enough to remember how Google revolutionized my Internet use, but no other technology has disrupted the industry to such an extent since then. As a front-end developer, I’ve embraced tools like ChatGPT and its competitors (looking at you, Claude) to make my day-to-day work more efficient. So now, I would like to share some ways I’ve been using it with you.

But before we dive in, a warning — AI isn’t a magic wand that replaces the need for understanding code. If you’re a junior developer, take this as a friendly heads-up: AI's answers can range from spot-on to complete nonsense. Sometimes, it’s just close enough to be misleading. So, while AI is an incredible tool, it’s only as effective as your ability to evaluate and tweak what it gives you. Think of it as a coding assistant, not a replacement for your skills.

Also, don’t forget to be polite—you never know when AI might develop a conscience. ;)

1. Generate Layout Code From an Image

A recent addition to ChatGPT (new as of the end of 2024) allows you to provide it an image of an interface design, and ask it to convert it to actual code. You can even be specific with what libraries you want it to write the code with: "Convert this image to React with styled-components". This is a pretty amazing and time-saving feature, but it's not 100% perfect, so be careful!

Here's the result of my asking ChatGPT to convert this screenshot from Figma to React.

The image:

The result:

As you can see, the styles aren't 100% correct, but the most tedious part, the layout, was done correctly.

Example prompt:
"Based on the attached image, please generate react code with styled-components" "Based on the attached image, please generate vue code with Tailwind CSS"

2. Generate CSS Animations

I've been a front-end developer for over 15 years, and yet, CSS animations remain a mystery to me. While I'm pretty good with CSS, animations feel like an entirely different beast. I can never seem to make them look smooth. Whenever I need one, I usually end up searching for a good example on CodeSandbox.io. However, now with the power of AI, I can ask it to generate it for me, and even give it instructions on how exactly I envision it (but can't execute it myself).

Example prompt:
"Create a CSS animation of a waiving div"
"Create a CSS animation of a bouncing div. The animation should last 1s and repeat 3 times" You can also ask for improvements: "It should feel more 'bouncy'"

3. Fixing TypeScript Errors

We’ve all been there: TypeScript is yelling at you, and you have no idea why. This is especially annoying when dealing with third-party libraries, where you're not in control. Instead of hunting through docs or Stack Overflow, you can simply paste the error into an AI chat and get tailored advice almost instantly. You can even paste the code itself and ask it to fix the issue for you. And, if you have some JS code you would like to convert to TS, it can do that for you as well.

Example prompts:
"Please explain the following TS error [ERROR]"
"Please fix the following TS code [YOUR CODE]"
"Please convert the following code from JS to TS [YOUR CODE]"

4. Converting One Code to Another

Need to convert a vanilla JS script into a React component? Or maybe some old jQuery code to something more modern? AI handles these transformations with ease. It’s not always perfect, but it’s usually a solid 90% there, which is a great jumping-off point. I recently tried to convert some Hammer.js code to vanilla JS events and was pretty amazed at how accurately Claude did it.

Example prompts:
"Please convert the following code to [YOUR CHOICE HERE]"

5. Writing Tests

TDD or not, writing some test coverage for your code is important to making our codebase more reliable and less prone to future issues. However, writing tests is not necessarily fun and can sometimes be time-consuming.

From my experience, it's pretty good at covering multiple use cases, including edge cases, and it even creates test titles based on my requirements (For example, Given-When-Then).

Of course, the reality is not that simple, and in larger code bases testing is far more complex, but AI can still help you with at least determining what cases you might want to test for and do some of the heavy lifting.

Example prompt:
"Please write unit tests for the code I'll give you. Use GIVEN WHEN THEN format for the test title. [YOUR CODE HERE]"
"Please write react testing library tests for this component"

6. Generate Mock Data

You are waiting for your fellow Backend developer to finish the API you need for the new UI you're working on. In the meantime, you need some data to work with. Creating mock data is a tedious process manually, especially if the data structure is complex, or requires multiple API calls. Using AI it takes two seconds to generate any kinda mock data you need, and if your company works with Open API Schema, it's even simpler, since you can simply provide the AI with the schema, and not even give it examples.

Example prompts:
"Based on the attached API schema, create a mock data for the [API] API [YOUR SCHEMA]"
"Based on the following example, please create a mock data"

7. Accessibility

Web accessibility is an important aspect of building inclusive applications, ensuring they can be used by everyone, including people with disabilities. I believe it also makes the experience better for everyone since it simplifies the UX. Sadly, it is often overlooked, or shoved under the rug until legal knocks on the door. Also, it's not so straightforward, and there are tons of rules and special attributes you need to learn about to make your app more accessible. AI can help you with some of that, and give you suggestions for improving accessibility, such as adding proper ARIA roles, fixing contrast issues, or ensuring keyboard navigation.

Example prompts:
"Please suggest how I can make the following component accessible"

✨ Bonus round! Here are some more ways I'm using AI, but which are not specific to Front-end ✨:

Simplifying Code

My code writing style involves throwing everything on my mind into the IDE. Once the code works, I start a cleanup. I consolidate code, rename variables, and move functions around. Also, I believe in KISS (keep it stupid simple), so that "future me/colleague" can read my code and understand it without too much hassle (and too many comments). Using AI allows me to make some shortcuts in that process, provide it with complex code, and ask it to simplify it.

Example prompts:
"[YOUR CODE] please simplify this code"

Boiler plating

Starting a new project or feature can be intimidating when you’re staring at a blank screen. And it's especially true if you're trying some new programming language or library.

Example prompts:
"Generate a Tanstack Query hook to fetch paginated data from an API."
"Generate a boilerplate "to-do list" react app with Tanstack Router and Tanstack Query"

-- Special thanks to Eitan Peer for reviewing this article --

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

Mon, 06 Feb 2023 00:00:00 GMT

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/**

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.

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.

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".

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.

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 thewith: 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.

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}}"

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!

Getting Started With Three.js

Tue, 15 Mar 2022 15:00:10 GMT

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.

React — 5 Things That Might Surprise You

Tue, 08 Jun 2021 11:00:00 GMT

The React library is pretty straightforward and is relatively easy to get into, especially with the wide variety of materials that exist to help you learn it. But every tool has its share of tricks or issues that these tutorials usually don’t cover. You get to learn them when someone reviews your code, or worse — when you’re facing a problem and are desperate to find a solution. Hopefully, with this article, I might reveal some of these things about React, and maybe even surprise you!

1. Setting the state by using the previous state is unpredictable. State management is the foundation of React, and while useState is probably the most common hook, there might be some unawareness of its actual behavior.

Let’s have a look at the following component:

import React, { useState } from "react";
import "./styles.css";

export default function App() {
  const [counter, setCounter] = useState(0);
  return (
    <div className="App">
      <h1>Counter: {counter}</h1>
      <button
        onClick={() => {
          setCounter(counter + 1);
          setCounter(counter + 1);
        }}
      >
        +
      </button>
    </div>
  );
}

What would you expect the value of the counter state to be, after a user clicks on the button?

A. 2
B. 1

Not sure? Try it out yourself:

Well, whether you knew that, guessed correctly. or just tested the demo — the answer is B!

The reason is that during our state update we used the previous state value: setCounter(count + 1). Essentially, the state setter function is wrapped inside the functional component closure, so it is provided with the value that was captured in that closure. It means that when it will eventually be executed (the state setter function is asynchronous), it might hold a state value that is no longer relevant. On top of that, consecutive execution of setState might cause React’s scheduling algorithms to handle multiple very fast state updates using the same event handler.

The same problem might also occur when setting the state inside an asynchronous function:

onClick={() => { 
   setTimout(() => { setCounter(counter + 1); ), 1000);
}};

But, no worries, React actually provides an easy solution to this problem — “functional updates”.

setCounter((prevCounter) => prevCounter + 1);

Instead of passing the value directly to setCounter, we pass a function. This function receives as a parameter the previous state. This way we can be sure that React provides us the correct value of the previous state, and avoid the scenarios that might cause the unexpected behavior.

Whenever your state update is relying on the previous state, be sure to use functional updates!

Another benefit of this is to allow correct memoization of functions, since passing the value as a dependency would re-create the function on every state change.

// incorrect
const update = useCallback(() => {
   setCounter(counter + 1);
}, [counter]);

// correct
const update = useCallback(() => {
   setCounter(prevCounter => prevCounter + 1);
}, []);

2. You can use useRef to store a static variable
We are accustomed to using the ref mechanism in React as a means to access an element’s DOM node, whether because we need it to calculate its size, set a focus status, or basically do anything React can’t do naturally. But refs can also be used for a different purpose — something that we could achieve for free with class components, but we can’t with functional ones — keep a static variable that won’t be recreated on every render.

Why would we need to do so? Well, it really depends on the situation. For instance, let’s say we’re using some javascript library that was not written for React.

In this example, we have a class Dog. Dog has two functions — one to set its name, and one to bark it.

If we tried to create the instance of this class using a simple variable, what would happen is that in case (for any reason) the component is re-rendered, a new instance will be created. So any changes we did so far will go away.

But by using a ref, we will be able to keep our instance alive, until we decide to override it by setting a new value to ref.current.

someRef.current = newValue;

3. React can be forced to re-mount a component
Writing to the DOM is one of the more costly actions that can be done by React. This is why we usually don’t want to remount components unless it’s absolutely necessary. Alas — sometimes we must, for various reasons. So on that occasion, how do we even tell react to unmount and immediately mount again a component? With a simple trick — by providing a key to our component, and changing its value.

The key prop is a special React property you most likely have learned about the first time you tried to render an array of components.

A key is something that helps React keep track of an element, even if we’ve changed its position within our component’s structure or re-rendered the parent (Otherwise each render would cause the entire component array to be re-mounted, which is bad for performance).

Using this mechanism, we can trick React to think a component is not the same as its previous self and cause it to re-mount.

See for yourself:

Why would we need that at all, by the way? Well, it’s a quick way to create a “reload” button for your app, for example. Another use case is mixing DOM handling with React, where we want React’s state to reflect updates that were made to the DOM from “outside”.

But it should still be avoided unless it's the last resort.

4. Context doesn’t work the way you would expect it to
Context API is a great built-in solution for sharing state between components and avoiding “prop drilling” — passing props multiple levels down — from one component to the other, sometimes just for the sake of passing them down where it's actually needed.

While it’s very useful, it also has its limitations.

When used for recurring or complex updates, it’s not that efficient. Quoting Sebastian Markbage, a Facebook engineer:

"My personal summary is that new context is ready to be used for low frequency unlikely updates (like locale/theme). It’s also good to use it in the same way as old context was used. I.e. for static values and then propagate updates through subscriptions. It’s not ready to be used as a replacement for all Flux-like state propagation".

Even the React-Redux team had to revert parts of the library re-written with context API in version 6, simply due to a significant performance hit compared to its previous version (Now React-Redux only uses context to pass down the store reference).

Another major issue is the incapability of components to subscribe only to part of a context (when a context value is an object, not a primitive).

Let’s have a look at the following example:

In this example, the context stores an object containing two entries: name and age. We then have two components subscribed to this context. One is using just the age, and the other the name. But — when updating just one of the entries, either the name or the age, both <Name> and <Age> components are re-rendered. You can access this demo here and see how it works.

The fact that all components subscribed to a context holding a non-primitive type value are re-rendered is obviously inefficient, and on some occasions might cause a performance issue.

There are some native solutions to this issue, but most of them are cumbersome. You can also consider using a 3rd party library, such as use-context-selector, which makes dealing with this problem much easier.

5. React has a whole API to deal with the children prop
Passing children to a component is a very common pattern, whether you’re using composition, or just writing a reusable wrapper component.

But, did you know that instead of just rendering the children, React also provides you an API allowing you to do all sorts of things with it?

First of all — children can be a string, an object, or an array of any of these types. It makes it quite hard to iterate over the children like this, so we can call toArray to transform children to an array:

React.Children.toArray(children)
// If you want to use map/forEach:
React.Children.map(children, fn)
React.Children.forEach(children, fn)

We can also call count to know how many children there are, avoiding the same hassle:

React.Children.count(children)

If you need to enforce a single child in your component (I recently noticed formik does so), you can simply include the following line in your component, and React will run the check and error handling for you:

React.Children.only(children)

You can use the following sandbox to play around with it:

And that was it! I really hope some of these will be useful for you. Please feel free to share in the comments any other React tricks that you know!

The Complete Guide to Front-end Developer Interviews

Sat, 02 Jan 2021 15:04:10 GMT

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).

1. Array or Object related questions

Example:
1. Reverse a string
2. Write a function that checks if a word is a palindrome
3. Given a string of characters, return the character that appears the most often.

2. BFS/DFS questions (traversing a tree)

Example:
1. 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.

3. Linked List

Example:
1. Reverse a linked list
2. 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:
1. Debounce requests sent to the server.
2. Prevent server calls when < 3 characters are typed.
3. 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

Understanding the difference between useMemo and useCallback

Fri, 28 Aug 2020 15:00:10 GMT

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.

Why Web Accessibility is Far More Important Than You Think

Sun, 02 Jun 2019 15:04:10 GMT

Web Accessibility is a relatively new topic web developers and commercial websites have to tackle. It takes effort and might even be a costly process, but the advantages of a web-accessible page are far greater than you would think (and not just because it’s the morally right thing to do, or because of accessibility laws). Let’s dig into these benefits and also learn some ways to make your website a better place to visit.

The first time I came face to face with web accessibility was a few years ago, when I was working for a SaaS company called Webcollage, which provided a rich content distribution solutions for vendors. I returned to the office from a nice summer vacation in Europe and thought I was going to have a quiet “the day after a vacation” day, just sorting my inbox and catching up. Boy was I wrong. Apparently, the day before, one of the company’s major partners sent a requirement to now make our product accessible. This partner was kind enough to provide a list of 98 accessibility issues we had to fix in order to meet the required standard.

And let me tell you, this was not easy. The real problem is that web accessibility is a huge topic. And since, as said, it’s relatively new, most of the time the issues you stumble upon are not something you can find a solution to on Stack Overflow. The longer you dig into it, you figure out just HOW MANY people it actually affects, how there are disabilities you never even thought about.

So how many people can’t use your site?

When ignoring web accessibility you’re potentially alienating one billion people, or 15% of the world’s population, who experience some form of disability, whether auditory, cognitive, neurological, physical or visual. This includes your grandparents who no longer can read the tiny font your site use or maybe hear the video’s audio. Maybe a girl who went on a ski trip, broke her arm, and now can’t use a mouse for a month. Even a perfectly healthy guy watching a video in the subway could use accessibility aid. Let’s say the train is so loud, he can’t hear your video properly (or maybe he forgot his headphones, so being polite he’s watching the video on mute).

By making your site accessible, you automatically increase the target audience and add new groups for which it did not provide any service before. Subsequently, you get increased traffic and thus the number of conversions increases as well.

Moreover, making these adjustments usually means it makes the site simpler and easier to use for the general public as well. As a result, users often tend to make more extensive use of the site, which leads to more conversions.

It can even make search engines robots happier! A simpler, better-structured site means search engines will treat your site better as they can get more information. Better SEO means more traffic from search engines, and again -> More users -> More conversions.

So why don’t all websites just fix their code?

As my teammates and I experienced first hand, we had to re-learn how to build certain parts of our product to make them fit the Web Content Accessibility Guidelines (WCAG). We also, for the first time, experienced assistive tools in order to test the new accessibility features more authentically (And trust me, when you hear the screen reader yell the 350 characters of an image URL because it didn’t find a description parameter on the image, you start to understand what a cluttered mess a typical website might feel like for a visually impaired person).

Also, remember that fixing the product isn’t enough. We now had to take accessibility into account for each new feature, which takes more development time for us and added time for the QA team to test it.

Making a site accessible, like everything else, has a price. It requires substantial changes in the structure of the site, from all aspects — design, programming, and even content. This means many hours of work, which cost money. And in the commercial market, people are in no hurry to spend time and money to change “what’s already working when no one’s complaining”.

And while more and more countries are adding laws to ensure the web is a nicer place to all people, even if there is no such law in your country, you might consider the benefits stated above, even if it appears costly at first.

Where do I begin?

So let’s say you want to add accessibility aid to your site. “Where do I begin?”, you’re probably asking. First, there are tools online that can analyze your website for accessibility issues, such as this one. Also, there’s an official guideline I mentioned before called “Web Content Accessibility Guidelines” or in short “WCAG”, which you access from here. It categorizes the requirements into 3 levels, ranging from A — the lowest to AAA the strictest and most accessible. While it’s quite informative, it doesn’t always provide code examples, so sometimes you’ll have to figure it out.

However, here are some points to get you started:

Add Closed Captions to your videos — Is there a narration or people talking in your videos? Provide a closed caption file to complement the spoken text.
Never ever use <table> tags for anything else then, well, tables — If you need to show a comparison between data, then sure, go ahead (but read how to implement tables correctly to make it easier for screen readers to read the data off it). This is obviously the correct practice anyhow (for years now…), so then again, if you did put things into tables just out of convenience, now you’ll have the chance to do things right!
Use headers correctly — There’s a reason why there are 6 different header tags! While it doesn’t really matter for the average user, it’s really important for screen readers. When used correctly, the screen reader will be able to easily map interest spots in the page for the user. (And it’s also better for SEO!)
Tab navigation — Some users can’t use a mouse, such as the visually impaired, or people with motoric disabilities. Make sure your site can be navigated using the Tab key, and links and buttons activated using the Enter keys. Also, active elements should be marked using a distinct color outline. Modern browsers do it for you (for the most part), but sometimes developers disable this CSS style because it appears on any focus event.
Add an “alt” parameter to images — If you don’t explain what’s in the image, visually impaired people have no way of telling what information you’re trying to convey. Some images are fine with an empty alt, depending on the situation, but please add it to all of your images nonetheless (Use this guide to help you out). What happens to images without an “alt”? The screen reader will read the image’s URL instead. NOT FUN.
Present a way to quickly pause videos and animations — People with Epilepsy need a fast way to close any moving animation/video that pops up to the screen. For example, if you trigger an overlay with a video, add an option to close it with the ESC key.
Make sure the color contrast between a text and its background is high enough — Don’t put pink text over a red background element. It’s actually an inconvenience even for people with perfectly fine eyesight but for people with a visual disability its a real struggle. You can check the color contrast rate using this tool.
Use buttons, not divs that simulate buttons — There’s really no real reason not to use a button when you need a button (other than it takes a few more styles to make it look the way you want). But if you do, please make sure that:

You use an aria attribute to state that this div is used as a button (role=” button”)
Make sure you can activate it using key presses, and not just mouse clicks.

Learn about Aria attributes — Aria attributes are part of the Accessibility API available in all modern browsers, which allow assistive technologies to better understand the elements that reside in your page. For example, do you need to inform the user that an error occurred? Without the correct aria attribute, a screen reader won’t be able to detect that a new message popped up.
Can color blind users see your images clearly? — It’s a bad idea to put text and numbers in images, which are the main cause of problems for people with color blindness. However, if you do, and you want to understand the problematic parts of the image, or even provide an alternative image (with no effort!), you can use some out of the box tools, from an asset management company called Cloudinary (Disclaimer: I work there! :)).

To conclude, making your site accessible is not a simple task. It takes some thought, time and even money. However, your benefit from it is far greater than it looks on a first glance. Take your time, but do this change, to make the web a better place.

Make Your Content Look More Interesting With CSS Shapes

Sat, 30 Mar 2019 10:00:00 GMT

For the longest time newspapers, magazines and books had one advantage over content designed for websites. It’s rather a small feature, but one that makes content look so much better — the ability to wrap text around images and shapes other than a rectangle. But fear not, because with the help of a CSS feature called ‘CSS shapes’, you can now achieve that as well!

Since the beginning of the internet, we were trained to see our web sites as a collection of boxes. Even when we got a native CSS solution for creating circles, triangles and even trapeze and stars (either by using CSS tricks or by the modern clip-path property) these were all a mere illusion, since they’re still part of a box. As you can see in the example below, I’ve create a floating circle, which is basically just a div with a border radius — alas, the content still wraps itself around the circle’s box container:

The float area is a box, so the text can’t wrap itself around the real circle.

However, thanks to CSS shapes, we have the power to break this limit and make browsers wrap text around any crazy shape that comes to mind.

Circles, ellipses, complex polygons, you name it. We can even use images with transparent backgrounds and get the same effect!

Now we’ve seen it in action, how does CSS shapes work?

CSS shapes is a set of rules for wrapping content around custom shapes and path. It does not actually draw the shape, but rather gives instructions to the browser on what the float area looks like (We can still draw the shape using the clip-path CSS property, this feature just isn’t part of CSS Shapes). Currently it only works when paired with a float property (in the future, with the help of CSS Exclusions, it will be possible to do so without it). Also, it’s not possible to wrap text from both sides of a shape.

The CSS Shapes specification Level 1 defines three properties:

shape-outside
shape-image-threshold
shape-margin

shape-outside

The shape-outside CSS property defines a shape around which adjacent inline content should wrap. By default, inline content wraps around its margin box; by accepting different functions, shape-outside provides a way to customize this wrapping.

Some supported values are:

circle()

.basic-circle {
  width: 150px;
  height: 150px;
  shape-outside: circle();
  float: left;
}

// Circle with a custom radius
.radius-circle {
  width: 150px;
  height: 150px;
  shape-outside: circle(30%);
  float: left;
}

// Circle with a custom radius and position (which defines the center of the circle)
.radius-position-circle {
  width: 150px;
  height: 150px;
  shape-outside: circle(50% at 0 50%);
  float: left;
}

polygon() —The polygon() function allows you to “go crazy” and create any kind of shape. It gets as an argument, a list of at least 3 coordinates. This, for example, is how you would create a simple 5 pointed star:

.star-shape {
  width: 150px;
  height: 150px;
  shape-outside: polygon(50% 0%, 61% 35%, 98% 35%, 68% 57%, 79% 91%, 50% 70%, 21% 91%, 32% 57%, 2% 35%, 39% 35%);
  float: left;
}

Creating shapes by hand is a bit of a pain, so you can use online tools such as this one to generate the correct CSS, which you can just copy-paste to your project.

url() — With this function you can create dynamic float borders from an image. It only supports png/gif/svg formats thought. Also note that you need the actual image present as an <img> tag for it to work.

<img src="some-image.png" class="custom-shape" />
<p>some text...</p>
<style>
.custom-shape {
  float: left;
  shape-outside: url(some-image.png);
}
</style>

Other supported shapes are ellipse() and inset().

Note: A useful property to use along with shape-outside is clip-path which takes the same values (except for url) and creates a visible shape.

shape-image-threshold

When using shape-outside along with an image value (using the url() function), the shape-image-threshold property is used to adjust the minimum opacity level of pixels that will be used to create the shape. Its value must be in the range between 0 and 1.

.shape-from-image {
  float: left;
  shape-outside: url(some-image.png);
  shape-image-threshold: 0.1;
}

shape-margin

If the shape you created with shape-outside is too close to the text, you can adjust its margin from the content using this property.

.circle {
  shape-outside: circle(50%);
  shape-margin: 20px;
  float: left;
}

Browser Support

Unfortunately CSS shapes level 1 is not supported by IE11 and not even by Edge, however support from other browsers is not too bad! You can still make your page look better on these, and just let them fallback to the old behavior on non supported browsers, or you can use a polyfill, created by Adobe.

https://caniuse.com/#feat=css-shapes

Future Features

Currently we can only float text around shapes, but when CSS Shapes level 2 hit the shelves, we will get a new feature called “shape-inside”, which will let us put text inside shapes!

https://drafts.csswg.org/css-shapes-2/#shape-inside-property

Conclusion

We learned that we can break the limits we were previously set, and by using some simple CSS, make our web pages more interesting to look at! I really hope this little article will inspire you to test these neat features :)