Skip to content
This repository has been archived by the owner on Aug 2, 2024. It is now read-only.

Next Steps

Jump to bottom
Christian Kienle edited this page Mar 4, 2019 · 1 revision

Becoming a better Vue citizen

One major reason why developers love Vue is it's stunning developer experience. Fundamental Vue also wants to be loved. In order to accomplish that, Fundamental Vue must be a good Vue citizen. There are some best practices outlined by Thorsten Lünborg (@Linus_Borg) in a recent talk. Some of those best practices have already been adopted. However some are missing.

🔆 Dynamic Component Names

Our component names are hardcoded. Even though we have prefixed them, we should allow the developer to override component names.

For example:

import FdButton from "@/components/Button/Button.vue";

export default const install = (Vue, options = {}) => {
  Vue.component(options.ButtonName  || "FdButton", FdButton)
}

export { FdButton }

Relevant Issues:

🚗 Automatic Installation

If someone is using Fundamental Vue by importing it into HTML, a manual step is required in order to be able to use Fundamental Vue.

<script>
  Vue.use(FundamentalVue);
</script>

Wouldn't it be great for this to happen automatically?

Page 41 of Thorsten's slides shows how to accomplish that.

Rationale: It is very important that Fundamental Vue just works. Every additional step that has to be done can be forgotten and cause frustration.

Relevant Issues:

🌳 Enable Tree Shaking

Fundamental Vue will grow as time goes on. At some point you don't want to include everything Fundamental Vue has to offer. This means that tree shaking becomes more relvant every day.

Tree shaking is a term commonly used in the JavaScript context for dead-code elimination.

Source: Webpack: Tree Shaking

Adopting tree shaking is not trivial but the basics are also outlined in Thorsten's slides. What could also be a nice source of information is Chris's hello-vue-components project. There has also been a test with tree shaking in a Typescript-based Vue project.

Relevant Issues:

🎰 More Slots

We want Fundamental Vue to be more customizable. One important step towards that goal is the introduction of more slots. However there should not be a slot for EVERYTHING. Slots should be available where it makes sense. This has to be decided on a case by case basis. Here are some basic guidelines:

  • If a component renders elements that have no Fundamental-specific CSS class it is a good candiate for a slot. For example FdShellBarLogo renders a vanilla <img>-element. This should actually be the fallback content in case no corresponding slot has been provided.
  • If a component has a String-prop that is rendered as plain text there should probably be a slot with the same name. Pseudocode:
<template>
  <div class="myclass">
    <slot name="productName">
      {{productName}}
    </slot>
  </div>
</template>
export default {
  props: { productName: String }
}
  • Obviously there should not be a slot for things that we want to tightly control.

Relevant Issues:

🐛 More Unit Tests

Tests are extremely important for component libraries. Developers depend on Fundamental Vue and in the worst case a bug costs a lot of money in production. But even just being blocked by a bug in one of your dependencies can make you feel sad.

Ramona has created a nice overview where we need tests the most.

Relvant Issues:

Clone this wiki locally