Exclusive tips every week

Hey there!

I hope you're having a fantastic week.

Here are some tips and other Vue content for you.

— Michael

🔥 Configurable Composables

We can make our composables more reusable by passing in an object that contains all of the configuration options for how we want the composable to behave:

const state = ref({ email: '' });

const { history, undo, redo } = useRefHistory(state, {
  // Track history recursively
  deep: true,
  // Limit how many changes we save
  capacity: 10,
});

We use an object here instead of a long list of parameters:

const { history, undo, redo } = useRefHistory(state, true, 10));

Using an options object instead of parameters gives us several benefits.

First, it’s self-documenting. We have the name of the parameter right beside the value, so we never forget what each value is doing.

We can also create a type for the entire options object:

export type RefHistoryOptions {
  deep?: boolean;
  capacity?: number;
};

export type RefHistoryReturn {
  history: Ref;
  undo: () => void;
  redo: () => void;
};

export function useRefHistory(
  ref: Ref,
  options: RefHistoryOptions
): RefHistoryReturn {};

Second, we don’t need to worry about ordering or unused options. The more potential edge cases we cover with a composable, the more options we’ll have. But we usually only need to worry about a couple of them at one time — they’re all optional.

Third, it’s much easier to add new options. Because the order doesn’t matter and none of the options are required, adding a new capability to our composable won’t break anything. We simply add it to the list of possible options and carry on.

The pattern doesn’t require a lot of work to implement, either:

export function useRefHistory(ref, options) {
  const {
    deep = false,
    capacity = Infinity,
  } = options;

  // ...
};

First, we pass in the options object as the last parameter. This makes it possible to have the options object itself as an optional parameter.

The required params come first. Typically, there will only be one or two. More parameters is a code smell, and likely means that your composable is trying to do too much.

The required parameter (or parameters) is very often a Ref, or a MaybeRef if we’re also implementing the Flexible Arguments Pattern.

We then access the options by destructuring.

Doing this gives us a really clean and readable way of providing defaults. Remember, these are options so they should all have defaults. If the values are required they should likely have

This helps to clarify what options are being used in this composable. It’s not uncommon for one composable to use another composable, and in that case some of the options are simply passed along to the inner composable:

export function useRefHistory(ref, options) {
  const {
    deep = false,
    capacity = Infinity,
    ...otherOptions,
  } = options;

  // Pass along some options we're not using directly
  useSomeOtherComposable(otherOptions);
};

🔥 Multiple Named Slots

Named slots allow you to design components with multiple content insertion points, each identified by a unique name.

This is particularly useful when a single slot isn't sufficient for the component's complexity.

For example, an Input component might need to display icons before or after the input field:

<!-- Input.vue -->
<template>
  <div class="input-styling">
    <slot name="icon-before" />
    <input ...>
    <slot name="icon-after" />
  </div>
</template>

Using the component, you can choose where to place an icon by targeting the specific named slot:

<template>
  <Input>
    <template #icon-before>
      <IconBefore />
    </template>
  </Input>
  <Input>
    <template #icon-after>
      <IconAfter />
    </template>
  </Input>
</template>

Named slots can be applied in any order and are referenced directly under the component they belong to.

They can also be dynamically generated, offering even more flexibility.

🔥 Looping Over a Range in Vue

The v-for directive allows us to loop over an Array, but it also let's us loop over a range:

<template>
  <ul>
    <li v-for="n in 5">Item #{{ n }}</li>
  </ul>
</template>

This will render out:

• Item #1
• Item #2
• Item #3
• Item #4
• Item #5

When we use v-for with a range, it will start at 1 and end on the specified number.

📜 Composition API vs. Options API

The Composition API and Options API are two different ways to structure your Vue code.

In this article I compare the two in depth, and give my own opinion on which one is best (it's the Composition API).

Check it out here: Composition API vs. Options API

📜 24 Time-Saving Tips for Nuxt

We know that Nuxt is a fantastic tool.

But it has so many amazing features that it’s hard to keep track of them all.

That’s why I’ve compiled this giant list of 24 Nuxt tips for you — use them to save time and write better Nuxt apps.

We cover a lot of topics here, including:

• When to use /assets vs. /public directory
• Using runtimeConfig vs. app.config
• Understanding how Universal rendering works (and how it’s different from SPA and SSR)
• A utility to make your own NuxtLink components that no one is talking about
• Adding a basic cache to your data fetching — since Nuxt doesn’t do this by default

Of course, there is so much more!

Check it out here: 24 Time-Saving Tips for Nuxt

💬 Things

"Things aren’t always #000000 and #FFFFFF." — undefined

🧠 Spaced-repetition: Reusability Fundamentals: The Configuration 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.

So you've got a fantastic CodeBlock component that does syntax highlighting and even shows line numbers:

<CodeBlock language="js">
  const myMessage = 'Highlighting code is supa ez';
</CodeBlock>

But now, you need to support a second colour theme.

Instead of copy and pasting (which is sometimes the right solution!), we can use props to help us create variations:

<!-- Uhhh, maybe not the best solution -->
<DarkModeCodeBlock language="js">
  const myMessage = 'Highlighting code is supa ez';
</DarkModeCodeBlock>

<!-- This is what props were meant for -->
<CodeBlock
  language="js"
  theme="darkMode"
>
  const myMessage = 'Highlighting code is supa ez';
</CodeBlock>

You already do this intuitively, so this may not be a huge revelation.

But the Configuration pattern is a fundamental pattern — you can't ignore it if you want to master reusability.

Dealing with prop explosions and understanding the Base Component Pattern is also part of mastering Configuration, the second level of reusability.

And the other, more exciting levels of reusability?

Well, mastering Configuration is vital to unlocking them. All the other levels build on top of this one.

🔗 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.