
I really like styled components and CSS in JS in general, but this has quickly overtaken as my favourite way to do styling in React. It took a little while to figure out the configuration so I'm going to share that here.

[Link if you just want to see the working starter](https://github.com/ryanantonydunn/cra-postcss-tailwind)

The combination that works to make this seamless is as follows:

- [Create React App](https://create-react-app.dev/docs/getting-started/)
- [TailwindCSS](https://tailwindcss.com/)
- [postcss-nested](https://github.com/postcss/postcss-nested)
  Use SASS style nested CSS rules.
- [craco (Create-React-App-Configuration-Override)](https://www.npmjs.com/package/@craco/craco)
  Allow us to use PostCSS to compile tailwind and the other plugins with webpack without the need for ejecting.

## Getting set up

Using [Create React App](https://create-react-app.dev/docs/getting-started/) is very well documented. We'll start a new project and install our dev dependencies.

```bash
npx create-react-app cra-postcss-tailwind
cd cra-postcss-tailwind
yarn add -D @craco/craco autoprefixer postcss-nested tailwindcss
```

## Setting up the basic webpack config

To allow us to customise the Create React App webpack config we'll be using Craco.

Create a `tailwind.config.js` file in the root of the project for whatever customisations you like. This is also where we set up the production purge to get rid of unused utilities and keep file size down.

```javascript
module.exports = {
  purge: ["./src/**/*.html", "./src/**/*.jsx", "./src/**/*.js"],
  theme: {
    extend: {
      screens: {
        xs: { max: "400px" },
      },
    },
  },
};
```

And create a `craco.config.js` file to set up the postcss plugins:

```javascript
module.exports = {
  style: {
    postcss: {
      plugins: [require("tailwindcss")("./tailwind.config.js")],
    },
  },
};
```

Now let's change the scripts inside `package.json` to use `craco` instead of `react-scripts`. This is what allows us to bypass the restrictions with Create React App without ejecting.

```javascript
"scripts": {
  "start": "craco start",
  "build": "craco build",
  "test": "craco test",
},
```

Finally, let's set up the global stylesheet. Adding to the start of `src/index.css`:

```css
@tailwind base;
@tailwind components;
@tailwind utilities;
```

That's it for the basics, you should now be able to use tailwind in your markup with all the benefits of CRA with impunity. Let's run the project with `yarn start` and add a utility class to test it out:

![Setting up Tailwind CSS with Create React App](https://dev-to-uploads.s3.amazonaws.com/i/o5r76xikq8u0y1g17a7m.png)

Nice.

## Composition and modules

This setup comes with all the benefits of a normal CRA + PostCSS setup, which means we can compose classes inside CSS modules alongside regular CSS like this:

```css
/* App.css */
.App {
  width: 100vw;
  height: 100vh;
  @apply bg-green-500;
}
```

And with the inclusion of the `postcss-nested` plugin we can have SASS style nesting as well:

```javascript
// craco.config.js
require("tailwindcss")("./tailwind.config.js"),
require("postcss-nested"),
```

```css
/* App.css */
.App {
  width: 100vw;
  height: 100vh;
  @apply bg-green-500 flex items-center justify-center;

  &-inner {
    @apply bg-gray-900 text-white p-4;
  }
}
```

```jsx
// App.js
return (
  <div className="App">
    <div className="App-inner border border-white">Success!</div>
  </div>
);
```

Resulting in this:

![Setting up Tailwind CSS with Create React App and nesting](https://dev-to-uploads.s3.amazonaws.com/i/hxfwi50me7wxpqgjfv9p.png)

And that's it. This is definitely my new favourite way to do styling in React. [Go to the repo](https://github.com/ryanantonydunn/cra-postcss-tailwind)



I was recently working on a number input field and ran into the age old problem of validating the user input to ensure a valid numerical value. This is simple enough to just validate once the complete value is inputted, but not so much while the user is still typing.

We need the user to be able to input a `-` on the way to typing `-1` and to be able to type `1.` on the way to typing `1.23`, but remove any non-numerical characters smoothly. I was sure this could be accomplished with a single regex and set out to do it.

## Requirements

1. Remove any characters that are not numerals, dots or dashes
2. Remove any dashes not at the beginning of the string
3. Allow one dot, remove any additional dots

This should also result, at least in Javascript with a value that can almost always be correctly formatted with `parseFloat` without any `NaN` hijinks.

## Filtering non-numeric characters

Let's go ahead and try to format this horrible mess into a valid potential numeric value:

```javascript
const n = "-a[b1-2.cd.-e34--.5*(a67.ac&";
```

The first part of the problem is simple, filter any characters that aren't numbers, dashes or dots:

```javascript
n.replace(/[^\d.-]/g, ""); // output "-1-2..-34--.567."
```

This looks mysterious if you haven't ever broken it down into pieces before, but I'll explain it bit by bit. We tell our match filter to find every match `/g` from a whitelist group `[ ]` that is not `^` a digit `\d`, a dot `.`, or a dash `-`. We use `replace` to replace all matches with nothing.

Note: normally the dot character would need escaping (`/\./g` matches all dots) but doesn't within the group.

## Removing improper dashes

Next we need to remove any dashes that aren't at the beginning of the string. This is a little more esoteric:

```javascript
n.replace(/(?!^)-|[^\d.-]/g, ""); // output "-12..34.567."
```

Here we're using a negative lookahead `(?! )` to tell our matcher to fail if it finds the following match at the first-character position `^` and then to match all dashes `-`, ie: all dashes that are not the first character. Then we are using the or operator `|` to tell it to search for that or anything from out previous matcher - anything non digit, dot or dash. Getting closer.

## Removing additional dots

The final problem here is one that unfortunately _is_ solvable in a one-line regex, but not supported by several widely used browsers. We need to use a positive look-behind which isn't supported in Firefox, Safari, or IE11 as of the time of writing. Nevertheless here is the solution which will work in any environment that does support it, courtesy of a colleague of mine:

```javascript
n.replace(/(?<=\..*)\.|(?!^)-|[^\d\.-]/g, ""); // output "-12.34567"
```

Here we use a positive lookbehind `(?<= )` to tell our matcher to succeed only if it finds at least one dot `\..*` behind it. We combine it with the or operator `|` to the rest of our filters and get the final result.

Unfortunately this won't work in several major browsers, so for now I have a short function to handle it:

```javascript
const formatNumber = (n: string) => {
  // replace all non numeric, dots or dashes that aren't the first char
  const filtered = n.replace(/(?!^)-|[^\d.-]/g, "");

  // remove all but the first dot
  const [first, ...others] = filtered.split(".");
  const newValue = others.length
    ? [first, others.join("")].join(".")
    : filtered;

  return newValue;
};
```

## Final validation

The above function is perfect for validating a changing user input, but when it comes to validating the final value and converting it to a float, we need to do a small final check.

Running this filter over any string results almost always in a value that can be parsed correctly with `parseFloat`. The exceptions are resulting strings containing only `-`, `.` or `-.` which we can simply filter out and replace with zero. Or do a simple `NaN` check:

```javascript
const getNumeric = (str: string) => {
  const n = parseFloat(filterNumericInput(str));
  return isNaN(n) ? 0 : n;
};
```



Recently I had quite a productive conversation about default font sizes in browsers in a PR comment section. I thought I would preserve the outcome here for later reference.

## The Problem

Most web browsers have a setting to customise what the default font size is. This can be used by visually impaired users to increase readability and comfort.

![Chrome default font settings](../static/blog-images/chrome-default-font-settings.webp)
_Chrome default font settings_

This can present challenges to developers with having the layout support a wide variety of text sizes while still being usable and presentable. This gets more challenging the more complex the website or web-app is. A lot of developers opt to set the font size explicitly, effectively disabling this feature. Including Google and Facebook.

![Google body tag font settings](../static/blog-images/google-body-tag-font-settings.webp)
_Google body tag font settings_

Opinions on best practices here vary. Some say it’s better to have the browser zoom feature handle all font increases, preserving the layout. Some that the feature allows people to choose the method that most suits them. Even the accessibility specifications are quite vague on this.

## The Conversation

We had a back-and-forth over this over several days. The following is roughly how the conversation went.

**Dev 1:**
Font size missing from body. Not all browsers have a 16px default size.

**Dev 2:**
Allowing the default is better for accessibility because some users use a higher default font size.

**Dev 1:**
Users use a custom stylesheet now to set the default because sites like Google and Facebook all use a base pixel font. Not setting it will break the layout in some browsers.

**Dev 2:**
Some big sites do but others do not. Just because others don’t support default sizes doesn’t mean we shouldn’t either. Mobile browsers aren't displaying them incorrectly, we’re just not building our layout flexibly enough to accommodate varying text size.
[Reference](https://www.w3.org/WAI/older-users/developing/#p)

**Dev 1:**
Agreed, but checking the spec here it looks like the zoom feature would be enough to meet their criteria.
G142: Using a technology that has commonly-available user agents that support zoom
Is there something more specific to do with default font sizes we can see?

**Dev 2:**
It might be enough to simply meet the minimum standards but I think we should aim to support this feature. By explicitly setting a pixel font size we are choosing to disable it.

[Survey conducted in 2018 with 248 respondents with impaired vision on how they use assistive technology](https://webaim.org/projects/lowvisionsurvey2/)

| Response                                                               | # of Respondents | % of Respondents |
| ---------------------------------------------------------------------- | ---------------- | ---------------- |
| Screen reader                                                          | 112              | 45.2%            |
| Screen magnification software or system settings                       | 120              | 48.4%            |
| Browser zoom controls (zooms all page content)                         | 109              | 44.0%            |
| Browser text sizing settings                                           | 91               | 36.7%            |
| High contrast mode or settings                                         | 76               | 30.6%            |
| Browser settings to change colors                                      | 34               | 13.7%            |
| Custom styles (for example with Stylish, Stylus, or user style sheets) | 31               | 12.5%            |
| Tools that highlight text as it is read                                | 25               | 10.1%            |
| Other                                                                  | 21               | 8.5%             |

I agree that on the surface it looks like zoom would be enough to meet the requirements, but the fact is that people use this feature. For whatever reason makes them comfortable with their particular disability they use it. I think we should support it for the small effort it takes to adjust our layout.

**Dev 1:**
Cool. So we need to mitigate the problems that arise due to this. _list of observed issues, eg: buttons overflowing, scrollbars appearing on some elements, images unpredictably moving around_

Also since not all the text has been done with rems and it's currently a mix of px and rems, some text is tiny while other text is huge. Based on this, do you think we should temporarily add the font-size in until we can attend to these?

**Dev 2:**
Good point. Let’s put in a temporary base font size for now and we’ll make a ticket to revisit this across the app further down the roadmap.

## Lessons

This was a very useful conversation. By approaching the problem with an open mind and looking into the evidence we came to some conclusions on both an ideal best practice and a pragmatic approach to getting there.

### Things to remember

- Users may feel more comfortable using our products in ways we don’t expect.
- Just because someone else is doing it doesn’t mean it’s the correct approach, no matter how big they are.
- Sometimes the best approach has to be compromised for practical reasons like budget and timescale.
- Sometimes we need a temporary solution that can be improved further down the roadmap.
- Friendly pushback makes you justify what you think you know and really check why you think the way you do.
- Always be open to having your mind changed by new information.



Today I finally decided to set up some aliases to make my life easier in the terminal, however I was not so sure what would be most useful for me. There are a lot of resources out there with collections of aliases, but everyone's workflow is different - plus there are commands that I use just for the project I'm currently working on.

The shell I use is zshell, which has a stored history of all the commands I have ever typed in the `.zsh_history` file, there is a similar file for other shells. I decided to take a little dive into this history to see which commands I was using the most, then make some aliases based on that.

## The history file

Opening the history file from here `code ~/.zsh_history`, the file looks something like this with thousands of lines for me:

```
: 1580312682:0;docker-compose up -d
: 1574942146:0;git rebase -i HEAD~2
: 1575637243:0;git push -u origin hotfix/edge_bugs
: 1575637313:0;git checkout master
: 1575637328:0;git checkout -b hotfix/autocomplete
: 1581072502:0;cd ../
: 1581072502:0;ls
: 1575637359:0;git cherry-pick 3538df76a00a16aa04190d075
...
```

## Some very basic analysis

I decided to try to take all of those commands and count how many times I had used each one, then sort them by most used - just to get a basic look at what I was typing the most.

I made a quick nodejs script to do this. First reading the file, splitting each line into an array and removing the timestamp from the beginning. Then finally rewriting the file back into a text file in the same directory.

```javascript
const path = require("path");
const fs = require("fs");

const historyFile = path.join(process.env["HOME"], ".zsh_history");

fs.readFile(historyFile, "utf8", (err, buffer) => {
  const commands = buffer.split("\n").map((line) => line.substring(15));

  const output = commands.join("\n");
  fs.writeFile("result.txt", output, () => {
    console.log("Success");
  });
});
```

From the directory, running `node analyse.js` this outputs a list of commands with no timestamps on them in a new text file in the same directory. Great.

Next I needed to group and count all the commands, with some slight refactoring of the code:

```javascript
// count all instances of each command
const counts = {};
buffer.split("\n").forEach((line) => {
  const command = line.substring(15);
  counts[command] = counts[command] || 0;
  counts[command]++;
});

// convert into a sorted list of commands
const output = Object.entries(counts)
  .sort(([, countA], [, countB]) => countB - countA)
  .map(([command, count]) => `${count} | ${command}`)
  .join("\n");
```

This outputs the sorted list, which looks something like this:

```
118 | cd ../
114 | code .
114 | git push
93 | git pull
92 | yarn middleware
80 | yarn
79 | git add .
67 | yarn start --reset-cache
66 | docker-compose exec php-fpm bash
...
1 | git merge develop_SIT-608
1 | git merge develop_SIT-611
1 | git merge develop_SIT-615
```

The top of the list contains the most obvious commands I type all the time, but towards the bottom there are the things I use a lot but aren't unique (eg: `git merge`, `git checkout`, etc). This could be made more accurate by adding a fuzzy search but I thought it was fun just to scan over the list and get a general idea.

## Creating the aliases

To add an alias you need to edit the config file for your shell. For zshell that's the `.zshrc` file, for bash it's the `.bashrc` file. From looking at my command usage I decided on just a few that were going to make my life easier:

```shell
# Misc helpers
alias pr="cd ~/projects"
alias yarnclean="rm -rf node_modules && yarn"

#[company] helpers
alias rdw="cd ~/projects/[company]-web"
alias rdc="cd ~/projects/[company]-cms"
alias sda="cd ~/projects/[company]-app"
alias ym="yarn middleware"
alias cp="docker-compose exec php-fpm clean-pimcore"

# Git helpers
alias gclean="git remote prune origin && git branch -vv | grep ': gone]' | awk '{print $1}' | xargs git branch -d"
alias gps="git push"
alias gpsu="gps -u origin HEAD"

alias gpl="git pull"
alias gplo="git pull origin" #branch-name
alias gplod="gplo develop"

alias gc="git checkout"
alias gb="gc -b"
alias gcd="gc develop"
```

What's best for me isn't necessarily best for everyone else. For example, I like to do my commits from the vscode git diff screen because it's more obvious to me what's happening in my commits from there. As such I don't really need any `git add` or `git commit` aliases to speed up my workflow, but somebody else would. This applies to all kinds of ways your workflow is personal to you.

Having used just these few for a day or so now I can really feel the difference.


Front End Developer & Designer

Featured Projects

Latest Articles

How to use Tailwind with Create React App and PostCSS with no hassle

Formatting numerically usinf regex

Should we set a default font-size? Ideals and practicalities