DEV Community: Markus Oberlehner

Are my Component Names Too Long? Vue.js Component Naming Best Practices

Markus Oberlehner — Sun, 31 May 2020 05:43:13 +0000

When naming your (Vue.js) components, you might sometimes be worried that the names are getting very long. In this article, we take a closer look at how long is too long and what are the most important best practices when it comes to naming your components.

What is too long?

Jane Manchun Wong from Facebook has gathered data from more than 3000 components in the Facebook React codebase. Her results are that the mean length of a component name is 27 characters: ImA27CharacterComponentName. And the longest component name counts 66 characters. She also gives two examples for some very long component names.

CometSearchTypeaheadInternalLayoutInlineStrategyWithScrollableView
CoronavirusCommunityHelpCometRequestOfferHelpCreateDialog

On the one hand, we should always strive to keep our code short and concise. On the other hand, we read more code than we write. Therefore, it is critical to quickly understand what a component does rather than to save a few milliseconds while writing the code.

That is why I argue that you should worry much less about your component names getting too long and instead focus on getting them right. It's more important to stick to some general rules and best practices when choosing the names for your components.

Best practices

The official Vue.js style guide provides us with a comprehensive list of recommendations for how to name our Vue.js components. You might notice that even in the examples, some of the component names are getting quite long.

Wrapping it up

Don't worry about your component names becoming too long! Instead, focus on coming up with descriptive names and rigorously follow the best practices I mentioned above. In the long run, it pays off.

Context and Provider Pattern with the Vue 3 Composition API

Markus Oberlehner — Sun, 24 May 2020 07:25:57 +0000

The React Context API provides a way to share properties that are required by many components (e.g., user settings, UI theme) without having to pass a prop through every level of the tree (aka prop drilling). Although Vue.js does not provide the same abstraction out of the box, in this article, we'll see that in Vue 3, we have all the tools we need to replicate the same functionality quickly.

User settings provider

In this example, we look at how we can use this pattern to make certain information globally available everywhere in our entire application.

The ProvideUserSettings component you see beneath, provides a reactive state with some default values and an update() function for setting properties on the state object.

// src/components/ProvideUserSettings.js 
import {
  provide,
  reactive,
  readonly,
  toRefs,
} from 'vue';

// We use symbols as a unique identifiers.
export const UserSettingsStateSymbol = Symbol('User settings provider state identifier');
export const UserSettingsUpdateSymbol = Symbol('User settings update provider identifier');

export default {
  setup() {
    const state = reactive({
      language: 'en',
      theme: 'light',
    });
    // Using `toRefs()` makes it possible to use
    // spreading in the consuming component.
    // Making the return value `readonly()` prevents
    // users from mutating global state.
    provide(UserSettingsStateSymbol, toRefs(readonly(state)));

    const update = (property, value) => {
      state[property] = value;
    };
    provide(UserSettingsUpdateSymbol, update);
  },
  render() {
    // Our provider component is a renderless component
    // it does not render any markup of its own.
    return this.$slots.default();
  },
};

Next we take a look at how we can use the ProvideUserSettings component in our application.

<!-- src/App.vue -->
<script>
import ProvideUserSettings from './components/ProvideUserSettings';

export default {
  name: 'App',
  components: {
    ProvideUserSettings,
  },
};
</script>

<template>
  <ProvideUserSettings>
    <div>
      <!-- ... -->
    </div>
  </ProvideUserSettings>
</template>

We probably need the settings in a lot of different components throughout our application. Because of that, it makes sense to put the provider at the root level inside of our App component.

So we now have access to the user settings from anywhere in our component tree.

<!-- src/components/ButtonPrimary.vue -->
<script>
import { inject } from 'vue';

import { UserSettingsStateSymbol } from './ProvideUserSettings';

export default {
  setup() {
    const { theme } = inject(UserSettingsStateSymbol);

    return { theme };
  },
};
</script>

<template>
  <ButtonBase
    :class="$style[`t-${theme}`]"
  >
    <slot/>
  </ButtonBase>
</template>

<style module>
.t-light { /* ... */ }

.t-dark { /* ... */ }
</style>

Above, we see how to consume the state of the injected context. In the following example, we explore how to update the state from any component in our application.

<!-- src/components/ThemeSwitcher.vue -->
<script>
import { inject } from 'vue';

import { UserSettingsUpdateSymbol } from './ProvideUserSettings';

export default {
  setup() {
    const updateUserSettings = inject(UserSettingsUpdateSymbol);
    const updateTheme = value => updateUserSettings('theme', value);

    return { updateTheme };
  },
};
</script>

<template>
  <div>
    <button @click="updateTheme('dark')">
      Enable darkmode
    </button>
    <button @click="updateTheme('light')">
      Enable lightmode
    </button>
  </div>
</template>

This time we inject the update() function with the UserSettingsUpdateSymbol. We wrap the injected function in a new updateTheme() function which directly sets the theme property of our user settings object.

In theory, we could not wrap our state with readonly() and mutate it directly. But this can create a maintenance nightmare because it becomes tough to determine where we make changes to the (global) state.

When we click one of the two buttons, the user settings state is updated, and because it is a reactive object, all components which are using the injected user settings state are updated too.

Wrapping it up

Although Vue.js does not have the concept of Context built-in like React, as we've seen in this article, it is straightforward to implement something similar to that with Vue 3 provide/inject ourselves.

Stale-While-Revalidate Data Fetching Composable with Vue 3 Composition API

Markus Oberlehner — Thu, 21 May 2020 06:50:10 +0000

When building apps that rely on data from an API, two things are essential: we want our data to be fresh, and we want it fast. The stale-while-revalidate caching pattern helps us to strike a balance between both.

If our cache already contains a copy of the requested information, we can immediately show the (potentially stale) data. But at the same time, we revalidate our cache and fetch a new version. This can make navigating our apps feel instantaneously while also making sure that the user sees the latest data eventually.

In this video, you can see two components which both fetch their data from the same API endpoint. Thanks to the SWR composable, the data is always in sync. Even if a new component is added, it immediately has access to the cached data while fetching a fresh copy in the background.

If you want to try it yourself, you can check out the demo hosted on Netlify and take a closer look at the code on GitHub.

Inspiration in the React world

In the last couple of weeks, I played around with Preact, and I learned a thing or two about how to do things in the React ecosystem. I discovered that because of how React Hooks work, there are a few special requirements on how to fetch data in React components.

This is why since the introduction of Hooks, two quite similar data fetching libraries saw the light of day: React Query and SWR. What we build today is inspired by those libraries.

SWR Data Fetching Composable with Vue 3

I kept an eye on the development of the Vue 3 Composition API since the first RFC was published, but I never got around actually using it extensively. After experimenting with it for a couple of days, I can say this: it is fantastic! Now that I have (minimal) knowledge about how things are done in React, I can even more appreciate how powerful and straightforward to use the Composition API is.

So without further ado, let's take a look at a naive implementation of a stale-while-revalidate data fetching composable for Vue 3.

// src/composables/swr-cache.js
import { reactive, readonly, toRefs } from 'vue';
import LRU from 'lru-cache';

import { asArray } from '../utils/as-array';

const CACHE = new LRU({ max: 1024 });

const DEFAULT_OPTIONS = {
  dedupingInterval: 2000,
};

// We use `Symbol` for the state properties to prevent
// consumers of this package to use raw strings.
// See: https://bit.ly/2Lh2lEM
export const STATE = {
  error: Symbol('error'),
  idle: Symbol('idle'),
  loading: Symbol('loading'),
  revalidating: Symbol('revalidating'),
};

export function useSwrCache(parameter, callback, customOptions) {
  const options = {
    ...DEFAULT_OPTIONS,
    ...customOptions,
  };

  // Wrap `parameter` in an array if it is not an array already.
  const parameters = asArray(parameter);
  // Naive way of creating a unique cache key.
  const cacheKey = `${JSON.stringify(parameters)}${callback.toString()}`;
  const cacheKeyDedupe = `${cacheKey}_dedupe`;
  const cachedResponse = CACHE.get(cacheKey);

  // Use the reactive object from the cache or create a new one.
  const response = cachedResponse || reactive({
    data: null,
    error: null,
    reload: undefined,
    state: undefined,
  });

  if (!cachedResponse) CACHE.set(cacheKey, response);

  const load = async () => {
    try {
      // Dedupe requests during the given interval.
      if (CACHE.get(cacheKeyDedupe)) return;

      CACHE.set(cacheKeyDedupe, true, options.dedupingInterval);

      response.state = response.data ? STATE.revalidating : STATE.loading;
      // Wait for the result of the callback and set
      // the reactive `data` property.
      response.data = Object.freeze(await callback(...parameters));
      response.state = STATE.idle;
    } catch (error) {
      console.error(error);

      CACHE.del(cacheKeyDedupe);

      response.error = error;
      response.state = STATE.error;
    }
  };

  response.reload = load;
  load();

  // Using `toRefs()` makes it possible to use
  // spreading in the consuming component.
  // Making the return value `readonly()` prevents
  // users from mutating global state.
  return toRefs(readonly(response));
}

One beautiful thing about this approach but also a potential gotcha is that every instance that resolves to the same cache key shares the same reactive object. So if one component triggers a reload, the data is updated everywhere. It almost works like a global Vuex store.

One thing to mention is that the way how the cacheKey is created is not very reliable. Because: JSON.stringify({ a: 'a', b: 'b' }) !== JSON.stringify({ b: 'b', a: 'a' }). Property order does matter! But as long as you only use strings as parameters, that's no problem.

Usage

Now let's take a look at how we can use our newly created useSwrCache() composable.

<template>
  <div>
    <h2>Profile</h2>

    <template v-if="user">
      Name: {{ user.name }}
      <!-- ... -->
    </template>
    <template v-else-if="state === STATE.loading">
      LOADING ...
    </template>
    <template v-else-if="state === STATE.error">
      {{ error }}
    </template>

    <!-- Stale data is shown while revalidating! -->
    <template v-if="state === STATE.revalidating">
      <small>REVALIDATING ...</small>
    </template>
  </div>
</template>

<script>
import { fetcher } from '../utils/fetcher';
import { useSwrCache, STATE } from '../composables/swr-cache';

export default {
  name: 'UserProfile',
  setup() {
    const {
      data: user,
      error,
      state,
    } = useSwrCache('https://jsonplaceholder.typicode.com/users/1', fetcher);

    return {
      STATE,
      error,
      state,
      user,
    };
  },
};
</script>

The fetcher utility is a simple wrapper around fetch(). useSwrCache returns a reactive object with the data, the current state and, if applicable, an error.

We have two different states for loading (no cached data) and revalidating.

Wrapping it up

Although it works perfectly fine, this is a quite raw implementation and in no way as comprehensive as React Query or SWR. If you consider using something like this in production, you might want to use a more bulletproof approach for generating unique cache keys.