Michael Thiessen

🔥 (#26) Understanding component reusability

September 2021

Heyo,

Nuxt Nation is happening today (maybe right now depending on when you open this email).

You might still be able to catch some of the action: Nuxt Nation

In the meantime, here are some more tips for ya.

— Michael

🔥 6 Levels of Reusability

My course on reusable components covers this framework, which outlines six different levels of reusability that you can use in your 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

🔥 Grid Template Areas

Sometimes complicated layouts are, well, complicated. But using grid-template-areas is here to help!

<section>

  <header>Page header</header>

  <nav>Nav bar</nav>

  <main>Content goes here!</main>

  <footer>Not for your feet</footer>

</section>

With this HTML, you'd first attach grid-area names to each element:

header { grid-area: header; }

nav { grid-area: nav; }

main { grid-area: main; }

footer { grid-area: footer; }

Now you can describe your layout:

section {

  /* ... some other CSS grid set up here */

  grid-template-areas: "header header"

                       "nav    main"

                       "footer footer";

}

And if you need a single column layout for mobile (with the nav at the bottom, just for fun):

section {

  grid-template-areas: "header"

                       "main"

                       "nav"

                       "footer";

}

It's pretty easy to see exactly how the page is being laid out with grid-template-areas.

What makes a conference great?

Is it a diverse array of speakers — amazing people who have valuable insights to share?

Informative talks on a wide array of subjects, so you learn about things you didn't even know existed?

Or is it really about how the hosts entertain you, and make you feel like a part of the Vue family?

I don't know.

But I do know that VueConf Toronto has it all, including:

  • Free, virtual talks
  • Workshops, speaker Q+A, and hands on sessions
  • Talking with other Vue devs, including a virtual after party

It all takes place November 22-23.

Don't miss out on upping your Vue game — register now.

đź“ś Helpful Patterns in Vue

Although I disagree with using custom elements to get a flatter component hierarchy, Brennan has a bunch of useful tips and patterns in this article.

I use the loading state one all the time.

Read it here: Helpful Patterns I Use in Vue

đź—ž News: Nuxt Nation is TODAY

Don't miss it!

We also have three more conferences coming up in the next 2 months, all accessible online and two offering (limited) in-person experiences:

đź’¬ Two Types of Languages

"There are only two kinds of languages: the ones people complain about and the ones nobody uses." — Bjarne Stroustrup

🧠 Spaced-repetition: Vue Testing Library

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.

One of my favourite tools for testing is Vue Testing Library:

test('displays correct text', () => {

  const { getByText } = render(MyComponent);

  getByText(/Fail the test if this text doesn't exist/);

})

It builds on top of vue-test-utils, making it easier to write tests that are closer to how users actually interact with your app.

Users look for specific text, or look for a button to click. They don't look for the nth child of a div with the class .booking-card-container.

Writing tests this way makes them easier to understand, simpler to write, and more robust against changes to your code. Nothing about this test is concerned with the implementation, so it's unlikely to break even under a heavy refactor.

If this idea is new to you, I highly encourage you to read more about the Testing Library guiding principles.



p.s. I also have two courses: Reusable Components and Clean Components

Related Articles