🔥 (#170) Redirecting in Nuxt (Every Single Way)

Hey!

I just wrote a comprehensive guide on redirecting in Nuxt.

It turns out there are a lot of different ways to do this, depending on what you need done!

You can read it on the Mastering Nuxt blog:

How to Redirect in Nuxt (Every Single Way)

In other news, Alex and I are continuing to put out new podcast episodes each week. Interviews with Daniel Roe and Evan You are coming up in the next couple weeks, so stay tuned for that!

The next thing I'm working on is the Nuxt Tips Collection. I'm already at 64 tips and counting, almost all of them completely brand new for the book!

Enjoy your tips, and enjoy the rest of your week!

— Michael

🔥 Make Testing Easy

Testing is important to do, but it can be hard to do.

In my experience, good architecture lends itself to easy-to-write tests (or at least, easier-to-write). The inverse is also true, that difficult-to-write tests are typically a symptom of poor architecture.

Of course, sometimes tests are just hard to write, and there’s no way around it.

The best thing we can do is borrow a tool from mathematics and science, and transform a difficult problem into an easier but equivalent one:

• Humble Components — UI is notoriously hard to test, and always has been. So keep as much in Humble Components, components that only receive props and emit events and nothing else. By making our UI as simple as possible we also make it much easier to test.
• Extract logic to composables — And I mean all of your logic. Components (that aren’t Humble) should only contain the bare minimum to connect all the different composables together. Think of them as Controller Components, the “C” in MVC.
• Composables are thin layers of reactivity — The easiest thing in the world to test are pure functions that have no dependencies. If you can make the majority of your codebase simple JS or TS code, you’ve already won. Composables then become simple wrappers that add a layer of reactivity to this business logic.

🔥 Destructuring in a v-for

Did you know that you can destructure in a v-for?

<li
  v-for="{ name, id } in users"
  :key="id"
>
  {{ name }}
</li>

It's more widely known that you can grab the index out of the v-for by using a tuple like this:

<li v-for="(movie, index) in [
  'Lion King',
  'Frozen',
  'The Princess Bride'
]">
  {{ index + 1 }} - {{ movie }}
</li>

When using an object you can also grab the key:

<li v-for="(value, key) in {
  name: 'Lion King',
  released: 2019,
  director: 'Jon Favreau',
}">
  {{ key }}: {{ value }}
</li>

It's also possible to combine these two methods, grabbing the key as well as the index of the property:

<li v-for="(value, key, index) in {
  name: 'Lion King',
  released: 2019,
  director: 'Jon Favreau',
}">
  #{{ index + 1 }}. {{ key }}: {{ value }}
</li>

🔥 Ref vs. Reactive

Is it better to use ref or reactive when using the composition API?

Here are a few situations where ref is better than reactive.

Using ref on objects makes it clear where an object is reactive and where it's just a plain object:

// I can expect this ref to update reactively
if (burger.value.lettuce) {
  // ...
}

// I have no clue if this value is reactive
if (burger.lettuce) {
  // ...
}

When using one of the watch methods, refs are automatically unwrapped, so they're nicer to use:

// Ref
const refBurger = ref({ lettuce: true });
watch(
  // Not much, but it's a bit simpler to work with
  refBurger,
  () => console.log("The burger has changed"),
  { deep: true }
);

// Reactive
const reactiveBurger = reactive({ lettuce: true });
watch(
  reactiveBurger,
  () => console.log("The burger has changed"),
);

One last reason why refs make more sense to me — you can put refs into a reactive object. This lets you compose reactive objects out of refs and still use the underlying refs directly:

const lettuce = ref(true);
const burger = reactive({
  // The ref becomes a property of the reactive object
  lettuce,
});

// We can watch the reactive object
watchEffect(() => console.log(burger.lettuce));

// We can also watch the ref directly
watch(lettuce, () => console.log("lettuce has changed"));

setTimeout(() => {
  // Updating the ref directly will trigger both watchers
  // This will log: `false`, 'lettuce has changed'
  lettuce.value = false;
}, 500);

🎙️ #012 — Geotastic, a Vue-based Browser Game (with Creator Eduard But)

Today on DejaVue, Alex and Michael are joined by Game and Web Developer Eduard But, who created Geotastic - a Vue-based browser game revolving around geographical knowledge and uses Googles Maps and Streetview API! Starting with Edu's background in programming and web development and initial experiences with Vue.js, we dive deep into how it happened he got into Game Development, which multiplayer game he built first and why and eventually talk about Geotastic.

With more than 1.5 Million registered users, Edu reveals details about the financial model, how he keeps things up and running, challenges while maintaining and which new game mode will come to Geotastic soon! Tune in to hear all of the above and more.

Watch on YouTube or listen on your favourite podcast platform.

Chapters:

• 00:00 - Intro and Guest Introduction
• 01:31 - How did you get into Programming and Web Development?
• 03:55 - Did you like being responsible for the "Full Stack"?
• 05:46 - After working at a Media Agency
• 07:55 - First Experience with Vue.js
• 11:55 - Creating the first browser-based Game
• 16:54 - Learnings from building a Multiplayer Game
• 19:20 - Starting Geotastic
• 21:20 - What type of Game is Geotastic?
• 24:22 - Deciding against a Subscription Model
• 28:03 - Differences between Geotastic and GeoGuessr
• 30:53 - Embracing the Community
• 32:49 - How did you use Vue.js to build the Game?
• 35:45 - Technical Challenges while maintaining Geotastic
• 41:36 - Taking a look at the back-end
• 43:38 - Daily Players and Expenses
• 48:36 - "Just do it" mentality
• 51:27 - People asked for Ads 😲
• 53:39 - When will Geotastic Ranked come?
• 57:21 - SPOILER - A new game mode
• 59:28 - Wrapping up

In case you missed them:

• #011 — Learning new Vue Features and Concepts (with LearnVue aka. Matt Maribojoc)
• #010 — Design Patterns in Vue.js
• #009 — Vue.js in Large Applications (with Tim Benniks)

📜 12 Design Patterns in Vue

Design patterns are incredibly useful in writing code that works well over the long run. They let us use proven solutions to problems that basically every single app has.

But there isn’t a lot written about how design patterns apply specifically to Vue.

In this article, I cover 12 design patterns that I think are crucial to writing great Vue apps.

Check it out here: 12 Design Patterns in Vue

📜 3 Kinds of Props in Vue

One of Vue's core features is the use of props. Props are how we pass data around in Vue, from parent to child components.

But not all props are created equal.

There are three main kinds:

• Template Props
• Configuration Props
• State Props (or Data Props).

Check it out here: 3 Kinds of Props in Vue

📅 Upcoming Events

Here are some upcoming events you might be interested in. Let me know if I've missed any!

VueConf CN 2024 — (July 6, 2024)

Check it out here

PragVue 2024 — (September 17, 2024)

The first Czech Vue.js conference, taking place in Cinema City - Nový Smíchov

Check it out here

Vuejs.de Conf — (October 8, 2024 to October 9, 2024)

A community-driven Vue conference in Germany. Listen to great talks from great speakers and meet the wonderful VueJS Community.

Check it out here

Vue Fes Japan 2024 — (October 19, 2024)

Check it out here

VueConf Toronto 2024 — (November 18, 2024 to November 20, 2024)

My favourite Vue conference, in my own backyard! A three-day event with workshops, speakers from around the world, and socializing.

Check it out here

💬 Write Less

"A good way to stay flexible is to write less code." — Pragmatic Programmer

🧠 Spaced-repetition: UI states to get right

The best way to commit something to long-term memory is to periodically review it, gradually increasing the time between reviews 👨‍🔬

Actually remembering these tips is much more useful than just a quick distraction, so here's a tip from a couple weeks ago to jog your memory.

When building a UI, there are many different states that you need to consider:

• Normal — Sometimes called the "happy path," this is when things are working as expected. For example, in an email client, you'd show some read emails, some unread emails, and maybe a few that are in the "spam" folder.
• Loading — Your UI has to do something while getting the data, right? A couple tricks:
  1. Use a computed prop to combine multiple loading states — you don't want spinners all over the page.
  2. Wait about 200ms before showing a spinner. If the data loads before that, it feels faster than if you quickly flash the loading spinner on and then off again.
• Error — Things will go wrong, and you need to handle that gracefully. Effectively communicating problems to users to help them get unstuck is very tricky (don't make me guess the password requirements!). Hopefully, you have a good UX designer. Empty — What happens when you have no emails to read, have completed all your tasks, or haven't uploaded any videos yet? A chart showing the "Last 30 Days" of data will probably look weird with no data.
• Partial Data — Often similar to the empty state, but your big table with filtering and sorting also needs to work with only two rows of data. The list of emails shouldn't break with only one email in it.
• Lots of data — Okay, now you have 1294 unread emails. Does your UI break? Maybe that infinite scrolling doesn't make as much sense as when there were only 42 emails.

🔗 Want more Vue and Nuxt links?

Michael Hoffman curates a fantastic weekly newsletter with the best Vue and Nuxt links.

Sign up for it here.

p.s. I also have four products/courses: Clean Components Toolkit, Vue Tips Collection 2, Mastering Nuxt 3, and Reusable Components