DEV Community: Wimadev

Hosting old Node Projects 👴🏼

Lukas Mauser — Thu, 25 Apr 2024 15:54:09 +0000

A while ago, a friend of mine asked me to help him extend an old NodeJS project. But when we finished with all the changes, we could not deploy it anymore! The Node version was simply too old.

Google App Engine (GAE), where it was hosted before, refused to take care of our oldtimer. Yeah, they had a point. Hosting old stuff is generally not recommended for security reasons. And as a company, you don't want to maintain 20 different Node versions forever.

So we were left with the choice:

Spend a day, trying to upgrade Node and all dependencies, or find a different way to host our project.

It's the age old question:

To upgrade or not to upgrade?

Upgrading or not upgrading is essentially risk management. It's about estimating:

How big is the impact of a security breach?
How likely is it to happen?
How confident are you in your estimate?

I will make a wild guess here: If you really plan to host a 5 years old Node project, it's either so much enterprise that none of us programmers can fully comprehend the logic behind that decision, or it's a tiny project.

Our project is not mission critical. It does not store any personalized data and if it's down for a day, probably 2 people will notice.

We did not upgrade.

So, finding a different hosting solution it is!

Docker to the rescue 🐳

Luckily there is a neat little tool called Docker. It opens the doors to hosting pretty much anything you wish. Be it a frontend, backend, database or 5 year old NodeJs application.

For those of you, who are not already familiar with Docker, here is my two sentence intro:

Docker creates a container around your code, that houses all the dependencies necessary to run it. You define all of what you need in a Dockerfile, that can look something like this:

FROM node:12.3.1-alpine AS builder

WORKDIR /my-app

COPY package.json package-lock.json ./

RUN npm ci

COPY . .

RUN npm run build

FROM node:12.3.1-alpine AS runner

WORKDIR /my-app

COPY --from=builder /my-app/.output ./.output

EXPOSE 9000

CMD ["node", "./.output/server/index.mjs"]

This Dockerfile contains instructions to build a Docker image with Node 12 installed, then copy our code into it, build it and run it. I won't go into all of the details in this post, but I do recommend you check out some other tutorials on Docker if you have not heard about it before.

And now instead of having to ask yourself: "Which provider still accepts Node 12?"

You ask: "Where can I host my container?"

Hosting Options

1. Self Hosting

If you know a thing or two about self hosting, you are probably able to fairly quickly spin up a VPS and throw your container on there.

But if you know a thing or two about self hosting, you also know, that taking care of the server can cause a lot of headaches and even if you manage to spin it up quickly, there is a bunch of overhead in solving secrets management, deploys, security updates etc.

If you want to dig into it anyways, Dokku is an interesting mention. They provide an Open Source PaaS that you can install on your server to simplify self hosting containers.

For our project though, we don't want to deal with server management, we just need a solution for hosting our old little Node project.

2. Major Cloud Providers

Amazon, Google and Microsoft offer a multitude of products (ECS, Cloud Run, Azure Container Instances, ...) in the container hosting space. They equip you with the tools to withstand an army of millions of users, firing requests at your container from all over the globe.

Great! No more worries about scaling! 🥳

But wait, we didn't worry about scaling in the first place. These solutions are highly capable but also highly complex. In the time we'd spend figuring out which product is the right one for our needs, we could have done a complete rewrite of our app.

And if we ever have to deal with an army of millions of users, it's probably time to upgrade...

We need a simple solution.

3. Simple Container Hosting

There are a bunch of other cloud services, that try to make simplicity a priority. These include Digital Ocean, Render or Railway for example. While they generally offer a great service, their entry plans often come with significant restrictions.

A fair compromise, but we were not fully happy with it.
If you read the book: "The third door", you know that there is often times an option, that is not obvious at first...

What Hoster did we choose?

We went for option Nr. 4 and instead of upgrading our app in a day, we fell into the rabbit hole and spent over a year of building a container hosting platform ourselves. 🤠

With a strong focus on simplicity, Sliplane enables you to deploy unlimited containers at a fixed rate for the fraction of the price of other popular hosting options. If you want to give it a shot, you can try it for free.

Recap

Only host old stuff, that can't create serious damage
Use Docker to containerize your app
Choose from: self hosting, major cloud providers or simple container hosting solutions

Or try Sliplane, which I co-founded.

Is Nuxt 3 Really Production Ready?

Lukas Mauser — Thu, 23 Nov 2023 13:48:59 +0000

Nuxt.js is a popular JavaScript frontend framework. But people still ask, if it is production ready. I've been using the framework for the past 5 years in a wide range of different projects, from small hobby websites to big enterprise applications. Here are some of my thoughts on using Nuxt in production and what to be aware of if you decide to do so.

Is it production ready?

Absolutely!

Nuxt is already used in large web applications in all kinds of different companies across the globe. Just take a look at their show case on https://nuxt.com/showcase . Does OpenAI sound like a familiar name to you? It's homepage was build with Nuxt (last checked Nov, 2023) and probably handles hundreds of millions of requests per month.

Compared to other popular frontend frameworks it is less popular though and they do have fewer collaborators:

Framework	Github Stars	Used By	Collaborators	npm downloads
Angular	92.1k	3.1m	1.812	3.3m
Svelte	78.9k	-	648	1.6m
Vue	206k	-	362	4.3m
Nuxt	48.6k	285k	594	611k
React	216k	18.5m	1.641	22.6m
Next	115k	2m	2.995	5.2m

Table: Stats from npm and Github accessed 23.11.2023

There is no big company behind Nuxt, like it is the case with Google and Angular, Facebook and React or Vercel and Next.

Nuxt has some decent backers though and at the end of the day what matters is, that they address issues and vulnerabilities quickly and that seems to be the case. New versions get released around every other week.

What does Nuxt do well?

Nuxt has a strong focus on developer experience. They enable you to move pretty fast and once you get familiar with some core concepts you can focus the bulk of your time on your code logic.

Their pre selected tech stack comes with some pretty neat features out of the box, that enable you to create fast, SEO optimized and beautiful applications.

Features include:

TypeScript support out of the box
SEO Meta tags
Server Side rendering
Data fetching with deduplication and caching
File based routing
Component and page transitions
State management
Fast build tooling with Vite
Server functions
and many more...

Large code bases are absolutely possible with Nuxt and the frameworks seems to hold up against big amounts of traffic quite well.

What are the downsides?

Nuxt has a very opinionated approach. It can take some time to get familiar with everything and adopt the way they want you to organize your code.

There is lot's of "magic" happening under the hood, which sometimes makes debugging quite hard, especially if you are new to the framework. You will stumble into situations and ask yourself, why is that happening/ not working??

On top, while this "magic" can accelerate things, I've found that it mostly covers simple use cases. Once you get outside a simple use case you need to put some thinking effort into fitting your problem into Nuxt concepts without using antipatterns.

Nuxt has a big eco system of tools around it. However, most of these Nuxt modules feel like half baked solutions at the current time. It seems like Nuxt just released too many things at once and can not keep up with it all. When it comes to third party libraries, I'd rather use native JavaScript or Vue libraries instead, that can usually also work with Nuxt with minimal effort.

Summary

Can you use Nuxt in production? Absolutely. It has already been used by some large companies for years and has an active community around it.

Nuxt enables you to move pretty fast, once you are familiar with some core concepts of how Nuxt works. It comes with some neat features that help you to build fast, SEO optimized and beautiful web applications.

The framework is very opinionated though and comes with a learning curve to it. There are a lot of hidden functionalities that can interfere with your code and can be hard to debug. On top, big parts of the ecosystem around Nuxt do not seem to be mature enough yet, to be used in serious production applications but you can always opt for the underlying native JavaScript or Vue library.

What are your thoughts?

You Probably Know This Bug, but why does it Always Slip Through?

Lukas Mauser — Tue, 14 Nov 2023 13:53:30 +0000

TypeScript does not catch this in strict mode

Does this error look familiar?

Trying to access undefined objects is one of the most frequent errors in JavaScript.

Even if you use TypeScript you are not guaranteed to avoid this Bug.

And I'm not talking about sloppy TypeScipt usage here, like throwing in any, using @ts-ignore or type assertions with as string...

I'm talking about using TypeScript without exceptions in strict mode.

The way it's supposed to be used. And this bug will still slip through.

Why is that?

And what can you do to make your code more robust?

Why does TypeScript miss this?

Let's start with some simple examples:

// 1. Arrays

const array: { id:string }[] = []
//...
console.log(array[0].id) // this throws an error but won't be caught by TS


// 2. Objects

const object: Record<string, string> = {}
//...
console.log(object['randomKey'].length) // this throws an error but won't be caught by TS

In both scenarios an error will be thrown but most TypeScript setups would not have seen it coming.

This is because TypeScript can not reliably track every index in all code paths between the initialization and property access of your array or object and therefore simply doesn't do it.

There are options to deal with this, but each of them has some downsides.

What can you do?

Testing

While you could potentially catch this bug in a test, you can not solely rely on it.

It is one of these cases, where 100% coverage doesn't tell you anything.

An array that is defined at index 0, might be undefined at index 1. You'd have to test all possible indices which is literally impossible.

So relying on tests means, that you either have already identified the critical step in your code beforehand or you accidentally stumble upon it in the context of a different test.

Maps

Use maps instead of objects or arrays. Maps can be used similar to objects or arrays, but type safe.

// instead of this:
const object: Record<string, string> = {}
console.log(object['randomKey'].length) // throws error

// do this:
const map = new Map<string, string>()
const str = map.get('randomKey') // returns string | undefined
console.log(str.length) // TS catches this, because str could be undefined

However, one big downsides of using a map, is that it needs to be converted to an object before it can be serialized to JSON and vise versa.

This can slow down your application when dealing with big datasets and introduce an additional layer of complexity.

Another reason against maps is that arrays and objects are just simpler to use and less verbose.

Go Beyond Strict

There is a TypeScript compiler option called noUncheckedIndexedAccess introduced in version 4.2.

// tsconfig.json
{
  // ...
  "compilerOptions": {
    // ...
    "noUncheckedIndexedAccess":true
  }
}

This option will warn you, whenever you access a property via an index.

const array: { id:string }[] = []
//...
console.log(array[0].id) // TS will warn you: 'array[0]' is possibly 'undefined'.

Solved?

Partially.

Like mentioned before, the TypeScript compiler has it's limits... And adding noUncheckedIndexedAccess leads to a lot of false positives:

const array : {id: string}[] = [ { id: 'id1' }]
console.log(array[0].id) // this throws a TS error, even though array[0] is defined

// this won't work either
if(array.length > 0) console.log(array[0].id) // throw TS error

// also C-style loops won't work anymore
for (let i = 0; i < array.length; i++) {
    console.log(array[i].id); // throws TS error
}

It's personal preference if you want to double check every indexed access, even though sometimes you are already sure that it is defined. That's why this option is disabled in strict mode.

The Solution? A Combination

The "can not read property of undefined" bug is a real thing that is missed all the time. The problem is, that this bug is hard to detect and even tests won't save you here.

To make your code more robust, you can use a combination of the tools listed above.

Use tests anyways and maybe catch something in the net that you did not expect.

Consider maps where they make sense in your codebase.

And use TypeScripts noUncheckedIndexedAccess compiler option as an additional safety net.

If you don't like the unnecessary verbose syntax that comes with it, you can still toggle this option every now and then during development, just to identify potential vulnerabilities in your code.

Are Unit Tests Really Just Garbage? 💩😳

Lukas Mauser — Wed, 01 Nov 2023 16:19:53 +0000

I always assumed that unit tests are just part of the job. They are just there, and it's a no-brainer to always test every new piece of code that you add to the codebase.

Until I recently stumbled upon a guy who leads an engineering team with a radically different approach. They refused to write even a single automated test for their entire production application.

You might say, "Well, this guy is just fooling around with his 10 users."

But when I dug a little deeper into the discussion, I found that there are teams at Facebook, Twitch, and Netflix that followed a similar strategy.

So what's that all about? Should we all just stop unit testing from now on?

✅ Supposed Benefits of Unit Tests

You can probably find more, but these benefits are mentioned over and over again:

Unit tests help you to:

find bugs early on before you commit them to production,
catch bugs when your code changes,
improve your code design,
document how your system works.

If we assume you are not writing garbage unit tests, these benefits are all reasonable. But they come at a cost.

💰 The Cost of Unit Testing

Unit tests are expensive to set up and maintain.

The question is not whether unit tests are beneficial but rather if these benefits are worth it.

Developers constantly need to think about how to design their tests in a meaningful way, how to mock stuff, how to get more code coverage, and whether they covered all potential edge cases.

On top of that, when parts of the code change, they might have to refactor dozens of tests, no matter how well they were designed in the first place.

And all of this can lead to engineers becoming very shy to touch existing code that has been cemented in place by excessive unit testing. They tend to avoid rethinking existing solutions, trying out new things, and being bold in general.

🦧 What can you do instead?

1. Use a strong toolset
You can catch a lot of stuff in advance with a strong toolset. Code reviews, linters, strict type checking, and some solid coding guidelines provide a good basis to produce a robust product.

2. Manual testing
If you do need to test something, test it manually by hand. Yes, you will repeat yourself, but you are probably closer to the production environment and can easily test scenarios that might not even be testable automatically.

3. Rely on users to find bugs instead of engineers guessing them
It's likely you are already addressing the obvious stuff. But most of the bugs you'll face come from edge cases that you couldn't have guessed in your wildest dreams. If you accept that code will inevitably break in production, your focus will shift more towards how to fix it fast.

4. Add safety nets
Speaking of fast fixes. Focus your effort on creating safety nets to detect and address bugs as quickly as possible. These include gradual rollouts of new features, using good bug and performance monitoring tools, and feature flags to quickly roll back in case anything fails.

5. Write stuff down
If you run into weird edge cases, leave a quick comment in the code to explain why stuff is in there and discuss it with your teammates. That way, you can remember everything when trying to refactor pieces of your code.

6. Code is written to be rewritten
Establish that in your team. You will never get your code right on the first try. Encourage frequent improvement and don't let anyone shy away from touching someone else's code.

7. Work on your code, not on the supporting structures
If your code is fragile and keeps breaking when you add or modify parts of it, focus your energy on making it more robust instead of making the tests around it more complex.

🤔 So, should you ditch your tests?

There are cases where the cost of a single failure is simply unacceptable. Take banking, for example, or critical infrastructure. These systems need to deliver 100% of the time, and it's just not worth messing with that.

Also, at a certain scale of a company, unit tests will for sure be worth it. When there are too many people involved and things keep constantly breaking.

But this point comes later than you probably think. Netflix apparently went to 100M users without a robust testing suite in place (Ex Netflix engineer on unit testing).

So if you are a startup or medium-sized company and your priority is moving fast, then you can probably get away without unit testing for longer than you think. And going even further, it might even benefit your company because you can focus on setting up processes to fix bugs faster.

What do you think about unit testing?

EDIT:
Going without automated tests is not an excuse to go wild and crazy with your code. It's like driving a sports car in race mode to make progress fast, but you better know what you are doing. It requires you to be always alert and you need to feel comfortable with running into some road bumps along the way.

Side notes:

If you want to dive deeper, check out this interesting discussion on the topic:
https://www.youtube.com/watch?v=pvBHyip4peo

📈 Scaling Web Applications to a Billion Users. It is Complicated... 😵‍💫

Lukas Mauser — Mon, 30 Oct 2023 09:22:19 +0000

Did you ever think:

"Instagram is just a photo sharing website, I could build something like that!"

You can't.

You can probably build a photo sharing website, but the tricky part is scaling it to a billion users.

But why is that so complicated?

Let me explain...

Increasing Demands on Performance and Reliability

Running a small project is easy. Your code doesn't have to be perfect and it doesn't really matter to you if a request takes 200 ms or 500 ms. You probably would not even notice a difference.

But what if 10 people want to access your service at the same time? Let's assume all requests get handled one after the other. Waiting 10 x 200ms = 2 seconds vs 10 x 500ms = 5 seconds does make a noticeable difference. And that's only 10 people.

Now think of 100 people, 1,000 or 100,000 people that are constantly bombarding your servers with requests. Performance improvements of just a few milliseconds make a huge difference at scale.

And same goes for security and reliability. How many people will notice, if your tiny site is down for an hour? On a large site, there could be hundreds of thousands of people who will get upset, who can not finish their checkout process, who maybe rely on that service so much, that it freezes their entire business.

That's why large enterprises have uptime goals of 99.995%. That's a maximum downtime of 30 minutes throughout the whole year!

And that's when it get's complicated...

Scaling Infrastructure

When your hobby project has reached unbearable response times, usually the easiest thing to do is to migrate everything to a bigger server. This process is called scaling vertically or in other words: "throwing money at the problem".

But there is only so much traffic that single machine can handle. So at some point you'll have to add more servers, that run your application in parallel. This is called scaling horizontally.

And now it already get's complicated. Do you run multiple small machines, or a few big ones? Or a mixture of small and big machines (diagonal scaling)? How do you distribute incoming traffic on the cluster? How do you deal with certain traffic spikes?

If you can not confidently answer these questions, it's time to bring in a dev ops specialist. But it does not end here. Remember maximum downtime of 30 minutes per year? You don't reach that, if you do not plan for failures.

You need redundancy in your system, meaning, if one node fails, another one is ready to take over. Or go even further: distribute your computing resources across multiple regions and service providers to also minimize platform risk.

And it get's even more complex when you think about scaling your infrastructure globally. How do you ensure low latency for users in Brazil? What about Australia, Europe, Asia, ...? You get the point. Infrastructure of big global applications is complicated.

But infrastructure is not the only bottleneck when scaling your app.

Scaling the Codebase

In the last chapter I talked about running your app on multiple machines to handle big amounts of traffic. But is it even possible to run your code in parallel or do you use a database that needs to stay consistent across all machines? How do you split your application logic? What part of your code runs on what machine?

Scaling your application also means scaling your codebase.
And this includes:

distributing application logic,
introducing advanced monitoring tools,
optimizing code for security, performance and reliability,
improving performance through additional layers like CDNs or caching,
introducing quality control processes,
...

And all of that usually means, every tiny little thing, that was so easy to do in your hobby project, is now exponentially more complex.

Take logging for example:

In your photo sharing hobby project, you look at the log file on the server. How do you do that in a cluster of hundreds of servers? And how do you keep an overview on millions of logs a day?

And again, remember 30 minutes maximum downtime? How often do you accidentally push broken code that crashes your whole application? You do not want this to happen in a serious production environment. That's why scaling your codebase also means setting up processes to ensure no one accidentally breaks something.

The same bugfix, that is done within 15 minutes in a hobby project, can take several days if not weeks in a large scale application.

From reproducing the bug, prioritizing it, discussing solutions, coding the fix, writing tests, writing documentation, reviewing the code, reviewing security issues, verifying it works for the customer, load testing, iterating back and forward through the test pipeline to finally releasing it.

But wait, there is more...

Scaling an application doesn't end with scaling the core product. In a bigger context it also means scaling a company. Scaling the team, or multiple teams, multiple divisions, comply with legal requirements in different countries and so on.

You get the point. So next time you think about Instagram as an easy weekend project, also think about the underlying iceberg below the waterline.

But anyways, none of that should scare you from starting something. You won't reach that scale over night. Don't loose yourself in hypothetical scaling scenarios, instead go step by step as you need to.

Interesting read:
Instagrams grew to 14M users with only 3 engineers in the beginning, one of the engineers describes their early architecture: https://instagram-engineering.com/what-powers-instagram-hundreds-of-instances-dozens-of-technologies-adf2e22da2ad

7 Powerful Principles to Tackle Complex Coding Problems 😤

Lukas Mauser — Wed, 25 Oct 2023 13:59:17 +0000

Recently I was given the task to fix a bug in a very complex component with some mind bending recursiveness going on. It took me days to wrap my head around everything but I eventually got through it.

These 7 powerful principles helped me to tackle the problem:

1. Think first, then code
My first tip is to step back and think about the problem first. Maybe draw a little sketch, create a diagram, write down your thoughts or talk to somebody else about it if you can.

Separate the coding environment from your thinking environment, meaning, close your editor and work on a piece of paper, whiteboard, or inside a diagram tool.

Only when you fully understood the problem and have a clear strategy to work on it, it's time to dive into the code.

2. Break down the problem
Complexity is really just a bunch of simple problems chained together. Try to break down your task into smaller chunks that are more manageable.

This is the hard part, because it requires some training to understand how bigger problems are made up. Only thing that really helps here is to have seen a lot of simpler problems before and try to recognize patterns.

3. Fix your data first
Lot's of problems arise because the underlying data is structured in a way that causes unnecessary problems along the way. Of course it's not always possible to change the underlying dataset, but maybe you can normalize it to avoid running into edge cases.

Sometimes filling optional parameters with empty values is all that it takes to reduce upcoming headaches. Or you just have to add a single additional parameter to simplify the codebase.

So if it is a possibility in your project, take the time to think outside the function that you work on, and also try to consider tweaking your data to avoid edge cases.

4. Start with a MVS
Your MVS is the MVP for your problem. A "minimum viable solution". I just came up with that term, so don't start googling now.

Your MVS should just demonstrate that your fix or feature works. Think of it like a mini version of an MVP. Intentionally skip edge cases and only focus on the meat of the problem.

For example, in the coding problem that I faced, the recursive functions called a chain of 10 other functions. To begin with, I started commenting out all of that and only focused on the core functionality. From there I slowly added more logic as I proceeded.

5. Ignore everything you know about clean code

Ditch everything that you learned about how to write clean code. Move fast and break things. Did you repeat some logic along the way three times? Good. Is your function starting to approach 300 lines? It's fine!

You can clean up all of that later. Focus on the essence of the problem. The 80% that matter instead of procrastinating by thinking about how to group your functions in a logical way or debating about how to call your variable names.

6. Abstraction is your Enemy
Your problem is complex enough. Don't start to introduce additional complexity through abstract classes or factory design patterns... Sure sometimes that stuff is beneficial, but the priority here is simplicity first. Don't abstract anything unless you really have to!

7. Don't forget to clean up
While some of these principles might help you to quickly find a solution to your problem they might leave you with a little mess. That's why it's important to clean up afterwards. Make sure to think about your coworkers and ideally leave the code in a way that others won't face the struggles that you had. Thoroughly test everything and leave some notes of your findings.

Summary

Working on a complex problem can be frustrating but at the same time very rewarding if you manage to power through it. Hope you found these tips helpful and I'm looking forward to hearing your tips on how to deal with complex coding problems?

Create Instagram Like Stories with Nuxt 3 and TailwindCSS

Lukas Mauser — Wed, 18 Oct 2023 14:56:42 +0000

In this tutorial, I'll show you how to build a simplified stories component just like you know it from Instagram.

The result will look like this:

Not only is it a fun little coding challenge, but interactive components like this also greatly enrich the user experience of your website or application. You could create an onboarding component to educate your customers about your product or service in a fun and interactive way.

So let's go!

I'm using Nuxt 3 and TailwindCSS.

Setup the project

To get started, open a terminal and create a new Nuxt 3 project with:

npx nuxi@latest init stories

I named the project stories here, but of course you can choose any name that you like.

Next, we install Tailwind. We'll just follow their official guide here: https://tailwindcss.com/docs/guides/nuxtjs.

In your terminal run:

cd stories
npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init

This will install all dependencies and init a tailwind.config.js file for us. Open the tailwind config file and add the following code:

/** @type {import('tailwindcss').Config} */
module.exports = {
  content: [
    "./components/**/*.{js,vue,ts}",
    "./layouts/**/*.vue",
    "./pages/**/*.vue",
    "./plugins/**/*.{js,ts}",
    "./app.vue",
    "./error.vue",
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}

Create the assets folder in the root of your project and place a main.css file there. Add the following lines to it:

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

And finally update your nuxt.config.ts:

// https://nuxt.com/docs/api/configuration/nuxt-config
export default defineNuxtConfig({
  devtools: { enabled: true },
  css: ['~/assets/css/main.css'],
  postcss: {
    plugins: {
      tailwindcss: {},
      autoprefixer: {},
    },
  },
})

Create Testdata

The finished story component can look overwhelming at first, so let's break it down into small sub problems.

I usually start thinking about the underlying data set first.

We need to display different stories. Each story contains different slides with images. That's already it!

I will also add id's to our stories and slides, so that we have some unique identifiers for them, when trying to render them in a v-for-loop later.

Our data will be shaped like this:

interface Slide {
  id: string;
  imgUrl: string;
}

interface Story {
  id: string;
  slides: Slide[]
}

So let's start by grabbing some example images. I placed them inside Nuxt's public directory and created the following data set:

const stories = ref<Story[]>([
  {
    id: "story-1",
    slides: [
      { id: "slide-1", imgUrl: "bowl.jpeg" },
      { id: "slide-2", imgUrl: "eggs.jpg" },
      { id: "slide-3", imgUrl: "berlin.jpg" },
    ],
  },
  {
    id: "story-2",
    slides: [
      { id: "slide-4", imgUrl: "builder.png" },
      { id: "slide-5", imgUrl: "coder.jpg" },
    ],
  },
  {
    id: "story-3",
    slides: [
      { id: "slide-6", imgUrl: "berlin.jpg" },
      { id: "slide-7", imgUrl: "bowl.jpeg" },
      { id: "slide-8", imgUrl: "eggs.jpg" },
    ],
  },
  {
    id: "story-4",
    slides: [
      { id: "slide-9", imgUrl: "coder.jpg" },
      { id: "slide-10", imgUrl: "builder.png" },
    ],
  },
]);

Creating a functional frame

Now that we have some data to play around with, let's continue with some basic functionality.

I will start by rendering all stories and slides and apply some simple styling to be able to tell them apart.

<template>
  <div>

    <!--stories-->
    <div
      v-for="(story, index) in stories"
      :key="story.id"
      class="p-4 border bg-red-200"
    >
      {{ story.id }}

      <!--slides-->
      <div
        v-for="slide in story.slides"
        :key="slide.id"
        class="p-4 border bg-blue-200"
      >
        {{ slide.id }}
      </div>
    </div>
  </div>
</template>

<script setup lang="ts">

interface Slide {
  id: string;
  imgUrl: string;
}

interface Story {
  id: string;
  slides: Slide[];
}

// example data set
const stories = ref<Story[]>([...]);

</script>

The result looks like this:

Next, let's implement some basic navigation functionality.

We must keep track of which story and which slide is currently in focus. To do so, we will introduce a new variable const currentStoryIndex = ref(0) to keep track of the current story.

Also, because we will probably need it a bit, let's create a computed property to get the current story in focus:

const currentStory = computed(()=>{
   return stories.value[currentStoryIndex.value]
})

To keep track of our active slide, we will extend our story interface with a new property currentSlideIndex:

interface Story {
   id: string;
   slides: Slide[];
   currentSlideIndex: number;
}

Remember to update your test data as well!

We can then add some simple navigation logic. Adding and subtracting indices and making sure we don't go out of bounds:

function nextStory() {
  if (currentStoryIndex.value < stories.value.length - 1) {
    currentStoryIndex.value++;
  }
}

function prevStory() {
  if (currentStoryIndex.value > 0) {
    currentStoryIndex.value--;
  }
}

function nextSlide() {
  if (
    currentStory.value.currentSlideIndex <
    currentStory.value.slides.length - 1
  )
    stories.value[currentStoryIndex.value].currentSlideIndex++;
  else if (
    currentStory.value.currentSlideIndex ===
    currentStory.value.slides.length - 1
  ) {
    nextStory();
  }
}

function prevSlide() {
  if (currentStory.value.currentSlideIndex > 0)
    stories.value[currentStoryIndex.value].currentSlideIndex--;
  else if (currentStory.value.currentSlideIndex === 0) prevStory();
}

Basic styling + Refactoring

Time to add some basic styling!

While styling everything, my initial file grew quite a bit, so I decided to split it into the following 3 parts:

1. Page

Our Page contains all stories, as well as the navigation logic that I described earlier. Events from Story components get passed up to Page parent through $emits and values get passed down the component chain through properties. I don't work with Vue's provide and inject functions here, since they introduce a little bit of unnecessary complexity for this tutorial:

<template>
  <div
    class="h-screen flex items-center bg-black bg-opacity-50"
  >
    <!--stories-->
    <Story
      v-for="(story, index) in stories"
      :key="story.id"
      :story="story"
      :focused="index === currentStoryIndex"
      @prev-story="prevStory"
      @next-story="nextStory"
      @prev-slide="prevSlide"
      @next-slide="nextSlide"
    />
  </div>
</template>

<script setup lang="ts">
interface Slide {
  id: string;
  imgUrl: string;
}

interface Story {
  id: string;
  slides: Slide[];
  currentSlideIndex: number;
}

// example data set
const stories = ref<Story[]>([...]);

// track currently focused story
const currentStoryIndex = ref(0);

const currentStory = computed(() => {
  return stories.value[currentStoryIndex.value];
});

// navigate between slides on story

function nextSlide() {
  if (
    currentStory.value.currentSlideIndex <
    currentStory.value.slides.length - 1
  )
    stories.value[currentStoryIndex.value].currentSlideIndex++;
  else if (
    currentStory.value.currentSlideIndex ===
    currentStory.value.slides.length - 1
  ) {
    nextStory();
  }
}

function prevSlide() {
  if (currentStory.value.currentSlideIndex > 0)
    stories.value[currentStoryIndex.value].currentSlideIndex--;
  else if (currentStory.value.currentSlideIndex === 0) prevStory();
}

// navigate between stories

function nextStory() {
  if (currentStoryIndex.value < stories.value.length - 1) {
    currentStoryIndex.value++;
  }
}

function prevStory() {
  if (currentStoryIndex.value > 0) {
    currentStoryIndex.value--;
  }
}
</script>

2. Story

As you already saw above, inside our Page there is a Story Component. It contains the story's slides, navigation buttons to move to the next and previous story, as well as some logic to visually distinguish the currently focused story, from the others.

<template>
  <div class="w-96 rounded-xl flex-shrink-0 flex justify-center">
    <div class="relative flex rounded-xl overflow-hidden">
      <!--black overlay for non focused stories-->
      <div
        v-if="!focused && story.slides.length > 0"
        class="bg-black opacity-50 absolute inset-0 z-40"
      ></div>

      <!--prev story button-->
      <button v-if="focused" @click="$emit('prevStory')" class="text-gray-200">
        <svg
          xmlns="http://www.w3.org/2000/svg"
          fill="none"
          viewBox="0 0 24 24"
          stroke-width="1.5"
          stroke="currentColor"
          class="w-6 h-6"
        >
          <path
            stroke-linecap="round"
            stroke-linejoin="round"
            d="M11.25 9l-3 3m0 0l3 3m-3-3h7.5M21 12a9 9 0 11-18 0 9 9 0 0118 0z"
          />
        </svg>
      </button>

      <StorySlides
        :slides="story.slides"
        :story-focused="focused"
        :current-slide-index="story.currentSlideIndex"
        @next-slide="$emit('nextSlide')"
        @prev-slide="$emit('prevSlide')"
      />

      <!--snext story button-->
      <button v-if="focused" @click="$emit('nextStory')" class="text-gray-200">
        <svg
          xmlns="http://www.w3.org/2000/svg"
          fill="none"
          viewBox="0 0 24 24"
          stroke-width="1.5"
          stroke="currentColor"
          class="w-6 h-6"
        >
          <path
            stroke-linecap="round"
            stroke-linejoin="round"
            d="M12.75 15l3-3m0 0l-3-3m3 3h-7.5M21 12a9 9 0 11-18 0 9 9 0 0118 0z"
          />
        </svg>
      </button>
    </div>
  </div>
</template>

<script setup lang="ts">
interface Slide {
  id: string;
  imgUrl: string;
}

interface Story {
  id: string;
  slides: Slide[];
  currentSlideIndex: number;
}

defineProps<{ story: Story; focused?: boolean }>();
</script>

3. StorySlides

Finally, there is a component that holds all story slides. It renders all slide images on top of each other, and puts the active slide image in focus by applying the highest z-index.

Take note, that this approach leads to a snappy UI, but all images are downloaded at once. This could lead to a long initial loading time. I won't dive into performance optimization here, but it's good to keep in mind, where improvements could be made.

Just like in the Story component, navigation events get passed up the component chain through the $emit function.

Finally our StorySlides component contains a little progress indicator on top, showing what slide is currently in focus.

<template>
  <!--story slides-->
  <div class="relative h-[50vh] rounded-lg overflow-hidden w-64">
    <!--slide indicators-->
    <div
      v-if="storyFocused"
      class="z-30 absolute top-10 w-full px-2 flex space-x-1"
    >
      <div
        v-for="(slide, slideIndex) in slides"
        :key="slide.id + '-indicator'"
        class="h-1 rounded w-full cursor-pointer hover:bg-opacity-90"
        :class="[
          slideIndex <= currentSlideIndex ? 'bg-gray-100' : 'bg-gray-600',
        ]"
      ></div>
    </div>

    <!--prev/next slide buttons-->
    <button
      class="z-20 absolute h-full w-1/2 left-0 top-0"
      @click.stop="$emit('prevSlide')"
    ></button>
    <button
      class="z-20 absolute h-full w-1/2 right-0 top-0"
      @click.stop="$emit('nextSlide')"
    ></button>

    <!--slide images-->
    <div
      v-for="(slide, slideIndex) in slides"
      :key="slide.id"
      class="absolute top-0 left-0 h-full w-full"
      :class="{ 'z-10': currentSlideIndex === slideIndex }"
    >
      <img class="h-full w-full bg-black object-contain" :src="slide.imgUrl" />
    </div>
  </div>
</template>

<script setup lang="ts">
interface Slide {
  id: string;
  imgUrl: string;
}
defineProps<{
  slides: Slide[];
  storyFocused?: boolean;
  currentSlideIndex: number;
}>();
</script>

The result looks like this:

We have a fully functional stories component, all that's missing is to give it some life and introduce some movement to it!

Add Transition Animations

Everything that moves is usually a bit intimidating at first, but bare with me, in this case it will be quite simple to follow.

The animation here is not coming from an overflowing div, that is moved across the screen.

Instead think of 7 fixed story slots and each time we progress to the next story, we use tailwinds build in transition utilities to shift all of them to the left or right.

At the end of each transition, we'll quickly swap out all of the stories for the next one and create an illusion of a moving strip of content. Vue's build in '@transitionend' hook comes in very handy for that.

So let's dive into implementation!

We start by introducing a visibleStories property, that keeps track of the 7 story slots that are displayed.

Hide the overflow, center everything, refactor our currentStory and we end up here:

<template>
  <div
    class="relative h-screen flex items-center bg-black bg-opacity-50 overflow-x-hidden"
  >
    <div class="absolute flex left-1/2 -translate-x-1/2">
      <!--stories-->
      <Story
        v-for="(story, index) in visibleStories"
        :key="story.id"
        :focused="index === 3"
        :story="story"
        @next-slide="nextSlide"
        @prev-slide="prevSlide"
        @next-story="nextStory"
        @prev-story="prevStory"
      />
    </div>
  </div>
</template>


<script setup lang="ts">

//...

// placeholder to put into empty story slots before and after
// our current story
const emptyStorySlot: Story = { id: "empty", slides: [], currentSlideIndex: 0 };

// we only display 7 stories
const visibleStories = computed(() => {
  const extendedStories = [
    emptyStorySlot,
    emptyStorySlot,
    emptyStorySlot,
    ...stories.value,
    emptyStorySlot,
    emptyStorySlot,
    emptyStorySlot,
  ];
  return extendedStories.slice(
    currentStoryIndex.value,
    currentStoryIndex.value + 7
  );
});

// get the story that is in focus
const currentStory = computed(() => {
  return visibleStories.value[3];
});

function nextStory() {
  if (
    currentStoryIndex.value <
    visibleStories.value.length - stories.value.length
  ) {
    currentStoryIndex.value++
  }
}

function prevStory() {
  if (currentStoryIndex.value > 0) {
    currentStoryIndex.value--
  }
}
<script>

All that's left now, is to introduce the transition animation!

In our Page, we add two more variables, telling us whether to move left or right:

const moveLeft = ref(false)
const moveRight = ref(false)

Then, we'll update our story slots, to transition to the left or right, when these variables are triggered:

<Story
   ...
   :class="{
      'transition-all duration-300 -translate-x-full': moveLeft,
      'transition-all duration-300 translate-x-full': moveRight,
   }"

Now we need to modify our nextStory and prevStory functions. We don't want to transition to the next story right away, but rather trigger the movement first, and only when the transition finished, increase the currentStoryIndex:

function nextStory() {
  if (currentStoryIndex.value < visibleStories.value.length - stories.value.length) {
    moveLeft.value = true;
  }
}

function prevStory() {
  if (currentStoryIndex.value > 0) {
    moveRight.value = true;
  }
}

function transitionend(index: number) {
  // only run this function once
  if (index > 0) return;

  if (moveLeft.value) {
    currentStoryIndex.value++;
    moveLeft.value = false;
  } else if (moveRight.value) {
    currentStoryIndex.value--;
    moveRight.value = false;
  }
}

Take note that I introduces a new function transitionend here. We will trigger this by adding the @transitionend vue hook to our Story:

<Story
        ...
        :class="{
          'transition-all duration-300 -translate-x-full': moveLeft,
          'transition-all duration-300 translate-x-full': moveRight,
        }"
        @transitionend="transitionend(index)"
      />

And that's basically it! After a few more styling tweaks, to scale the stories as they enter and leave the current story slot, we end up with this:

<template>
  <div
    class="relative h-screen flex items-center bg-black bg-opacity-50 overflow-x-hidden"
  >
    <div class="absolute flex left-1/2 -translate-x-1/2">
      <div class="fixed top-0 left-0 z-50 text-white"></div>

      <!--stories-->
      <Story
        v-for="(story, index) in visibleStories"
        :key="story.id"
        :class="{
          'transition-all duration-300 -translate-x-full': moveLeft,
          'transition-all duration-300 translate-x-full': moveRight,
          'scale-150':
            (index == 3 && !moveLeft && !moveRight) ||
            (index == 4 && moveLeft) ||
            (index == 2 && moveRight),
        }"
        :focused="index === 3 && !moveLeft && !moveRight"
        :fade-overlay="(index == 4 && moveLeft) || (index == 2 && moveRight)"
        :story="story"
        @next-story="nextStory"
        @prev-story="prevStory"
        @next-slide="nextSlide"
        @prev-slide="prevSlide"
        @transitionend="transitionend(index)"
      />
    </div>
  </div>
</template>

<script setup lang="ts">
interface Slide {
  id: string;
  imgUrl: string;
}

interface Story {
  id: string;
  slides: Slide[];
  currentSlideIndex: number;
}

// example data set
const stories = ref<Story[]>([
  {
    id: "story-1",
    slides: [
      { id: "slide-1", imgUrl: "bowl.jpeg" },
      { id: "slide-2", imgUrl: "eggs.jpg" },
      { id: "slide-3", imgUrl: "berlin.jpg" },
    ],
    currentSlideIndex: 0,
  },
  {
    id: "story-2",
    slides: [
      { id: "slide-4", imgUrl: "builder.png" },
      { id: "slide-5", imgUrl: "coder.jpg" },
    ],
    currentSlideIndex: 0,
  },
  {
    id: "story-3",
    slides: [
      { id: "slide-6", imgUrl: "berlin.jpg" },
      { id: "slide-7", imgUrl: "bowl.jpeg" },
      { id: "slide-8", imgUrl: "eggs.jpg" },
    ],
    currentSlideIndex: 0,
  },
  {
    id: "story-4",
    slides: [
      { id: "slide-9", imgUrl: "coder.jpg" },
      { id: "slide-10", imgUrl: "builder.png" },
    ],
    currentSlideIndex: 0,
  },
]);

// keep track of story in focus
const currentStoryIndex = ref(0);

const currentStory = computed(() => {
  return stories.value[currentStoryIndex.value];
});

// placeholder to add to empty story slots

const emptyStorySlot: Story = { id: "empty", slides: [], currentSlideIndex: 0 };

// we only display 7 stories
const visibleStories = computed(() => {
  const extendedStories = [
    empty,
    empty,
    empty,
    ...stories.value,
    empty,
    empty,
    empty,
  ];
  return extendedStories.slice(
    currentStoryIndex.value,
    currentStoryIndex.value + 7
  );
});

// get the story that is in focus
const currentStory = computed(() => {
  return visibleStories.value[3];
});

// navigate through slides in story

function nextSlide() {
  if (
    currentStory.value.currentSlideIndex <
    currentStory.value.slides.length - 1
  )
    stories.value[3].currentSlideIndex++;
  else if (
    currentStory.value.currentSlideIndex ===
    currentStory.value.slides.length - 1
  ) {
    nextStory();
  }
}

function prevSlide() {
  if (currentStory.value.currentSlideIndex > 0)
    stories.value[3].currentSlideIndex--;
  else if (currentStory.value.currentSlideIndex === 0) prevStory();
}

// transition stories to left/ right

const moveLeft = ref(false);
const moveRight = ref(false);

// navigate through stories

function nextStory() {
  if (currentStoryIndex.value <
    visibleStories.value.length - stories.value.length) {
    moveLeft.value = true;
  }
}

function prevStory() {
  if (currentStoryIndex.value > 0) {
    moveRight.value = true;
  }
}

// swap stories when transition ends

function transitionend(index: number) {
  // run only once
  if (index > 0) return;

  if (moveLeft.value) {
    currentStoryIndex.value++;
    moveLeft.value = false;
  } else if (moveRight.value) {
    currentStoryIndex.value--;
    moveRight.value = false;
  }
}
</script>

Summary

To sum it all up:

Interactive components make your website or application alive and fun to use
Building them can be intimidating at first, but when you break it down into small problems, they become very manageable
We started with thinking about how the underlying data needs to look and created a test data set to work with
Next, we implemented some wireframes without styling them or thinking about any animations
Once everything worked, we introduced some basic styling for our code and refactored it into 3 sub components in order to stay ahead of the introduced complexity
To finish it off, we added the animation which consists of defining 7 fixed slots for each story, then transition each slot to the side and swapping the stories inside these slots after the transition ended.

And that's it!

Of course there is always something to improve upon. I mentioned coming up with a more network friendly loading strategy or making parts of the code a bit more tidy. Do you have any recommendations? Let me know in the comments!

Cheers ✌🏻

Validate HTML Form Inputs With Vanilla Js

Lukas Mauser — Mon, 09 Oct 2023 15:47:32 +0000

Validating HTML forms can be a pain >.<

You might be tempted to pull in an external form library, but the fact that you need to deal with a few input fields that require custom validation is probably not enough reason to pull in an external library.

Each external library introduces new dependencies and potential vulnerabilities. It comes with a learning curve and sometimes these form libraries do not really help a lot to tidy your code. On top you either need to customize the layout so much that you did not save anything at the end or you're stuck with their design...

Vanilla JS and HTML offer some great tools already!

Let me show you, how you can easily add custom validation to your HTML forms.

In our example, we have an HTML form that contains two password input fields:

<form>
  <input id="password" type="password" placeholder="password" />
  <input id="confirmPassword" type="password" placeholder="confirm password" />
  <button type="submit">Sign up</button>
</form>

We can add basic validation with built in HTML attributes like required or minlength.:

  <input id="password" type="password" placeholder="password" required  minlength="6" />

But what if we want to check, if the password and confirm password field match?

For this scenario, we need custom validation.

So let's explore how easy it is, to write a custom validation function:

function formSubmitHandler() {
  // grab inputs
  const passwordInput = document.getElementById("password");
  const confirmPasswordInput = document.getElementById("confirmPassword");

  // validation logic
  if (passwordInput.value !== confirmPasswordInput.value) {
    confirmPasswordInput.setCustomValidity("The passwords don't match!");
    confirmPasswordInput.reportValidity();
    return;
  }
  // handle valid inputs ...
}

First, we simply grab our inputs with document.getElementById(...). Then we run our custom validation logic on the input values. If the validation fails, we set a custom validation error message on the input via the setCustomValidity(...) function and trigger the validation event with the reportValidity() function.

And that's all it takes. If necessary you can even translate your validation messages and structure your code as you need to.

In simple use cases you don't need to add an external form library to handle validation for your form fields.

Take note though, that cross-browser support for these built in validation methods should be double checked.