DEV Community: Karl Taylor

Creating a Switch Toggle in React using styled-components.

Karl Taylor — Wed, 15 Dec 2021 23:00:24 +0000

I always find myself every now and again creating a "Switch" or "Toggle" component for a client project.

After making them quite a few times I've decided to put my findings down in this post.

They can be super easy to make, and there's a few nuances that go with them. Let's begin.

Note: I've built this using the technologies I use the most: react, typescript and styled-components. But the CSS can be applied to any frontend stack :)

The whole component is built using just 4 components.



import styled from "styled-components";

const Label = styled.label``;
const Input = styled.input``;
const Switch = styled.div``;

const ToggleSwitch = () => {
  return (
    <Label>
      <span>Toggle is off</span>
      <Input />
      <Switch />
    </Label>
  );
};
```

This gives us something like this:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7dccyj0x0qnmwgwg7h5k.jpg)

Now we actually don't want to show the `<input>`. But we **do** want it to be of `type="checkbox"`.

This allows the user to be able to click on anything inside the `<label>` to trigger the `onChange` event, including our `<span>` element.

> Note: It's important here to keep the input in the DOM by setting `opacity: 0` and `position: absolute`. Why?

- `opacity: 0` will hide it from the user
- `position: absolute` takes the element out of the normal doument flow.
- This allows the user to "tab" to the label/input and use the spacebar to toggle the element.


```tsx
const Input = styled.input`
  opacity: 0;
  position: absolute;
`;

// Set type to be "checkbox"
<Input type="checkbox" />
```

I'll add a few styles to the `<label>` component, it's wrapping everything, so I want it to be `display: flex` to align the `<span>` and `<Switch />` vertically.

The `gap` gives us a straight forward 10px gap between elements, and the `cursor: pointer` gives the user visual feedback saying _"Hey! 👋 you can click me!"_.

I'll also add styling to the `<Switch />` element.

```tsx
const Label = styled.label`
  display: flex;
  align-items: center;
  gap: 10px;
  cursor: pointer;
`;

const Switch = styled.div`
  width: 60px;
  height: 32px;
  background: #b3b3b3;
  border-radius: 32px;
`
```

We now have something like this:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/86wlp27nq4aqwnukanz3.png)

Next up I'm going to create a [pseudo-element](https://developer.mozilla.org/en-US/docs/Web/CSS/Pseudo-elements) on the `<Switch />` element. This will act as our switches "lever".

```tsx
const Switch = styled.div`
  position: relative; /* <-- Add relative positioning */
  width: 60px;
  height: 32px;
  background: #b3b3b3;
  border-radius: 32px;
  padding: 4px; /* <!-- Add padding

  /* Add pseudo element */
  &:before {
    content: "";
    position: absolute;
    width: 28px;
    height: 28px;
    border-radius: 35px;
    top: 50%;
    left: 4px; /* <!-- Make up for padding
    background: white;
    transform: translate(0, -50%);
  }
`;
```

Now we have something that resembles a toggle switch:

![Toggle Switch Off](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/w7tsnh133h7gqx5025xe.jpg)

To animate the switch to be in the "on" position when it's pressed I need to move the `const Switch = styled.div` variable declaration to be **above** the `const Input = styled.input` variable. This is so we can reference the `Switch` from within `Input`.

Using the `:checked` [pseudo-class](https://developer.mozilla.org/en-US/docs/Web/CSS/Pseudo-elements) selector and the [adjacent sibling combinator](https://developer.mozilla.org/en-US/docs/Web/CSS/Adjacent_sibling_combinator), we can make our switch turn green.

```tsx
const Input = styled.input`
  display: none;

  &:checked + ${Switch} {
    background: green;
  }
`;
```

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/njqr2tvdm8g2nx5wvxw0.jpg)

Now in that same nested css structure, we can target the `:before` pseudo-element of the `Switch` element:

```tsx
const Input = styled.input`
  display: none;

  &:checked + ${Switch} {
    background: green;

    &:before {
      transform: translate(32px, -50%);
    }
  }
`;
```

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zrdw74swfzupkpusv889.jpg)

Now all we have to do animate this into action is to add `transition: 300ms` to our `Switch` and the `Switch` `:before` pseudo-element

```tsx
const Switch = styled.div`
  position: relative;
  width: 60px;
  height: 28px;
  background: #b3b3b3;
  border-radius: 32px;
  padding: 4px;
  transition: 300ms all;

  &:before {
    transition: 300ms all;
    content: "";
    position: absolute;
    width: 28px;
    height: 28px;
    border-radius: 35px;
    top: 50%;
    left: 4px;
    background: white;
    transform: translate(0, -50%);
  }
`;
```

I'll add a basic `onChange` handler and `useState` hook to allow us to store the value of the checked input and change the text depending on the value:

```tsx
const ToggleSwitch = () => {
  const [checked, setChecked] = useState(false); // store value

  const handleChange = (e: ChangeEvent<HTMLInputElement>) => setChecked(e.target.checked)

  return (
    <Label>
      <span>Toggle is {checked ? 'on' : 'off'}</span>
      <Input checked={checked} type="checkbox" onChange={handleChange} />
      <Switch />
    </Label>
  );
};
```

And now we have a super simple working switch toggle:

Here's a [CodeSandbox link](https://codesandbox.io/s/easy-toggle-tnimz?file=/src/App.tsx)

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2vb2vergstpkj70vojuf.gif)

These things can be over-engineered sometimes, and there's also plenty of ways to recreate them. 

If you wanna follow me on twitter for dev-related tweets [you can find me here](https://twitter.com/karlcodes_)

10 steps to start building your own Serverless Plugin using Typescript.

Karl Taylor — Tue, 25 Aug 2020 21:22:00 +0000

I've found building things with serverless really fun, and after skimming the surface of the documentation trying to build my own plugin, I wanted to start off my development using typescript, here's how I did it.

Step 1:

Setup your npm module to build the serverless plugin.

$ mkdir my-cool-plugin
$ cd my-cool-plugin
$ serverless create --template plugin
$ ls
index.js // <- What serverless made us.

Step 2:

Run npm init so we get ourselves a package.json.

$ npm init
# Whilst we're here, lets initialize git and add a .gitignore file and add node_modules to it.
$ git init
$ echo "node_modules" >> .gitignore

Step 3:

Add typescript as a dependency along with @types/node. We can init typescript so we get our tsconfig.json file.

$ npm i typescript --save-dev
$ npm i @types/node --save-dev
$ node_modules/typescript/bin/tsc --init

Step 4:

Add a tsc build script to our package.json.

{
  "scripts": {
    "build": "tsc ./src/index.ts"
  },
}

Good thing to note here is that scripts inside your package.json will look inside node_modules. That's why in step 3 I had to specify node_modules/typescript/bin/tsc when initialising.

Step 5:

Create our src folder with a basic index.ts file in.

$ mkdir src
$ echo "console.log('hello typescript')" >> src/index.ts

Step 6: (Totally optional)

Check it's all working!

$ npm run build
> my-cool-plugin@1.0.0 build /Users/karltaylor/code/my-cool-plugin
> tsc ./src/index.ts

You would now have an index.js inside your src folder which has been compiled from typescript to normal javascript. But the src directory isn't exactly where we want it.

Step 7:

Add a rootDir and outDir to our tsconfig.json and a watch script to our package.json to re-compile our files on save.

In our tsconfig.json:

{
  "compilerOptions": {
    "rootDir": "./src"
    "outDir": "./dist",
  }
}

And our package.json:

{
  "scripts": {
    "build": "tsc",
    "watch": "tsc -w"
  },
}

Step 8:

Let's copy the contents of the index.js file that serverless gave us when we created in step 1 into our index.ts file.

You will be inundated with plenty of errors in the console that we now need to go and fix...

Now, unfortunately, after a lot of digging, I couldn't find the specific types for building a serverless plugin. But there is a @types/serverless file. To combat all the errors, your index.ts should look something like this:

import Serverless from "serverless";

class ServerlessPlugin {
  serverless: Serverless;
  options: any;

  commands: {};
  hooks: { [key: string]: Function }

  constructor(serverless: Serverless, options: any) {
    this.serverless = serverless;
    this.options = options;

    this.commands = {
      welcome: {
        usage: "Helps you start your first Serverless plugin",
        lifecycleEvents: ["hello", "world"],
        options: {
          message: {
            usage:
              "Specify the message you want to deploy " +
              "(e.g. \"--message 'My Message'\" or \"-m 'My Message'\")",
            required: true,
            shortcut: "m",
          },
        },
      },
    };

    this.hooks = {
      "before:welcome:hello": this.beforeWelcome.bind(this),
      "welcome:hello": this.welcomeUser.bind(this),
      "welcome:world": this.displayHelloMessage.bind(this),
      "after:welcome:world": this.afterHelloWorld.bind(this),
    };
  }

  beforeWelcome() {
    this.serverless.cli.log("Hello from Serverless!");
  }

  welcomeUser() {
    this.serverless.cli.log("Your message:");
  }

  displayHelloMessage() {
    this.serverless.cli.log(`${this.options.message}`);
  }

  afterHelloWorld() {
    this.serverless.cli.log("Please come again!");
  }
}

module.exports = ServerlessPlugin;

Running yarn build in the console should successfully build your index.ts severless plugin boilerplate into dist/index.js

Step 9

Let's create a new serverless project in a new directory.

$ ~/code mkdir my-serverless-test-directory
$ ~/code cd my-serverless-test-directory
$ ~/code/my-serverless-test-directory npm init
$ ~/code/my-serverless-test-directory serverless create --template=hello-world

Let's install our npm module locally simply by referencing its absolute or relative path:

$ ~/code/my-serverless-test-directory npm i --save-dev ~/code/my-cool-plugin

Open up the serverless.yml file and add the name of your plugin to the plugins section:

# Welcome to serverless. Read the docs
# https://serverless.com/framework/docs/

# Serverless.yml is the configuration the CLI
# uses to deploy your code to your provider of choice

# The `service` block is the name of the service
service: my-serverless-test-directory

plugins:
  - my-cool-plugin # <------ Right here! 🚀

# The `provider` block defines where your service will be deployed
provider:
  name: aws
  runtime: nodejs12.x

# The `functions` block defines what code to deploy
functions:
  helloWorld:
    handler: handler.helloWorld
    # The `events` block defines how to trigger the handler.helloWorld code
    events:
      - http:
          path: hello-world
          method: get
          cors: true

Step 10

Let's run our serverless boilerplate plugin to check everything is working as it should:

$ ~/code/my-serverless-test-directory serverless welcome -m "Hello World Serverless Plugin in Typescript"
Serverless: Hello from Serverless!
Serverless: Your message:
Serverless: Hello World Serverless Plugin in Typescript
Serverless: Please come again!

And voila! Your compiled typescript serverless plugin is working!

Personally I've found there is a distinct lack of documentation for building Serverless Plugins, I am very much developing in the dark and figuring out what things do what, but it's very fun to play with.

Feel free to follow me on twitter where I tweet about more tech-related adventures.

A successful git branching model & AppCenter testing CI flow for React Native apps.

Karl Taylor — Mon, 30 Mar 2020 13:24:50 +0000

After developing React Native applications for over 2 and a half years, I found a few paint points when developing, testing and releasing apps in a way that I could fully get my head around and keep my sanity, things like provisioning profiles and staging/production API URLs would cloud my vision. But I finally found an elegant solution.

The model I'm going to explain worked well for me and my team but YMMV.

Pain point 1

In an app stack with a staging and production environment, you need to change your API endpoint when developing for TestFlight or the App Store.

For example

https://api.staging.my-app.com
https://api.production.my-app.com

Now back in the day, I would simply merge develop into master and then bump the version on master and also update the API endpoint manually. This is awful.

Solution

The solution was simple, I had a config file which included my endpoint:

// app/config/index.js
module.exports = {
  apiUrl: 'https://api.staging.myapp.com/graphql', // default to staging
  versionNumber: '1.0.0',
};

Then I created a node script that will change the apiUrl depending on which arguments I pass to it.

// changeAppConfig.js
module.exports = async (env) => {
  await findAndReplace(
    config,
    /(apiUrl: 'https:\/\/)(.+)(.myapp.com\/graphql',)/,
    `$1${env}$3`,
  )
};

Note: findAndReplace is just a function that takes a file, a regex, and a string which is the replacement using regex grouping. Here is a gist

Now I have a switch.js module which can take an argument of production. e.g. $ node switch production

// switch.js
const env = process.argv[2]
changeAppConfig(env)

I would now have a config file which is set to production:

// app/config/index.js
module.exports = {
  apiUrl: 'https://api.production.myapp.com/graphql', // changed to production
  versionNumber: '1.0.0',
};

So far so good, I can now easily switch between staging and production URLs. I can also utilize this within AppCenter by passing an appcenter-pre-build.sh script.

These run before your app is built and you can pass in environment variables in the build configuration on AppCenter. Here's an example:

#!/usr/bin/env bash

# APP_ENV would be staging or production.
yarn switch $APP_ENV

Great! So now I can have 4 different apps on AppCenter with their environment variables set and the branches configured to build on push.

iOS staging
iOS Production
Android Staging
Android Production

Using git and releasing to staging/production.

So now I can easily switch between staging and production URLs. Let's talk about how we actually release the apps using AppCenter so QA can test the staging branch and master and build and release to production.

The flow

Our git flow was an adaption from the successful Git branching model with a few small tweaks.

I still use feature branches that are then merged into develop.

After I've got a few PR's merged into the develop branch, I would then create a staging release.

Now the way I've done this is as follows:

Branch off of develop into a release branch with a version number and release candidate number. I try and keep in line with semver.

For this example, let's say it's a minor release, so we will increment the version number from 1.0.0 to 1.1.0. And it's the first release candidate to staging, so our branch will be release/1.1.0-rc.0

Now this works wonderfully. I can create a staging release candidate which will now build on AppCenter using the staging branch, which can now be reviewed by QA and features & develop branches can continue to be worked on.

If I add more features to dev, I can repeat the process and create a release/1.1.0-rc.1, release/1.1.0-rc.2 and so on.

Note: release branches should be deleted after they've been merged.

Releasing to master

Creating a release to master is similar to staging, but you simply merge the release branch into develop and into master, it is a full release, not an RC release, so we omit the -rc.x value.

Note: RC releases cannot be released to TestFlight, the value x.x.x-rc.x is not compatible.

In my next post, I'll explain how I automate version bumps, branches, and pull requests to make deploying a whole lot easier.

How do you currently deploy your React Native applications? What are your pain points and achievements?

Use test.todo() when writing Jest tests.

Karl Taylor — Tue, 03 Mar 2020 15:17:10 +0000

When I start building a new component, I can sometimes completely forget to write tests as I am going, or perhaps I've finished writing my component, and I don't fully remember what I should be writing in my test suite.

A quick solution to this if you are using Jest is to build your test suite, and replace your tests with test TODOS!



describe('NewsContent', () => {
  it('Should render a normal string', () => {}) // Passes, but it's not complete! ☹️
  it('Should render a very long string') // This will fail ☹️
})

Instead, we can do it.todo('My todo test description').



describe('NewsContent', () => {
  it.todo('Should render a normal string') // This will show up as a todo in our test suite! Woohoo! 
});

The beauty of this is that we get visual feedback in our test suite in the terminal that we have outstanding tests to finish.

Now you never have a reason to not hit that diff-coverage threshold 🤓

What is your go-to process when building new components and adding tests?

Getting started with Gitlab CI/CD: Eslint

Karl Taylor — Wed, 09 Jan 2019 21:45:50 +0000

Getting up and running with Gitlab's Continuous Integration can take less than 10 minutes (depending on what you want to do, YMMV) I'm going to show you how:

To begin with - I just want to setup a simple task that will run eslint on our code. Luckily for us, we're already half way there.

Starting from version 8.0, GitLab Continuous Integration (CI) is fully integrated into GitLab itself and is enabled by default on all projects.

If you head on over to a project within Gitlab and click on Settings and CD / CD (https://gitlab.com/{username}/{project}/settings/ci_cd) you will see a drop down for Runners. You should see two columns. Specific Runner and Shared Runners. Awesome! (You don't have to do anything).

Runners

You should have some shared runners available. Shared runners are free to use for public open source projects and limited to 2000 CI minutes per month per group for private projects.

Runners are virtual machines that run jobs specified in a .gitlab-ci.yml. This file will tell the runner what jobs to do.



# At the root of your repository, add the .gitlab-ci.yml file.
$ touch .gitlab-ci.yml

Runners use docker to pull an image and run our application in a container, so we need to tell it what image to pull, what things to install and what scripts to run.

Since I'm using node, we want to pull that image from Docker



# We're pulling and installing node into our virtual container, neat!
image: node

Now we want to add a stage. Stages tell the runner what functions to run and when. For example you might have build, test and deploy stages. Stages can have multiple Jobs.



image: node

stage:
 # I just want to lint, so I will create a "lint" stage
 - lint

# Lets name our Job eslint, because that's what it's doing.
eslint:
 # tell eslint what stage it is. (This could also be build or test for example)
 stage: lint
 # What scripts do we want to run?
 script:
    # install eslint
    - npm i eslint
    # Run eslint
    - node_modules/eslint/bin/eslint.js .

Commit the .gitlab-ci.yml and push it to gitlab!

Head on over to https://gitlab.com/{username}/{project}/-/jobs to see your job in action.

Assuming you have some eslint errors, your job will fail - Woohoo!

But I have plugins, and presets!

You can simply install these along side the npm i eslint statement.

If you have multiple, you can use a backslash \ to move it onto a new line for a multiline command



image: node

stages:
  - lint

eslint:
  stage: lint
  script:
    # Install eslint
    - |
      npm install eslint \
      eslint-config-airbnb \
      eslint-config-prettier \
      eslint-plugin-flowtype \ # Any ideas on what I might want to do next?
      eslint-plugin-import \
      eslint-plugin-jsx-a11y \
      eslint-plugin-prettier \
      eslint-plugin-react
    # Run eslint
    - node_modules/eslint/bin/eslint.js .

Now go and get rid of all your eslint errors and you're on your way to a passing pipeline!