DEV Community: Paul Duvall

Setting up Tailwind in your Vue project

Paul Duvall — Sat, 06 Feb 2021 14:48:32 +0000

I suspect that Tailwind CSS needs no introduction. This 'utility-first, fully responsive CSS framework' is increasingly popular (the State of CSS survey suggests it experienced the greatest degree of growth of any CSS framework in 2020) and, since I had only used Bootstrap-Vue in my work, I thought it time to try something different. If you want to try it too and want to set up a Vue project to get started in, follow these instructions.

Instructions for setting Tailwind up in a project can be found in the Tailwind docs.

If you already have a Vue project set up and ready to use Tailwind, you can skip steps 1-2!

1. Vue CLI

In order to easily set Vue projects up from the command line, you'll need the Vue-cli (command line interface) tool installed on your computer. You can do this from the command line:

npm install -g @vue/cli

(Note that the -g adds the package globally so it can be used in all project on your computer.)

2. Create a Vue project

With the Vue CLI installed, you are now able to create Vue projects from the command line. Navigate to the folder on your computer where you wish to create your project and enter the follow:

vue create tailwind-project

I've chosen to call my project 'tailwind-project' but of course you can call yours whatever you wish. You'll need to select whether you want your project to use Vue 2 or 3. Once your project has been created, your command line will prompt you to type the following two commands:

cd tailwind-project
npm run serve

The first command will move you into the project folder (if you have named your project differently, you will need to replace 'tailwind-project' with the name of your project). The second command will start a development server, enabling you to view the newly-created project.

Once you have run this second command, you'll be given a localhost url, which you can copy to your browser and will show you the Vue project template:

3. Setting up Tailwind

Back on the command line, making sure you are now in your project folder, run the following command:

npm install tailwindcss

With Tailwind installed, open your code editor of choice. You will need to create a file in the root directory of your new project called postcss.config.js and add the following to this file:

module.exports = {
  plugins: {
    tailwindcss: {},
    autoprefixer: {},
  },
}

PostCSS is a tool that Tailwind requires in order to work (click here if you want to find out more).

You'll also need to create a file called tailwind.css in the src/assets folder in your project. Add the following to this file:

@tailwind base;
@tailwind components;
@tailwind utilities;

Essentially this is your css file and these directives allow you access to all of the css classes that come with Tailwind.

Finally, in your main.js file, you'll need to import your new tailwind.css file (on a line after the import statements for Vue and App):

import Vue from 'vue';
import App from './App.vue';
import '@/assets/css/tailwind.css';

4. PostCSS gotcha

Whilst completing this process, I hit the following error:

Syntax Error: Error: PostCSS plugin tailwindcss requires PostCSS 8.

You can skip this step if you don't hit this error, but if you do, follow the instructions on this page.

5. Test it out!

All being well, you should now be able to apply a Tailwind class to you application and see the styling adjust accordingly. In the app.vue file, remove all the standard styling that is automatically included with the Vue standard template.

That done, if you view your site in the browser, you should notice that the layout and styling changes. Back in your code editor, navigate to HelloWorld.vue, the component that is automatically included. This contains the majority of the template content. You should be able to find an <h1> tag that renders a prop passed from the App.vue (it's the main heading that reads 'Welcome to your Vue.js app').

Add the class 'text-red-500', so the line should now read:

<h1 class="text-red-500">{{ msg }}</h1>

If all is working, your text should now be red. Congratulations, you have successfully set up a Vue project with Tailwind!

#100DaysOfCode - Round 3 complete!

Paul Duvall — Fri, 19 Jul 2019 10:11:26 +0000

This article was originally posted on my blog, let-there-be-code.com, where I post articles not quite as frequently as I'd like.

The #100DaysOfCode challenge is a personal call-to-arms, an opportunity to hold yourself to account and a framework for establishing a consistent routine. By undertaking #100DaysOfCode, you set an expectation that you will spend at least an hour coding for one hundred days in short succession. I’ve just finished my third round. Here’s a rundown of what I achieved during that time.

Sass / Scss

I’d heard a lot about CSS pre-processors and decided to finally take some time to familiarise myself with these technologies. I worked through a course called Advanced CSS and Sass and learnt how to implement Sass in projects and the myriad of different ways that it can be used to enhanced CSS.

I have since integrated Sass into two multi-page projects and can honestly say I won’t be going back. In terms of creating more organized, useable CSS, the impact of using a pre-processor cannot be overstated. And I’m still discovering ways that it can enhance my coding experience (such as improving my use of media queries for responsive design).

Portfolio

One of the main objectives for this round was to create a portfolio that better demonstrated my abilities. Gone is the clunky design and the ineffective responsive design of the first iteration, now replaced with carefully thought-out visuals, a considered colour-scheme and consistent component design.

Working on my new portfolio provided me with a number of firsts: it was the first substantial project I’d designed using Adobe XD, the first time I’d used a CSS pre-processor (Sass) and the first time I’d deployed a website with a custom domain name.

My portfolio can be viewed here and I’ve written about it here.

Freelancing

During the course of these 100 days, I reached out to some local businesses to see if anyone wanted a free website. It turned out that someone did – a popular and established local café. I met with the owners to discuss the project, created a design from scratch and built the site.

It’s not live yet though hopefully it will be ready to go any day now. The domain name has been purchased and I’m looking forward to having a commercial website up and running!

Git / GitHub

Conscious of how essential getting comfortable with Git is to making oneself employable, I earmarked some time to getting to grips with version control. I took a fabulous free course called How to Use Git and GitHub.

Having improved my confidence with version control tenfold (though I still regularly find it confusing), I made a commitment to use it in some personal projects, making regular commits, using branches, making pull requests to merge those branches, and logging and resolving issues.

I wrote about using Git in personal projects here.

React

I made a start on learning React during my second round of #100daysofcode and found it to be intuitive and logical. Yet it didn’t quite sink in and I never made the step to creating my own projects.

This time round, I reviewed what I had learnt already, going further and getting to know associated tools such as Redux and React-Router. Redux was a little overwhelming so I took a step back and implemented some more basic React in a series of projects, completed as part of the freeCodeCamp curriculum. So far, I have made a random quote machine, a markdown previewer and a drum machine.

jQuery

I’d learn a little jQuery in the past but had never implemented it independently in a project that depended upon jQuery in a significant way. Whilst jQuery is often labelled as an older, redundant technology, there are still plenty of jobs that list it as a required skill, so I decided to make something to increase my confidence – a movie quote quiz.

This project can be viewed here.

Looking ahead

This time around, I haven’t jumped straight into another round of #100daysofcode. Whilst I have found the commitment and structure around the challenge immeasurably helpful, I’m also conscious that I need a period where I’m placing a little less pressure on myself.

I’m still coding and suspect I’ll be starting up round 4 before too long, but I’m taking a few more days off and cutting myself some slack. That said, I’ve got a bunch of things on the backburner (and the…err…frontburner):

*An ecommerce product page that I’ve designed and am going to create using HTML, CSS and JavaScript
*More functionality for my movie quiz to keep practicing jQuery
*Reworking a project called ‘devLearn’ built using vanilla JavaScript and Bootstrap that needs quite a bit of work
*A more complex application to continue with React (possibly a meditation or exercise app)
*A course to learn PHP

I also want to learn more about Inkscape, SVGs and HTML canvas. Ultimately, there is always more to learn and more to build and that’s what I love about web development. Looking back over the last 100 days, I’m proud of how much progress I’ve made – it really is surprising how much can be achieved by making a commitment to consistently sit down, switch on your computer and work at developing your skills.

Sass and Media Queries

Paul Duvall — Sun, 30 Jun 2019 16:25:32 +0000

Ensuring websites and applications are responsive so that they are usable and visually appealing across all devices is one of the cornerstones of modern web development. Writing media queries in CSS is the most commonly used technique for ensuring our products are responsive and using media queries in conjunction with Sass makes them all the easier to work with.

In this article, I will give a brief overview of how media queries are used to ensure sites and applications are responsive and then how they can be used with the Sass preprocessing language.

An example of these ideas in practice can be found here.

Media queries

A media queries can be applied in CSS to enable different values to be given to properties of selectors based upon the width of the viewport.

h1 {
  font-size: 26px;
}

@media only screen and (max-width: 900px) {
  h1 {
    font-size: 24px;
  }
}

The above example contains a CSS rule that sets a value of 26px for the <h1> selector. This dictates the size of the font until the screen width drops below a breakpoint of 900px, at which point the media queries kicks in and adjusts the font size to 24px.

One media query tends to be set for each breakpoint and that one query contains all the CSS rules that need to be adjusted.

This is all well and good and media queries established in this way have served me well. However, my media queries are often located quite a long way from the CSS rules they are adapting. Imagine that the h1 rule above is located near the top of the CSS document, say around line 15. If the document were several hundred lines long and the media query located at the bottom, perhaps around line 250, it would be tricky to navigate quickly between the two.

I often find myself scrolling up and down, having looked at a rule in the media query, trying to find the original code further up the document.

Sass and media queries

With Sass, it is possible to nest a media query directly within the CSS rule:

h1 {
  font-size: 26px;

  @media (max-width: 900px) {
    font-size: 24px;
  }
}

This removes the need the name the CSS rule twice, making the code more succinct. It also ensures that all the code related to this particular rule is located in the same place.

No more scrolling up and down, hunting for two (or three or four – if multiple media queries affect the h1 rule) associated blocks of code.

An issue

Writing media queries in this way presents a new problem – instead of having a media query defined in one place, there might be as many smaller media queries as there are rules within the CSS document.

This would be a problem if in the future you needed to adjust the breakpoint value from, say, 900px to 950px. It would be necessary to scroll through the entire codebase, hunting down dozens of media queries.

Mixins to the rescue!

Luckily, mixins can solve this issue by allowing us to define the media query in one location and to then apply it around the codebase wherever it is needed.

  @mixin respond-medium {
    @media (max-width: 900px) { @content }
  }

The content directive – @content – allows us to pass a block of code into the mixin. Once the mixin is set up, we can apply it:

h1 {
  font-size: 26px;

  @include respond-medium {
    font-size: 24px;
  }
}

Multiple media queries

We can go one step further to establish one mixin that handles multiple media queries, allowing us to set different breakpoints easily.

  @mixin respond($breakpoint) {
    @if($breakpoint == medium)  {
      @media (max-width: 900px) { @content }
    }
    @if($breakpoint == small)  {
      @media (max-width: 600px) { @content }
    }
  }

Here we have established a variable called $breakpoint. Depending upon what is passed in for this variable (medium or small), the correct media query is set.

With this done, we can easily apply multiple media queries:

h1 {
  font-size: 26px;
  @include respond(medium) {
     font-size: 24px;
   }
  @include respond(small) {
     font-size: 20px;
   }
}

This example would ensure that the h1 font-size, normally 26px, would be 24px in viewports less than 900px wide and 20px in viewports less than 600px wide.

Summary

Take a look at this example of media queries in Sass implemented in a real-world example. Thanks to Sass’s ability to nest items within a CSS rule, media queries can be more closely linked to the CSS rule, resulting in a codebase that is more user-friendly and understandable. This, coupled with the use of mixins (using @content and @if directives) has completely changed how I will be using media queries in the future.

Updating my portfolio

Paul Duvall — Fri, 01 Mar 2019 10:05:37 +0000

I’ve been painfully conscious for some time that the first indication of what I’m capable of as a developer I give to prospective employers is my portfolio. And my portfolio leaves a lot to be desired.

For a start, the design is clunky. I might not be a top-grade designer but my awareness of web design principles has come on leaps and bounds over the last few months. On top of the clunky design, as a demonstration of my ability to create responsive websites, it falls flat on its face.

With this in mind, I recently set out to create a brand-new portfolio, built from scratch using a couple of tools I didn’t the first time around. Read on to find out how I’ve gone about this redesign and what I hope the final product to achieve.

The design brief

The aim of my portfolio is to demonstrate the skills I have learnt in my efforts to transition into a web development-related role by creating a professionally-presented product that is both pleasing to the eye and built using well-organised, clean code.

The target audience is primarily recruiters and prospective employers. As such, the primary goals of the site should be:

• Ensuring my skills are presented concisely

• Making it clear how best to contact me

• Providing information about, and links to, projects I’ve worked on.

I’d like to also work towards being able to potentially take on freelancing work, though since this is a secondary goal for me at present, the design I have put together is not intended to engage freelance clients. To do so would require a wider-scope, however the current design could be built upon in the future to achieve this purpose.

Inspiration

Before creating my design, I spent quite some time researching other people’s portfolios. This I found surprisingly challenging. I found plenty of ambitious and unique designs through blog posts with titles like ’30 inspirational portfolio designs’, but these were invariably built around designs that were a little too ambitious to be guiding me at my current skill-level.

Yet I wanted something visually appealing and built upon solid, dependable layout patterns. A couple of portfolios inspired me:

• Tom Hirst’s site I found to be incredibly focused. Any text content is concise and the intention of the site is very clear, with great use of green as a ‘call to action’ colour.

• Sarah Evan’s site has a modern but approachable feel. In particular, I liked the individual project pages detailing the process and brief behind each project.

• Adam Marsden’s site provided some more direct inspiration – I loved the layout of his project cards and decided to use this as inspiration of my layout. I also liked the way he divided his project into two sections, with key projects gaining a greater priority on the page, with a ‘miscellaneous’ section for older or smaller projects.

• Finally, although it might not be the most flashy part of a site, I really liked Hannah King’s footer section, and used this as inspiration for mine.

Initial design

With some inspiration under my belt, I began to think about my design. Having watched Kevin Powell’s video on designing a brewery site using Adobe XD (and discovering that, unlike Adobe’s other software, XD is free), I decided to have a go at using it to put together a design for my portfolio. This was my first attempt at using design software for a project. In the past, I had drawn out a design on paper showing a rough layout of pages but I can honestly say that, having created a initial design for a site on a computer, I will never start a project again without spending time on this stage.

Adobe XD is, in my opinion, very intuitive and enjoyable to use. I spent the best part of 15 hours putting my design together, which is probably quite a long time, but I learnt a lot and, the more I used the software, the quicker I became.
I’m confident that having a well-thought-out design is saving me time now that I’m coding. There are several reasons for this – colours, sizing and responsive layout.

Colours

To begin, I did what I usually do: pick a couple of colours and mostly use those, throwing in random other colours I kind of think work in an ad-hoc way as I work my way through the project.

Whilst creating my portfolio design, I cycled through several colour schemes before settling on my final palette. I used ColorSpace to help me select complementary colours but it was Adobe XD’s colour-library feature that ensure I developed a more disciplined approach.

Wherever possible, I used the same small selection of colours, resulting in a more consistent design. I selected a bold, vibrant green as a highlight colour that stands out and draws the user’s focus.

I created a little colour board for myself, including the variable names I would use in Sass.

Sizing

Creating an initial design also encouraged me to think more carefully about the sizing and positioning of elements. I’d read a lot about the importance of whitespace and how it’s effective use is integral to modern design. Spending time creating a design in Adobe XD undoubtedly helped me develop a greater awareness of my use of whitespace, ensuring the components on my site are given room to maximise their impact and to ensure a good flow.

I also found the design process to help with thinking about giving text space to breathe with more line-spacing than I would have used in the past and a subtle increase in character spacing. Most importantly, I was able to keep all of these design considerations consistent.

Responsive layout

Adobe XD allows the user to quickly add a new ‘artboard’ to a project and, in doing so, select a width based upon different devices. Though I was aware I would most likely need to create a third mid-size layout, I decided to include two versions in my initial design: a larger-viewport version (1280 pixels) and a smaller version (360 pixels).

Creating both versions gave me a real sense of how they would relate to each other, how the different components would have to stack and change position. This process naturally led me to consider the practicalities of how this might work and my brain began to formulate ideas and make practical decisions based upon what I knew I could achieve with code. In turn, this affected how I put together the design.

Coding - setup

After my last project’s CSS files had become very messy very quickly, it was clear to me that this time around I needed a better way to organise my CSS. So I decided to use Sass, arguably the most popular CSS-preprocessor to organise my code into separate (partial) files.

I used node package manager (npm) to install node-sass in my project, creating a script to run and compile Sass automatically whenever a change was made. This I was able to do thanks largely to Jonas Schmedtmann’s Advanced CSS and Sass course.

Having also spent some time developing a deeper understanding of git and Github, I was keen to integrate these technologies into my workflow in a more professional manner. I started using issues and pull requests on Github and the command line tool Git Bash on my computer to manage branches and commits on the project. I’m ready to start working more confidently with these tools thanks in large part to Udacity’s fantastic free course How to use Git and Github.

Front page

The front page will be divided into four main sections:

• A header including my name, photo and - most importantly - links to the contact page and my CV

• An about section, which will be short and sweet

• A skills section, which will again be short and sweet as most of the information about my skills will be located on a separate page

• A projects section, also short and sweet (noticing a pattern here?), with only two recent projects featured along with a link to the dedicated projects page.

Having read Steve Krug’s Don’t Make Me Think, in which he strongly emphasizes how little time people tend to spend on average looking at any given webpage, I wanted to keep the information on the front page as focused and succinct as possible. The primary goals outlined above are achieved in this page with a minimal amount of waffle.

Next steps

My intention is to get this up and running as soon as I possibly can – out with the old portfolio and in with the new. I can then add the secondary pages as when they are ready.

Hopefully, once the CSS is written for the home page, I will be able to put the other pages together a little quicker. Some reuse components that I am designing for the home page, such as the skills card component (reused on the About me page) and the project card component (reused on the Projects page).

I’m excited about this project and am confident it will better present what I am capable of. I’ve spoken to several recruiters who have looked at my current portfolio and, whilst they are sometimes complementary about it, I know I will feel more confident in these conversations when my new site is up and running.