Forem: Macke Hansson

To Tailwind or not to Tailwind

Macke Hansson — Sat, 25 Mar 2023 10:53:21 +0000

The TL;DR is: The question to use Tailwind or not, is as easy as do you like it? Does it help and improve your work? If it is; use it, if it's not, don't use it. It really is as easy as that. Know your reasons. Me, personally, I love it. This article describes my past, writing CSS and what problem I encountered that Tailwind mostly solves for me.

I engaged in a brief discussion on Twitter earlier this week. As many times before it was regarding someone who didn't like the utility class approach that Tailwind brings to the table.

Austin

@amcdnl

Can someone explain to me how adding 20 CSS classnames is easier/better than just writing CSS? #tailwind

14:26 PM - 20 Mar 2023

I replied with these tweets and that is what I want to write about today

Macke Hansson 🏳️‍🌈

@mackehansson

@amcdnl People seem to forget the struggle that was working with css in a large team with different expereince. The ctrl + f, the inheritance, the naming of classes. It was pain.

20:12 PM - 20 Mar 2023

Macke Hansson 🏳️‍🌈

@mackehansson

@amcdnl Oh and all the unused styles. Working with components(I guess that is what we mostly do today) you write styles once and reuse the component where previous you wrote classes for reuse everywhere. :)

20:13 PM - 20 Mar 2023

I want to talk about why I personally love using Tailwind. But to do that, we have to bring it back a couple of years. Back then we had these problems:

Multiple ways to write CSS

In the beginning, it was only CSS (well not in the beginning, but you get the point). We had one way to style our websites. It sure must have been easy and nice, right? Well... The big discussion back then was where to write CSS. Some people said to write it in CSS files whereas others preferred inline CSS. Much like the Tailwind discussions today, it was very opinionated.

But time went on and preprocessor languages became the way to write CSS. Suddenly we had a much more creative way to style our websites. But now you needed to compile your files to CSS. Maybe you really liked to write Stylus and someone else on your team wanted LESS? How to solve those kinds of problems? Oh, and Sass could be written in 2 ways, *.scss and *.sass. I mostly used the *.scss format and still do today.

The code and the file structure

As I said, sass with the *.scss syntax was what I and my team mostly used. Great, we had agreed on how to write styles. Now we arrive at the next problem; Where does the code go? How do we structure the styles? How do we name the classes? Should it be an ID or a class?

This was a shit show out of this world. We had to invent naming conventions just to make styles easier to work with. BEM was my weapon of choice.

Projects often started with the variables file. You added all of those variables that "could be changed someday" in a separate file. Does anyone remember Bootstraps variable file? Impressive stuff. We had the non-functional requirement of Changeability on top of our minds. "This color could perhaps be another color one day". But let's be honest here, how many times did a change of a variable really solve your problems? Search and replace with a proper code inspection was mostly how we changed stuff.

It. Was. Hard.

Unused styles

We didn't have any tree shaking when it came to styles. At least not what I've used. It was all glued together in a styles.scss file with imports everywhere. Imported stylesheets imported other stylesheets.

We had large stylesheet files back then, and it was hard to know what class or id, was in use. So often we shipped unused classes.

Ctrl + F

Now we are up and running. We create the most beautiful websites. Everything is fine. We are adding styles to our HTML and everything is fine. But suddenly, the font weight on our heading is not bold. What happened?

You know what happened here. Inheritance. Somewhere in your codebase, you have some style that takes precedence for the font-weight attribute. But where is it? In a perfect world, you have full control over all the files and knowledge where you have previously added something that could have been the source.

But this is not a perfect world. We have multiple developers on the team with varied skill sets. The solution is to start searching the code for elements, class names, and so on.

On top of that, you have to have full control over the HTML as well. What if the class was in use in another part of the page?

Static web pages and JavaScript frameworks

There is a large shift in how, at least for me, how I work with the web today. I rarely develop big static web pages anymore. I focus mostly on Javascript frameworks.

With static web pages, like a CMS, it makes more sense to have a regular CSS class to be able to reuse all over your website. But when you're working with Javascript frameworks, you mainly work with components that can be reused.

Using Tailwind does exactly the same thing here. We write our utility classes only once (for a specific ui element) in that component and reuse that component.

Let's look at an example of what I mean.

CSS

.card {
  width: 200px;
  background: #efefef;
}

.card__image {
  box-shadow: 1px 1px 5px #000;
}

.card__content {
  padding: 16px;
}

.card__title {
  margin: 0 0 4px 0;
  padding: 0;
}

.card__description {
  font-weight: light;
  margin-bottom: 8px;
}

.card__actions {
  text-align: center;
}

.card__action-button {
  background: yellow;
  border: none;
  padding: 12px 16px;
  font-weight: bold;
  text-transform: uppercase;
}

This is a very simple ui element, a typical card. First, we write the CSS for it somewhere in a CSS file.

Then some HTML

<div class="card">
  <div class="card__image"><img src="https://picsum.photos/200/120" alt="From stockphoto" /></div>
  <div class="card__content">
    <h3 class="card__title">Car title</h3>
    <div class="card__description">
      The description for the card goes here.
    </div>
    <div class="card__actions">
      <button class="card__action-button">
        Great!
      </button>
    </div>
  </div>
</div>

When working with static HTML, the HTML part is not where you abstract and reuse, but the CSS. This exact HTML could be located in another part of the page. Both use the same CSS classes. Makes sense right?

Now enter the world of JavaScript frameworks. The same HTML, with Tailwind would look like this (inside a Card component):

<div class="w-[200px] bg-gray-100">
  <div class="shadow">
    <img src="https://picsum.photos/200/120" alt="From stockphoto" />
  </div>
  <div class="p-4">
    <h3 class="m-0 mb-1 p-0">Car title</h3>
    <div class="font-light mb-2">The description for the card goes here.</div>
    <div class="text-center">
      <button class="bg-yellow-400 text-black border-none px-4 py-3 font-bold uppercase">Great!</button>
    </div>
  </div>
</div>

This component would then be able to be reused all over the place. The styles are written once and contained with the markup. For me, this creates changeability and visibility, both to be able to "see" what the end result will look like in one place.

People who use Tailwind don't know CSS

This argument is just nonsense. I have seen it sometimes. How could you possibly create a design with Tailwind if you don't know what the utility classes even do? You have to know CSS to use Tailwind. Right? I'll even argue that reading the Tailwind documentation makes you better at CSS.

Conclusion

Readability - This is where I see the hesitant user's main complaint. Big complex design elements could have many many classes. This is the question in the first tweet. 20 class names instead of fewer (depending on CSS naming conventions, like BEM with modifiers, it could, with CSS, be like 1 to 3 classes). For me, this is not really a problem with modern code editors that makes code so easy to read. Typically I write the classes once, modify them to my needs and then I don't really care about them. I move on to the next element.

But of course, reading 1-3 classes is easier than 10+. It's not an argument. But for me, it's easily tradeable for the speed(Tailwinds JIT compiles used classes only = smaller CSS files to the user and lack of separate CSS file) and visibility of what I'm building.

But in the end, It's up to you to use what you and your team are comfortable with. If Tailwind does look like a mess and that mess will break or slow you down. Don't use it. That is your reason. But don't try to tell other people that have their own reason for using it to feel bad for using it. I'm sorry if this article makes the expression that I'm all in Tailwind, and people/teams only using CSS bad. That is not at all what I want to be said. That's your reason and that is fantastic.

You do you, and have fun while doing it.

Using tRPC with REST

Macke Hansson — Mon, 20 Mar 2023 08:11:22 +0000

Tl; Dr; I wanted to try tRPC with NextJS against REST, and it worked. If you just want the code, you can find the repo here.

A while ago I got curious and tried the T3 stack and it was amazing. The experience was just flawless. Prisma, NextJS, NextAuth, and Tailwind together, configured for me, just to start coding. After running through the documentation I had so many ideas as to what it could do for me.

But mostly I don't get to have control of the whole stack, just the front end of it. 99% of the time I get some swagger documentation of all the endpoints available for me.

So using the T3 stack seemed wrong. I could just use NextJS. To be honest, I was kind of bummed. I loved tRPC. How I could use the procedures in my UI components.

I searched and I searched for some kind of documentation on the tRPC website for my use case. But no luck. So I gave it up.

Until today. My daughter was napping and once again the idea of tRPC popped up in my head. Well, I could at least try to mock something up and see how it could work. So I typed in the command in my PowerShell and was on my way.

npm create t3-app@latest

I picked everything except Prisma. On top of that, I quickly added Mantine for some sugar.

This is the application I built. A simple "e-commerce". Well, at least it shows some products. The features and visual is not the point here.

I found a test API online that would work for this POC: Fake store API

My service layer

I never fetch stuff in my components. I typically create some services for endpoint access. In this application, it's just some functions for fetching products.



export interface Product {
    id: number;
    title: string;
    price: number;
    category: string;
    description: string;
    image: string;
    rating: Rating;
}

export interface Rating {
    rate: number;
    count: number;
}

export async function getAllProducts(params: {
    limit?: string;
    sort?: "asc" | "desc";
}): Promise<Product[]> {
    const urlParams = new URLSearchParams({
        limit: params.limit ? params.limit : "",
        sort: params.sort ? params.sort : "asc",
    }).toString();

    const response = await fetch(
        `https://fakestoreapi.com/products?${urlParams}`
    );
    const data = (await response.json()) as Product[];
    return data;
}

First, some interfaces to describe the data (from the fakestoreapi). Then a function for getting the data.

tRPC Routers

In the repo, I have 3 routers: Cart, Product, and User



export const appRouter = createTRPCRouter({
    cart: cartRouter,
    product: productRouter,
    user: usersRouter,
});

Let us look at the product router:



import { getAllProducts } from "@/services/products.service";
import { createTRPCRouter, publicProcedure } from "../trpc";
import { z } from "zod";

export const productRouter = createTRPCRouter({
    getAllProducts: publicProcedure
        .input(
            z.object({
                limit: z.string().optional(),
                sort: z.enum(["asc", "desc"]).optional(),
            })
        )
        .query(async ({ input }) => {
            const products = await getAllProducts({
                limit: input.limit,
                sort: input.sort,
            });
            return products;
        }),
});

In this router, I (for the demo) create a procedure called getAllProducts. It takes some optional input params and gets all the products from the service. This POC has no authentication involved so it's just a public procedure. In the real world, there should probably be a protected procedure.

In all of the tRPC documentation and tutorials around the internet, the query/mutation is where you are supposed to do database operations (Prisma). I don't really know if it is good practice to use it like this. I really wish this is ok because there is so much code that I don't need to write because of this.

Normally I create my own custom React-query hooks that returns data from my services. I don't have to do that with tRPC. I love it.

UI Component

This is where tRPC really does it for me. Look at this code:



const products = api.product.getAllProducts.useQuery({
    limit: "8",
    sort: "asc",
});

It is just beautiful. Not only the type safety but I didn't have to write my own custom hook for using that query.

Anti corruption layer

If this is all done on the server I can also use the procedure as an anti corruption layer. The data we return should be what the UI want, not what the endpoint returns. What happens if backend suddenly deploys a breaking change to the API and it breaks the UI?

In the query we can (Not present in this demo) map the response to a ui model with fallback.

Conclussion

I like this approach. But I dont know if there are any fallbacks. Is this the way you can use tRPC? Is it something missing? Will it scale well in a large application? I guess it's like everything else, I'll have to try it, evaulate it and refactor if so.

Please leave a comment if there is maybe another approach for this or if there is another great, well respected library instead of tRPC for this cause.

RE: Tell us about yourself

Macke Hansson — Sat, 18 Mar 2023 19:16:36 +0000

My name is Macke and I have been coding on a regular basis since 2004. My first line of code was written back in 1997/98 in a text book at school.

I got in touch with markup at first and added upon that as time went. Front-end developing was pretty natural for me. I think the main reason for going the front-end path, was because I had no one in my proximity doing only backend.

Back then, web sites was build in notepad and then "deployed" to one of all the free hosting sites. I remember using cjb.net (If i reacall correctly) a lot.

Time went, portfolio got bigger and bigger. Coding was not yet something I did for pay, only for the fun of it. I applied to community college and went there for a couple of years. There I really connected with the web. This was in 2004.

I got into wordpress. This is where I got to experience backend for the first time. It was a lot of fun.

In 2006-7 I joined a local web design company and got my first job as a developer, or developing was just a part of the job. I had many hats back then, mainly design and coding. This was my entry and I will forever be grateful for that part of my life.

Years came and went as fast as web tech. Went from:

HTML / CSS to,
PHP / Wordpress to,
jQuery / Javascript to,
Angular.js / Angular to,
Vue to,
React

And here I am today. I love coding and are happy that I get to do it for a living, providing to the family.

But I have lately felt there is something missing. Maybe not missing, but something I want to add to my legacy as a web developer. And that is to share what I know, what i get to know in the future.

My goal is to publish one story a week. I need practice.

Nice to meet you. Lets go.