🔥 (#143) Static and dynamic classes

Hey!

I hope your week is going well.

This week I've been working on updating all the dependencies for Mastering Nuxt 3. It's quite tedious going through each lesson and making the necessary changes, but it makes the experience way smoother when going through the course.

I also took some time to switch the format of the repo to each lesson being on a separate branch.

When I made the course I did one commit per lesson all on a single branch, but that made it really difficult to go back and fix anything. Now I can just add a commit to the relevant branch!

Oh, and I'm also working on a Christmas gift for you 🎅 — but you'll have to wait a bit to find out what that is...

Enjoy your tips!

— Michael

🔥 Static and dynamic classes

We can add static and dynamic classes to an element at the same time:

<ul>    <li      v-for="item in list"      :key="item.id"      class="always-here"      :class="item.selected && 'selected'"    >      {{ item.name }}    </li>  </ul>

This lets you apply basic styling through static classes and then dynamically add other styles as you need them.

You can also achieve the same thing when using an Object or Array with dynamic classes:

<ul>    <li      v-for="item in list"      :key="item.id"      :class="{        'always-here': true,        selected: item.selected,      }"    >      {{ item.name }}    </li>  </ul>

Or with an Array:

<ul>    <li      v-for="item in list"      :key="item.id"      :class="[        'always-here',        item.selected && 'selected',      ]"    >      {{ item.name }}    </li>  </ul>

I prefer splitting them out into class and :class bindings though, since it makes the code clearer. It also makes it less likely to be broken when refactored!

🔥 From Options to Composition — The Easy Way

You can use reactive to make the switch from the Options API a little easier:

// Options API  export default {    data() {      username: 'Michael',      access: 'superuser',      favouriteColour: 'blue',    },  	methods: {      updateUsername(username) {        this.username = username;      },    }  };

We can get this working using the Composition API by copying and pasting everything over using reactive:

// Composition API  setup() {    // Copy from data()    const state = reactive({      username: 'Michael',      access: 'superuser',      favouriteColour: 'blue',    });      // Copy from methods    updateUsername(username) {      state.username = username;    }    	// Use toRefs so we can access values directly  	return {      updateUsername,      ...toRefs(state),    }  }

We also need to make sure we change this → state when accessing reactive values, and remove it entirely if we need to access updateUsername.

Now that it's working, it's much easier to continue refactoring using ref if you want to — or just stick with reactive.

🔥 6 Levels of Reusability

There are six different levels of reusability that you can use in your components.

Each level increases your ability to reuse code.

These levels are the focus of my course, Reusable Components.

Here are the six levels of reusability:

1. Templating — Reusing code by wrapping it up inside of a component
2. Configuration — Using configuration props to allow for varying behaviour
3. Adaptability — Allowing components to become future-proof
4. Inversion — Letting other components control the process
5. Extension — Using reusability throughout our component
6. Nesting — Creating powerful hierarchies of components

I cover this in more detail in this excerpt from the course.

📜 What is Universal Rendering in Nuxt 3?

Modern web development has brought forth two main types of applications: Single Page Apps (SPA) and Server Side Rendered apps (SSR).

While each has its advantages, Nuxt offers a unique approach that combines the benefits of both types.

This article delves deeper into the workings of SPAs, SSRs, and the innovative Universal Rendering of Nuxt.

Check it out here: What is Universal Rendering in Nuxt 3?

💬 90%

"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time." — Tom Cargill

🧠 Spaced-repetition: The Data Store Pattern

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.

The simplest solution to lots of state management problems is to use a composable to create a shareable data store.

This pattern has a few parts:

1. A global state singleton
2. Exporting some or all of this state
3. Methods to access and modify the state

Here's a simple example:

import { reactive, toRefs, readonly } from 'vue';  import { themes } from './utils';    // 1. Create global state in module scope, shared every  //    time we use this composable  const state = reactive({    darkMode: false,    sidebarCollapsed: false,    // 2. This theme value is kept private to this composable    theme: 'nord',  });    export default () => {    // 2. Expose only some of the state    //    Using toRefs allows us to share individual values    const { darkMode, sidebarCollapsed } = toRefs(state);      // 3. Modify our underlying state    const changeTheme = (newTheme) => {      if (themes.includes(newTheme)) {        // Only update if it's a valid theme        state.theme = newTheme;      }    }      return {      // 2. Only return some of the state      darkMode,      sidebarCollapsed,      // 2. Only expose a readonly version of state      theme: readonly(state.theme),      // 3. We return a method to modify underlying state      changeTheme,    }  }

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

Unsubscribe | 8 Queen St N, Kitchener, ON N2H2G8