DEV Community: Uduakabaci Udofe

How to set up TailwindCSS in Angular.

Uduakabaci Udofe — Mon, 27 Dec 2021 11:47:15 +0000

TailwindCSS is one of the most loved CSS frameworks on the block and one of the reasons many people prefer TailwindCSS to the existing solutions is because, unlike other CSS frameworks, TailwindCSS is easy to pick up and allows for great customization. You can change just about anything in Tailwind by adding some configurations to the config file. This means that you don’t need to force changes to a class with important. If you don’t like something, you can replace it.

In this tutorial, I’ll show you how to add TailwindCSS to your Angular project, but before we get into that, let’s explore a bit about tailwind CSS.

What is TailwindCSS

The TailwindCSS team defines it as “a utility-first CSS framework packed with classes like flex, pt-4, text-center, and rotate-90 that can be composed to build any design, directly in your markup”. What this means is that TailwindCSS provides us with classes that we can use to produce any design imaginable. Each class does exactly one thing and this makes it easy to see what the page will look like in the browser from the code.

Composing independent classes to produce a design means applying a lot of classes to an element and this means having a bloated HTML file, but in tailwind CSS, this can be fixed with the @apply derivative. You can read more here.

Unlike bootstrap, with tailwind CSS, you don’t need to hold on to styles you don’t need. Tailwind provides a purge feature that will remove unused style while from your production build. This means that you can shave off many megabytes of unused styles.

How to set up tailwind in angular

To add TailwindCSS to your project, you have two choices: using the CDN link or CLI.
Whereas the CDN link helps you get started with Tailwind CSS quickly, the CLI is much more complex to set up, but it allows you the kind of freedom that is not possible with the CDN link. With the CLI, you can add or override the existing configurations with ease and this makes it the preferred choice for large projects.

If CDN is what you want, simply add <link href="https://unpkg.com/tailwindcss@^2/dist/tailwind.min.css" rel="stylesheet"> to the head portion of your project’s index.html and you are set. But if you need customization, then there are two methods of adding Tailwind using the CLI.

Method 1: Angular CLI

Run ng add @ngneat/tailwind on your command line. This will ask you a bunch of questions.
When asked if you want to enable JIT mode type yes. The JIT comes with lightning-fast build time and allows us to generate arbitrary styles without writing custom CSS. with this feature, you can add our custom style like bg-[#348feb] to our template and Tailwind will generate a class for us. The CSS generated in JIT mode is the same as in production, so this means lean CSS during development and a responsive dev tool as a result. You can read more about the JIT mode here.
When asked if you want to enable dark mode select class
When asked what TailwindCSS plugins you want to enable, pick the ones you like or press enter to continue. Tailwind should now be installed in your project. After the installation, you will notice that a new tailwind.config.js file has been added to your project and both the style.css and index.html have been modified. These are just the required bit for Tailwind in your project. Go ahead and use tailwind, everything should work.

Method 2: Manual installation

Step 1 => Run npm install -D tailwindcss@latest to install tailwindCSS
Step 2 => Run npx tailwindCSS init to initialize TailwindCSS in your project.
Step 3 => Update the newly create tailwind.config.js file to this

module.exports = {
  prefix: "",
  purge: {
    enabled: true,
    content: ["./src/**/*.{html,ts}"],
  },
  darkMode: "class", // or 'media' or 'class'
  theme: {
    extend: {},
  },
  variants: {
    extend: {},
  },
  plugins: [],
}

Step 4 => Add this to the beginning of your styles.scss file
@import 'tailwindcss/base'; @import 'tailwindcss/components'; @import 'tailwindcss/utilities';
Everything should now work.

How To Build Tailwind For Production.
For angular, simply running npm run build should build angular for your project. But the size will be large. You can reduce the size of the production build by simply adding the enabled: true to the purge field of the tailwind.config.js file and Tailwind will go ahead and purge the used styles.

One thing to keep in mind when purging for production with TailwindCSS is that dynamically creating class strings in your HTML with string concatenation will break your production build. This is because TailwindCSS uses PurgeCSS internally and it doesn’t try to parse your HTML or do anything special. It simply looks for any strings in the entire file that match this regular expression /[^<>"'`\s]*[^<>"'`\s:]/g. So things like<div class="text-{{ error ? 'red' : 'green' }}-600"></div> might break because Tailwind won’t catch that.

It may still work if the class is used correctly somewhere else. What you want to do is to always include the full class no matter what like <div class=”{{error? ‘text-red-600’: ‘text-green-600’'}}”></div>. Another way to do this is to add the needed class as a comment and continue dynamically creating a class string and PurgeCSS will pick it up.

That’s it for this tutorial, thanks for reading.

How To Document Your Next Open-source Project

Uduakabaci Udofe — Thu, 16 Dec 2021 08:34:38 +0000

I find myself looking at many open-source projects in a given week because I love reading people’s code. Reading another person’s code is one of the best ways to learn new things about your favorite technology and I have not been disappointed in that area. I’ve also been prompted to question some of my logic, but occasionally, I catch myself swearing over a project’s documentation, and according to this survey performed in 2017, the numbers are pretty bad.

While some people omit documentation for their projects because they feel it’s not important, others include half-baked documentation without a demo whatsoever, leaving the reader overwhelmed. You want to provide enough information to the reader in the most detailed way possible, while still being concise. This might sound hard, but it’s worth it.

The essence of this guide is to provide you with actionable tips on how to write a well-structured, and rich in details documentation that will help people make the most of your, existing or new, pet open-source project.

Keep in mind that this guide is for people who want to fill out their pet project’s README.md file but do not know how to begin. It is not aimed at big projects, although what you will be doing won’t differ much.

How To Structure Your Project Documentation

One of the most overlooked aspects of documentation is its structure. It’s not enough to write about your project in gory details without structure because the required details, at that point, might be lost in useless information. The best way to do this is to split your documentation into separate sections and provide the details where needed.

You want to start with a “getting started guide” where you showcase your project’s power and slowly move towards the architectural design where you explain exactly how your project does what it does. Also, the API section comes in handy for projects that expose API so you want to include it.

Now, let’s go through each section and explain what they do.

Getting Started Guide

This section is where you walk users through your project by performing a task. A good way to do this is to start with a finished result and walk through how to achieve the result with a step-by-step guide. Each step should do one thing and build on top of the last step. Bonus point if you catch some errors the user might run into while setting up the project, it shows you battle-tested the project.

API Documentation

The API documentation is where you write in-depth about the APIs the project exposes. Projects with multiple components are good candidates for this. You want to go through each component and highlight what options they expect and the type of options they expect if that matters.

You can immediately follow through with the architectural design or the “In the production guide”. Keep in mind that the ultimate is goal is to not provide extraneous details. Keep everything as concise as possible.
Architectural Design
The architectural design section is where you write about how your project does what it does. Explain a design decision and why that makes sense for the projects. You can also go through the inspiration for that the said design decision, this helps familiarize the readers with your mental model of the project.

You can also go into what potential contributors should look out for in the project should they decide to contribute. The best place for this is the CONTRIBUTING.md file, but I find it very helpful to have information like this in the main documentation.

License

This is a very important part of a project’s documentation because it dictates how people will interact with the project. It’s advisable to choose the one you are comfortable with as some licenses require modified copies of your work to be also open-source. This might not be what you want.

Also, if your project uses another project, be sure to check out that project’s license because some licenses require you to use the same license as the project your project is built upon. Below is a list of some commonly used licenses.

Apache License, Version 2.0
GNU General Public License v3.0
MIT License You can find details for these licenses here.

Make sure you choose the one that fits both you (the author) and your project well.

That’s pretty much it. If you have suggestions or questions, drop a comment below.

How to achieve dark/light mode with CSS.

Uduakabaci Udofe — Wed, 08 Dec 2021 12:10:02 +0000

If you have ever written CSS for a large web app then you know how hard it is to manage CSS. Add that to the increasing need to support dark and light modes in your app and you’ll have an overwhelming app starring you in the face. It helps to have methodologies and pre-processors handy but even with these tools, CSS can easily balloon into a monster code-base that's very hard to manage if not properly structured from the get-go.

In this guide, I'll introduce you to a simple system i use to manage my CSS and how you can absorb it into your current front-end workflow. We'll start with a brief introduction to methodologies and preprocessors and why you should pick up one if you haven’t already.

Why Do We Need CSS Methodologies?

When it comes to writing CSS, I think it’s better to avoid selecting tags or even an element’s descendant because the HTML structure can change in the future. A better option is to split the HTML into independent components, style them with classes, and then compose them to achieve the desired interface, and here is where CSS methodologies come in. CSS methodologies are formal, documented systems for writing CSS in a way that allows us to develop, maintain and scale the front-end as a set of small, isolated modules.

CSS methodologies provide us with structures and mental models to manage CSS efficiently. With CSS methodologies, we can embrace the whole DRY (don’t repeat yourself) ideology easily because our CSS will be divided into isolated modules which makes styling a breeze and repetition kind of hard.

Why Do We Need CSS Preprocessors?

Whereas methodologies provide us with systems to manage our CSS, preprocessors such as SASS, LESS, and stylus provide tools to implement these in a way that is easy to understand and maintain. There are a few methodologies and preprocessors to choose from, but for this guide, I'll be using the BEM methodology because it is relatively easy to pick up and it is very intuitive. I’ll also be using SASS as my preprocessor of choice because of its mass appeal.

A Better Way To Structure CSS

The first step towards building a scalable and maintainable system is to group the primary values. Primary values are values that multiple parts of the system depend on, for example, colors, font families, and font sizes. If multiple components of the system rely on a value, it makes sense to isolate the value and store it somewhere and then reference that value from the dependent components instead of hard-coding the value into these components. So that in an event of a change, we will only update one part of our system and have the change reflected in all dependent components.

When grouping the primary values, we will store these values in CSS variables and reference these variables in our component. What we want to do is to pick out the primary colors and fonts and store them in CSS variables with explainable names. It’s easier if we have a UI to look at but if we don’t, then we’ll need to make these hard design decisions ourselves.

Some designs use different fonts for different hierarchies and different colors for different messages/text, so it makes sense to understand what we are working with. When naming our font variables, it’s best to name them in terms of their use-case instead of some generic name, the same thing with colors. We want to abandon names like --font-ubuntu, --color-red for names like --headline-font, --main-accent-color as these names explain the roles of each font and color in our system. This way, we understand what each color and font does at glance.

With everything we’ve said so far, our codebase should look more like this.

:root {
  --main-accent0: hsl(165, 100%, 50%);
   /* lighter version for hovers */
  --main-accent1: hsl(165, 100%, 90%); 
  --headline-font: Ubuntu;
}

/* then in our call to action we can do like this*/
.button {
   background-color: var(--main-accent0);
   font-family: var(--headline-font);
   &:hover {
    background-color: var(--main-accent-1);
   }
}

How To Structure CSS For Theme Switching

When it comes to themes (dark mode/light mode), there are a couple of ideas I know of: one way is to put the dark and light theme variables in their separate stylesheets and load them when the user needs them. I do not like this approach because the browser will have to fetch the themes from the server, and for servers with high latency, users with bad network speed, or even users using our app offline, our web app might not work smoothly.

My preferred approach is to have all the variables in one stylesheet, split them up into classes, and then toggle these classes depending on what mode we want to achieve. Here is what I mean.

/*main.scss*/


.theme {
  &__light {
    --high-contrast-bg: hsl(194, 2%, 93%);
    --high-contrast-text: hsl(194, 2%, 28%);
  }
  &__dark {
    --high-contrast-bg: hsl(194, 2%, 48%);
    --high-contrast-text: hsl(194, 2%, 98%);
  }
}

.card {
  padding: 20px;
  background-color: var(--high-contrast-bg);
  color: var(--high-contrast-text);
}

<!-- index.html -->
 <body class="theme theme__light">
    <div class="card">
    <div class="card__header">
      header
    </div>
    <div class="card__body">
      body
    </div>
    <button class="theme-switcher">switch to <span class="theme-switcher__current-mode">dark</span> mode</button>
  </div>
 </body>

Here is a Javascript snippet to help us achieve that.

document.addEventListener("DOMContentLoaded", () => {
  const theme = document.querySelector(".theme");
  const button = document.querySelector(".theme-switcher");
  const mode = document.querySelector(".theme-switcher__current-mode");
  button.addEventListener("click", () => {
    theme.classList.remove("theme__dark", "theme__light");
    if (mode.innerText == "dark") {
      theme.classList.add("theme__dark");
      mode.innerText = "light";
    } else {
      theme.classList.add("theme__light");
      mode.innerText = "dark";
    }
  });
});

Thank you for reading this guide, I hope you’ve learned a thing or two. If you have a question or a suggestion for this guide, please don’t hesitate to send ‘em in.