DEV Community: timothyokooboh

What I Learned From Building A UI Components Library For Legacy And Modern Vue.js Applications

timothyokooboh — Tue, 24 Jun 2025 05:54:58 +0000

I had the pleasure of leading a team of frontend engineers to build an internal library of reusable and accessible UI components based on our design system. We had to implement over 40 UI components and each needed to meet acceptable standards for accessibility, reusability, and maintenance. The UI library needed to cater to the needs of both legacy products that are based on Vue 2 and more recent products that are based on Vue 3.

In this article, I would like to share the lessons I learned from that experience and the decisions and tradeoffs we had to make. Here is a summary of the lessons I learned from building an internal library of design system components:

Build on top of open-source, headless UI libraries when you can.
Prioritize web accessibility.
Be guided by a set of software engineering best practices.
Define and document a component’s architecture before development.
Test components in real-world usage, not just in isolation.
Create well-written documentation for developers on how to use the new UI library.

Now let’s get into the details!

Build on top of open-source, headless UI libraries when you can.

Building design system components is not an easy task, especially when you consider accessibility requirements and some edge cases in functionality. This is why building on top of open-source libraries that have taken care of important aspects, such as functionality and accessibility, would be a great way to start. Popular libraries such as Radix UI, Headless UI, and PrimeVue are top of the list, at least in the Vue ecosystem. These libraries provide ways to customize the theme and styles of components using your brand colors, typography, etc., and get accessibility and functionality for free.

However, my team and I did not build on top of a headless UI library. Instead, we built the components from scratch. One thing that all popular and actively maintained open-source headless UI libraries, such as Radix-UI, Headlessui, and PrimeVue, have in common is that they only support Vue 3. They don’t support Vue 2.

I pointed out earlier that some of our products are legacy systems based on Vue 2. So to address this challenge, we first built components in Vue 2 to support the legacy apps, then created a Vue 3 version of the same component to support the Vue 3 apps, ensuring that both variants share the same API. This consistency in API made it easy to write one documentation that supports both the Vue 2 and Vue 3 variants of the same component. Also, since engineers can be rotated across different product teams, consistency in API ensures that engineers don’t have to learn a new API when working on a product that uses the Vue 3 or Vue 2 components, which is great for developer experience.

JavaScript libraries such as floating-ui and tippy.js were very helpful in building components such as tooltips, popovers, and dropdowns. Packages such as tabbable and focus-trap-vue were helpful in implementing a keyboard-accessible modal.

Building on top of an open-source headless library would have been a great choice. However, in software engineering, it’s important to understand fundamentals and learn how things work under the hood so that you can still get the job done when there is a good reason to build from scratch.

In hindsight, probably a much better approach would have been to develop the component library as web components by leveraging frameworks such as Lit Elements or Stencil.js. That way, instead of maintaining two variants of the same component, we would only have one library of web components that can be used across products irrespective of the JavaScript framework the products are built with. From my experience, components built with Vue.js or React.js make it easy to craft a better developer experience compared to web components. However, software engineering is mostly about trade-offs, and by allocating more time for development, it’s possible to build a robust UI library of web components that can serve the needs of enterprise applications.

Prioritize web accessibility.

In addition to writing semantic HTML, one of the easiest ways to build an accessible application is to ensure that the UI building blocks are accessible. This is why accessibility is at the core of any open-source UI library. If an open-source UI library does not prioritize accessibility, the web community will frown at it. This is why Figma sites have been getting a lot of criticisms related to accessibility violations. Despite how important and challenging building complex accessible experiences can be, you get accessibility for free if you leverage standard open-source UI libraries, as mentioned earlier.

Since we built our components from scratch, that made implementing accessibility even more challenging and interesting. To help my team get accessibility right, I shared this resource that contains accessibility guidelines for building many design system components.

Also, courses on frontend masters related to accessibility were very helpful. If you are interested, check out Enterprise Web App Accessibility and Web Accessibility, v3.

You can leverage arc toolkit chrome extension to perform accessibility testing. You can press CMD + Shift + C on a Mac or Ctrl + Shift + C on Windows to quickly inspect accessibility properties of an element.

The takeaway is that when building UI components, prioritise accessibility, not just aesthetics. The web community rewards what works for all, not just what looks good.

Be guided by a set of software engineering best practices.

When building a project, it's necessary for the codebase to be guided by a set of software engineering best practices. Below are some of the guiding principles I emphasised before we commenced development.

Atomic design: Components were designed in a modular, reusable fashion, breaking down complex components into smaller, manageable building blocks. For instance, below is a sample usage of our Tabs component.


<SfeTabs default-tab="tab1" variant="shadowButton">
  <SfeTabList>
      <SfeTabTrigger value="tab1">Tab 1</SfeTabTrigger>
      <SfeTabTrigger value="tab2">Tab 2</SfeTabTrigger>
      <SfeTabTrigger value="tab3">Tab 3</SfeTabTrigger>
  </SfeTabList>

  <SfeTabContent value="tab1">
      <p>Content for Tab 1</p>
  </SfeTabContent>
  <SfeTabContent value="tab2">
      <p>Content for Tab 2</p>
  </SfeTabContent>
  <SfeTabContent value="tab3">
      <p>Content for Tab 3</p>
  </SfeTabContent>
</SfeTabs>

I spent time going through Chakra UI and Shadcn to get inspiration on how to compose complex components. Vue’s provide/inject played a critical role in allowing us to break down components such as Tabs, Accordion, Breadcrumb, Dropdown, etc., into a set of related, tightly coupled components.

Single responsibility principle: Each component had a clear, focused responsibility, ensuring clean and maintainable code.
Reusability: Components were built to be reused across different projects and contexts, reducing redundancy and effort. I recommend this course by Michael Thiessen on reusable components.
Declarative programming: We focused on describing what the UI should look like rather than how to build it, making the code easier to reason about and understand.

Define and document a component’s architecture before development.

Before developing a new component myself or assigning a task to an engineer, I documented the component’s architecture on Notion to specify its usage, props, slots, custom events, and accessibility criteria. It made development easier, as my team and I could discuss about a component’s API and make necessary adjustments before development.

For example, this is a section of a draft of the Select component architecture

Test components in real-world usage, not just in isolation.

One of the lessons I learned the hard way was the importance of testing components both in isolation and in real-world usage to see how a component integrates with other components.

For example, in a real-world application, the Select component will be used inside a form alongside other components such as Input, Checkbox, Radio buttons, etc. While each of these components should be tested in isolation, they should also be tested in the context of how they will be used together in production.

Testing the Select component in isolation would be fine. But testing it inside a form can let you know if the component works well with form validation rules. For instance, does clicking the submit button trigger an error state on the Select component if no option has been selected from its dropdown menu despite the validation rule specifying that at least one option must be selected?

Also, testing the Select component inside a modal can help you test that its dropdown menu is not confined to the height of the modal.

Testing in isolation reveals bugs; testing in integration reveals design flaws. So it’s important to test in both contexts.

Create well-written documentation for developers on how to use the new UI library.

Creating well-written documentation is as important as developing the components. Engineers should not have to study the source code just to learn how to use your components.

To improve adoption and developer experience, we created documentation that showcased example usage of each component. We also created an API reference section for each component, highlighting its props, slots, and events. We were able to create one documentation since both the Vue 2 and Vue 3 variants of each component exposed the same API.

I used prism.js to create a basic syntax highlighting component and copy-to-clipboard to implement a ‘copy code to clipboard’ functionality.


/*
  Takes the 'language' and 'code' props and returns the same code with syntax higlighting, with support for HTML (markup), JavaScript and CSS.
*/
highlightCode() {
 if(this.language === 'markup') {
    return Prism.highlight(this.code, Prism.languages.markup, 'markup');
  } else if(this.language === 'javascript') {
    return Prism.highlight(this.code, Prism.languages.javascript, 'javascript');
  } 
  return Prism.highlight(this.code, Prism.languages.css, 'css');

Conclusion

Leading development of 40+ reusable and accessible components for use across both legacy and modern codebases was a demanding and rewarding experience. At the core of our decisions were accessibility and developer experience. Prioritizing accessibility from day one, treating documentation as a first-class deliverable, testing components both in terms of isolation and integration , and maintaining a unified API across both the Vue 2 and Vue 3 components were critical to the success of the project.

Six Factors That Raise The Risk Of Bugs In A Codebase

timothyokooboh — Mon, 04 Mar 2024 06:58:42 +0000

As a frontend developer, I've come across several key factors that greatly impact the presence of bugs in a codebase. While my insights are based on JavaScript applications, these principles are relevant across different codebases. Let's explore them together.

1. Lack of Static Code Analysis
Static code analysis tools like TypeScript and ESLint play a crucial role in identifying and preventing bugs. TypeScript provides static typing, enhancing the robustness of the code. ESLint detects issues and enforces coding standards. The absence of these tools can significantly elevate the likelihood of bugs due to the lack of early detection and guidance provided during development.

// Example of TypeScript usage
// Define a function with static typing
function greet(name: string): string {
  return 'Hello, ' + name;
}

2. Lack of Automated Testing
Codebases devoid of automated tests, such as unit and end-to-end tests, are at risk of too many bugs. Without automated tests, the detection of regressions and bugs relies heavily on manual testing, leaving room for oversight and undetected issues. Consequently, developers may hesitate to introduce changes or refactor existing code, fearing unintended consequences. When working on a codebase that lacks automated tests, it becomes really hard to ship new features with confidence.

// sample unit test with jest
test('adds 1 + 2 to equal 3', () => {
  expect(sum(1, 2)).toBe(3);
});

// sample end to end test with playwright
test.describe("porfolio page", () => {
  test.beforeEach(async ({ page }) => {
    await page.goto("/portfolio");
  });

 test("can view the tech jobs project", async ({ page }) => {
    await page.getByTestId("techjobs").click();
    await expect(page).toHaveURL("http://localhost:3000/portfolio/techjobs");
});
)

3. Lack of a Continuous Integration Build Process
Codebases lacking a continuous integration (CI) build process miss out on automated checks for production readiness, code quality, and test coverage. Without CI, discrepancies between developer environments and the production environment may lead to undetected bugs surfacing in production. Depending on where your code repository is located, you can setup a CI workflow using GitHub Actions, Bitbucket Pipelines, Gitlab CI etc.

Example of a GitHub Action workflow that checks the formatting of files, builds for production, checks linting and runs test cases

name: CI

on:
  push:
    branches:
      - develop
      - master

  pull_request:
    branches:
      - develop
      - master

jobs:
  actions:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: cache dependencies
        uses: actions/setup-node@v3
        with:
          node-version: 18
          cache: yarn

      - name: install dependencies
        run: yarn

      - name: check formatting of files
        run: yarn format:check

      - name: build for production
        run: yarn build

      - name: check linting of files
        run: yarn lint

      - name: run unit tests
        run: yarn test:unit

4. Misleading Variable or Function Names
A variable or function is considered misleading if its name does not accurately reflect its functionality. This discrepancy can lead to bugs when developers rely on the function's name to guide their implementation logic. For instance, consider the function isLoggedIn. One would expect it to return true if a user is logged in and false otherwise. However, imagine if the function returns a user object when a user is logged in and null otherwise. While a user object is a truthy value and null is a falsy value, such discrepancies in return types can result in unintended bugs.

// Better
const isLoggedIn = () => auth.currentUser ? true : false;
OR
const isLoggedIn = () => !!auth.currentUser;

// Misleading
const isLoggedIn = () => auth.currentUser ? auth.currentUser : null;

5. Multiple Sources of Truth for the Same State
Having multiple sources of truth for the same state can lead to bugs that are hard to trace or debug. It introduces inconsistency and confusion into the codebase, making it difficult to maintain and debug issues. Consider the example below

// Vue.js

<template>
 <input type="text" v-model="loanBalance">
</template>

<script setup lang="ts">
const loanBalance = ref<number>(0)

const getLoanBalance = async (userId: string) => {
 const response = await axios.get(`/loans/users/${userId}`)
 loanBalance.value = response.data.data;
}

const updateLoanBalance = (balance: number) => loanBalance.value = balance
</script>

The component above has three sources of truth for the state loanBalance: the input field (two-way data binding), the getLoanBalance function, and the updateLoanBalance function. When a state is modified in many places, such multiple side effects can lead to bugs that are hard to trace and debug.

6. Redundant States
A component contains redundant states if the same value is stored in more than one state. This becomes problematic if you have to manually keep track of the states and ensure they contain the same value.

// Vue.js

interface Notification {
 subscribers: string[];
 message: string
}

 const notification = ref<Notification>(
 { 
   subscribers: [],
   message: ''
 }
)

const subscribers = ref<string[]>([])

const getNotification = async () => {
 const response = await axios.get('/notifications')
 notification.value = response.data.data;
 subscribers.value = notification.value.subscribers
}

In the example above, the list of subscribers is contained in both the notification state and the subscribers state. Having to manually ensure that both states contain the same value can lead to bugs.

However, if subscribers need to be accessed across multiple places in the component, it is much better to use a computed property to ensure that you don't have to manually synchronize the values.

 // Vue.js
const notification = ref<Notification>(
 { 
   subscribers: [],
   message: ''
 }
)

const subscribers = computed(() => notification.subscribers))

// React
const [notification, setNotification] = useState({})

const subscribers = useMemo(() => {
  return notification.subscribers
 }, [notification.subscribers]
)

In conclusion, the pursuit of bug-free code is an ongoing endeavor. Throughout this article, we've explored six key factors that contribute to the proliferation of bugs within a codebase. From the absence of static code analysis and automated testing infrastructure to the presence of misleading variable names and duplicate states, each factor presents its own set of challenges and risks. By acknowledging these factors and implementing strategies to mitigate their impact, developers can strive towards building more robust and resilient software applications.

Seven Lessons I Have Learned From My Experience as a Software Developer

timothyokooboh — Mon, 06 Mar 2023 18:59:01 +0000

I decided to change career from pharmacy to software engineering in 2018, which has changed my life forever. Since that time, I've had the chance to work on a range of projects, either independently or as a member of a cross-functional team.

Despite the fact that I have not been around for a very long time, I have discovered and seen a few factors that consistently lead to positive outcomes. I have also noticed the actions that don't result in the desired results.

I'll thus be sharing some lessons I've learned from my time spent working as a frontend engineer. These are my opinions. The ideas I present in this post have been shown to yield positive outcomes. I'd be interested to hear your opinions if you disagree with any of them, though. This article aims to impart some important lessons I've discovered that might be useful to others. I will therefore be glad to benefit from your experiences as well.

Well, with that said, let's get started!

A. If you understand the problem then you are 50% done even before writing the first line of code.

As software developers, our daily work revolves around finding solutions to challenges. Hence, when faced with an issue at work, it can be tempting to want to write code right away and provide answers.

If you are certain that you already comprehend the issue you are trying to tackle, then this is acceptable. But it turns out that this isn't true the majority of the time. Before attempting to write code to address a problem, it is crucial to make sure you have a thorough understanding of the problem and you know what success looks like.

This approach has some advantages such as:

It helps to solve the root cause and not the symptoms of the problem.
It helps to come up with a more robust and maintainable solution.
It prevents you from wasting your time and that of your colleagues
It saves resources in the long run

The most crucial lesson I've learned as a frontend engineer, in my opinion, is to fully comprehend the issue before writing any code!

Reading the technical/product specifications, asking the appropriate team member questions to clear up any confusions, doing internet research on the issue, etc., are all strategies for comprehending the problem you want to solve.

B. Be a team player. It's about institution and not individual.

Being a proficient and dependable software engineer is crucial. But playing well with others is just as crucial!

Being a team player and acting with humility at work go hand in hand. Never assume that because you have a task or feature to work on, it is because you are the most qualified for it. Someone else on your team might be able to perform the task better. Forget the reason why, then. Instead, concentrate on doing your best to provide a high-quality outcome.

To be a good team player, you must also communicate with your teammates, support them, and provide them quick feedback.

C. Consume quality content

Online resources are abundant for learning how to code. These are generally all free. Some of the paid resources are affordable, while others are pricey.

Yet, I've come to understand that quality, not price, should be the deciding factor when selecting a tutorial or course to enroll in.

Some questions to help assess the quality of a content includes:

Who is the author?
How many people have subscribed to the course?
What are the reviews from those who are already taking the course/tutorial?
What is the average rating?
When was the the course published?
When was it last updated?
Does it contain updated syntax, APIs, and concepts?

As a Frontend Engineer, I have found certain platforms and tutors who are known for publishing quality content. They include Frontend Masters, Framework documentation sites (e.g Vue and React), Vue School, Vue Mastery, Scrimba, and courses by Michael Thiessen, Maximilian Schwarzmuller and The Net Ninja.

Of course, the list is not all-inclusive, but you get the idea.

D. Avoid a toxic work culture and a toxic boss!

I won't focus too much on this. But it's vitally significant.

When I'm considering joining a new company, the work culture is the first thing I consider, not the compensation. I'm not sure about you, but I work best in settings that value a healthy work-life balance, a culture of respect for others, and an open-door policy for employees to express their opinions and be creative.

E. The code should be based on the experience of the product. The product should be based on the experience of the user.

The lesson from this point is simple: The development of a software product should be user centric
It's crucial for software developers to code with the user in mind. In this manner, you can develop empathy and be motivated to implement simple and enjoyable user interfaces. Also, you can speak with the product manager or tech lead if you notice that a product or technical requirement won't contribute to making users' lives easier.

F. Testing is not only for QA engineers.

It's crucial to test the code you create. In addition to designing clear and manageable code, testing your code ensures the dependability of the final output.

In light of this, I believe you should write clean code as if you won't test, then test carefully as if you don't trust your code.

G. Take breaks

Taking breaks at intervals can boost productivity. Taking short intermittent breaks as you code can help manage stress and prevent burn out.

I have also noticed that sometimes all you need to figure out the solution to a coding challenge or bug fix is to take a break. You'll be mentally prepared to take on the challenge once more when you return to the code. And occasionally, during your break, you might have an epiphany, after which you can quickly return to your code and succeed in the task at hand 😎

That's it! The seven important lessons I have learned while working as a frontend engineer.

Do you agree or disagree on any of these points? Would you like to share the lessons from your own experience? It will be nice to know what you think.

Thank you for reading 😊

Vue.js: How to maintain atomic design principles when using vendor components

timothyokooboh — Wed, 21 Apr 2021 19:50:06 +0000

In this post, I explain how you can maintain atomic design principles when using UI component libraries such as Vuetify, Quasar, BootstrapVue, Font awesome, etc.

A brief overview of atomic design principles

Atomic design principles were introduced by Brad Frost. He recommends a way of coding up web user interfaces by first breaking them down into the smallest units called atoms. Then organize a group of atoms into molecules which can be reused in organisms. A group of organisms can be put together to form a template (without the real content). And when real content is placed inside templates, you get pages.

For example, let's say you want to create a form component.
By following the atomic design principles, you could have a component for inputs BaseInput.vue. A component for labels BaseLabel.vue. And a button component BaseButton.vue.

Each of these components would constitute your atoms. Then your form component could look like this.

AppForm.vue

The focus of this post is not to deeply explain atomic design principles. To learn more, check out chapter 2 of the book . Also, in this article, Alba Silvente, dives deeper into how you can apply atomic design principles in Vue.js.

Vendor component wrapper design pattern

The vendor component wrapper design pattern can be used to maintain atomic design principles when using component libraries like Vuetify.

It encourages wrapping vendor components (e.g Vuetify, BootstrapVue, Quasar, Font awesome) inside your own custom .vue components.

By the way, I learned about this design pattern from Ben Hong, a Vue.js core team member in this course.

Let's do a comparison of how our code could look like if we are to create a form component with Vuetify without applying this design pattern versus if we apply this design pattern.

Without applying vendor component wrapper design pattern

AppForm.vue

With vendor component wrapper design pattern

With vendor component wrapper design pattern, you will need to create your own .vue components that wrap the individual vuetify component.

BaseInput.vue

BaseButton.vue

For Vue 3.0, no need to add v-on="listeners"

By setting v-bind = "$attrs" and v-on="$listeners", you can pass all the props and attributes specified in the vendor component's API reference to your own .vue components, just as you would have done directly on the vendor components.

Note: If your template has a wrapping container element, e.g a div element, you will need to set inheritAttrs to false

BaseInput.vue

Then our form component will look like this:

AppForm.vue

Advantages of this pattern

(i) By wrapping vendor components inside your own .vue components, you can have finite control over vendor components API and still maintain atomic design principles just as you would have done if you were designing all your UI components with CSS, SCSS, or Tailwind CSS.

(ii) Your components can be flexible enough to switch between displaying vendor components or your own custom-made UI components.

In this example, I can switch between displaying a Vuetify button or display the button I designed myself with CSS

The isVuetify prop can be used to determine which button gets displayed.

You can even extend this methodology to switch between two vendor components e.g Font awesome icons or Material design icons.

That will not be possible if you do not wrap vendor components inside of your own .vue components

Vuex best practices

timothyokooboh — Wed, 14 Apr 2021 18:55:20 +0000

As a Vue.js developer, I have been using Vuex for state management.

Recently, I completed a course on Frontend Masters titled Vuex for intermediate developers. I have also read a couple of useful posts on Vuex written by experienced Vue.js developers.

Therefore, these days when utilizing Vuex in my application, I do my best to follow these patterns/strategies/rules.

A. Always use Mutations to update a value in Vuex state.

Let's say you have something like this in your state:

const state = { age: 20 }

To update the value of age inside any of your Vue components, never do this:

this.$store.state.age = 40;

Instead, write a mutation that will be responsible for updating the state.

You could write something like this:

const mutations = { updateAge(state, payload) { state.age = payload } }

Then in your components, you can do this:

this.$store.commit("updateAge", 40)

We can even extend this example further with the next best practice.

B. Let every mutation be associated with an action. Then dispatch these actions inside of your Vue components.

Most experienced Vue developers propose that components should not directly commit mutations. Instead, every mutation should be associated with an action. Then components should dispatch these actions instead of directly committing mutations.

To demonstrate this concept with our previous example, let's create an action:

const actions = { updateAge({ commit }, payload) { commit("updateAge", payload) }

Then inside our Vue components, we will dispatch the action instead of committing the mutation directly.
this.$store.dispatch("updateAge", 40)

C. Keep asynchronous logic inside actions and NEVER inside mutations

Asynchronous logic such as fetching data from an API call should be carried out inside actions and not inside mutations.

This is because each time a mutation updates the Vuex state, it leaves a before and after snapshot of the Vuex state inside of Vue dev tools. This is very useful in debugging because you can always go back in time to check the initial values in the state before the mutation was committed.

But this unique ability of mutations is lost whenever an asynchronous event is fired inside a mutation. Hence it is best to only perform synchronous tasks inside mutations.

Usually, these synchronous tasks only involve updating the value of the state just like we did before:

state.age = payload

D. Actions and Mutations should not be used outside of their core responsibilities.

Because Vuex actions and mutations are simply javascript functions, sometimes we execute logic that should
not really be done inside either of them.

Each time you commit a mutation, it should do only ONE thing: Update the value of the state.

Each time you dispatch an action, it should do one or more of the following:
(i) Fetch data from an API.
(ii) Commit a mutation.
(iii) Dispatch an action.

Each time you find yourself executing logic that falls outside of these core responsibilities, you should consider extracting that logic inside a Vuex plugin.

Thankfully, Vuex plugins are very easy to write. I will show you how.

Use case
Let's say you dispatched an action that fetched data from an API. Then you committed a mutation and passed the API response as a payload to the mutation. Then inside your mutation, you updated the value of the Vuex state with the payload. And in addition, you want to save some values to local storage.

It's best not to write the logic that saves the values to local storage inside of your mutation or action. Instead, you can write a simple plugin to do just that.

How to write a plugin
Let's create a Vuex plugin to save data in Local storage.

Create a folder called plugins, preferably inside of your Vuex store folder. Then create a file called webStorage.js

export default function saveToLocalStorage(store) { store.subscribe((mutation, state) => { if(mutation.type === 'updateState' ) { const payload = mutation.payload; localStorage.setItem("userId", payload.userId) localStorage.setItem("username", payload.username) } }) }

A Vuex plugin is just a normal javascript function that receives the Vuex store as its only argument.

In the code above, I check if the mutation that was committed is called "updateState". Then I access the payload from the mutation and save the username and userId to local storage.

This logic does not update the Vuex state. Therefore, it's not best practice to place it inside of a mutation.

To use this plugin, we will import it into the Vuex store (index.js file)

store/index.js
import saveToLocalStorage from "plugins/webStorage";

const Store = new Vuex.Store({ plugins: [saveToLocalStorage], state: {}, mutations: {}, actions: {}, getters: {} })

Vuex plugins are really powerful and easy to write. You can use them to create powerful notification systems such as notifying a slack channel whenever a particular mutation or action is executed.

E. Don't write redundant code inside Vuex getters.

The below Vuex getter is not really useful and should not have been written in the first place:

const getters: { getAge(state){ return state.age; } }

It is only returning the value of age. In our components, we can conveniently access the value of age without the help of this getter.
this.$store.state.age

Use getters to compute derived values of the state

But let's say we want to check if age is less than 18. Using a getter to compute this value will be very useful.

const getters: { isUnderAge(state){ return state.age < 18 } }

Then inside of our components, we can conveniently determine if a user is under age by accessing the value of the getter:
this.$store.getters.isUnderAge instead of writing return this.$store.state.age < 18

That's it, guys! ☺️.
Let me know what you think about these tips. And share the best practices you have been applying inside of your Vuex codebase too.

I must add that these best practices will not be complete without a properly organized Vuex folder structure. But that's a topic for another time.

Vue 3.0: Debugging composable functions

timothyokooboh — Sun, 28 Mar 2021 18:29:47 +0000

The composition API is a core feature of Vue 3.0 (though it is also available as a plugin for Vue 2). It provides an alternative syntax for writing Vue.js components. Vue developers are used to the options API where each component may consist of one or more options such as data, computed, watchers, mixins, directives, filters, extends, and lifecycle hooks.

Recently, I have been creating Vue components using the composition API. I must say that it has been an awesome experience. This is because the composition API offers a better and cleaner way of composing reusable code/logic across your Vue application. These reusable codes are commonly referred to as composable functions. You may already be familiar with mixins. Unlike Vue 2 where mixins were mostly used to create and share reusable logic, in Vue 3.0 writing composable functions is the real deal!

The purpose of this article is to share with you two mistakes I have made while writing and using composable functions. And of course, they caused bugs in my app. They may seem quite trivial but these are potential sources of bugs that you should be aware of.

To demonstrate how to avoid these gotchas, let's build a simple login component with two logical concerns: form validation and API consumption.

I used TailwindCSS for the styling. Don't mind the placeholder text "Pharmacy email address". The template code is an excerpt from a project I'm working on 😉

Below is the script section before refactoring the code to use composable functions. As earlier stated, there are two logical concerns: form validation and API consumption.

I used vee-validate to validate the user's inputs. With vee-validate's useField method, I created email and password fields which are connected to the template via v-model.
With the help of vee-validate's useForm method, I validated the email field to ensure that it is required and is a valid email address. The password must be at least 8 characters long.

Now, let's refactor the code to use composable functions!. To do so, let's separate each logical concern into its own file.

For this demo, I placed the validation logic into it's own file.
demo-validation.js

For this demo, I placed the login API call into it's own file.
demo-login.js

Now, let's make use of these composable functions. To do so, we just have to import them into the component and destructure the values that were returned from the composable functions.

Simple right? 😀

Mistakes to avoid

Here are two mistakes you should always avoid:

a. After importing your composable functions into the component, Don't forget to invoke them inside the setup function. It's not enough to destructure returned values from the composable functions. You must also add brackets after the functions

const {
email,
emailErrorMessage,
password,
passwordErrorMessage
} = FormValidation ()

b. When passing arguments to a composable function inside setup, don't add the "value" key.

DO THIS
const {
loginUser
} = Login(email, password)

INSTEAD OF
const {
loginUser
} = Login(email.value, password.value)

But to use the arguments inside of the composable function file, you must use the value key

demo-login.js

DO THIS

const user = await axios.post("/api/users", {
email: email.value,
password: password.value
})

INSTEAD OF

const user = await axios.post("/api/users", {
email: email,
password: password
})

That's it, guys! Leave any comments or questions below. Thanks for reading ☺️

5 CSS Properties You Probably Did Not Know About

timothyokooboh — Sat, 19 Sep 2020 15:23:08 +0000

I have been studying a lot of new CSS properties in order to up my game as a frontend developer.

I am fascinated by the new CSS properties I have come across and utilized in my recent projects. Therefore, I am going to share 5 CSS properties you probably didn't know about.

1. @media (hover: none) or @media(hover: hover)
How do you know if users are viewing your web application with a touch-screen device (e.g mobile phones) or a non-touch-screen device (e.g desktop/laptop)?

You can determine this by using the media query above.

This is important because some CSS properties like hover may not be so important when applied to touch screen devices. The hover effect is not so obvious on touch screen devices.

@media all and(hover: none) {
apply styles for touch screen devices e.g mobile phones
}

@media all and(hover: hover) {
apply styles for non-touch-screen devices
}

The CSS property in the codepen below will only apply on non-touch-screen devices when users hover on the text. Therefore, if you are viewing this on your mobile phone, the hover effect will not work.

2. selection pseudo-class
The selection pseudo-class lets you define custom colors and background colors that appear when users try to copy texts on your web applications.

3. hyphens
By setting the hyphens property to auto, texts on your webpages will be automatically hyphenated.

In the codepen below, try resizing the browser and see hyphens automatically apply to the texts

4. background-clip
When set to text, the background-clip property is useful for creating linear-gradients on texts.
However, to work on the chrome browser, you need to add the -webkit prefix.

5 @supports
This is a very useful CSS property. It lets you set styles that should only apply when a browser supports a CSS property.

In the codepen below, the @supports property will ensure that the backdrop-filter CSS property will only be applied on browsers that support the property. Hence, if you view the webpage with a browser that doesn't support the property e.g firefox, then the backdrop-filter won't be applied. You will need to set up a default property that should apply. In this case, I used background-color as the fallback property.

Click the button to view the modal

And that's it!

If you find any of these CSS properties interesting, please leave a comment below. I'd also love to learn about new CSS properties that you have come across lately.

Thanks for reading.

Understanding Watchers in Vue.js

timothyokooboh — Sat, 11 Jul 2020 15:51:42 +0000

In this article, we will take a deep dive into one of the core concepts in Vue.js -- watchers.

We will start from scratch and look at what watchers are and then we will go further to look at two properties available within a watcher: deep and handler.

We will end the lesson by building a simple project where we will connect to an API endpoint and fetch data to our webpage. Of course, we will use watchers to get the job done.

Lets's get started

Open your text editor to code along. I will be using visual studio code.
Let's begin with the following HTML markup.

Then, head over here to get the Vue.js CDN

I have included the Vue.js CDN on the project. To test if everything is working fine, I added a property called msg in the data object and outputted it on the DOM. Now go to your browser, you should see hello timothy printed on the webpage.

Understanding Watchers

In addition to the data object, the Vue instance accepts other properties such as methods, computed properties, watch, filters, and life cycle hooks such as mounted.

As the name implies, watchers watch for changes in the value of a property that we have already defined in our data object, and does something whenever the value of that property changes. They can also watch for changes in the value of a computed property, and do something whenever the value changes.

Let's see how it works

I have added a button to the DOM and attached a method to it called changeName which gets executed whenever the button is clicked. Below the button, there is an empty div that has a ref attribute with a value of name. The ref attribute will be used to access this div inside of the Vue instance instead of using traditional javascript methods like getElementById.

As you can see, when the button gets clicked, the name changes from Timothy Okooboh to Julie Peterson

The next thing we will do is to watch for this change and make something happen whenever the value of name changes.

So what is happening here?
We added a watch object to the Vue instance. Then we gave it a property called name which happens to be a function. Within this function, we listened for changes in the value of the name property defined inside of the data object. When a change occurs, we set the innerHTML of the div that has a ref value of name.

There is one major thing you MUST take note of. The name property within the watch object MUST BE CALLED name and nothing else. Why? you may ask. Well, that is because we are watching for changes in the value of name. If we had an email property within the data object and wanted to watch for it, then we would have called the watcher email and nothing else.

Also, the watcher takes two parameters, the first is the new value of the property we are watching. The second parameter is the old value of the property we are watching.

Understanding the handler method

In our code above, the watcher name was declared as a function. But it can actually be declared as an object. When declared as an object, the watcher can take three properties namely a handler function, and two booleans deep and immediate. For the sake of this article, we will focus on the handler function and deep.

As you can see in the code above, the handler function basically holds the logic that should get executed whenever the value of the property that we are watching for changes.

Head over to your browser, you should still see that the code works as before.

What about deep?
If you understand deep, then your knowledge of watchers will be on a new level.

Basically, you use deep when watching for changes in the value of items inside an array, or changes in the value of properties inside an object. You will need to set deep to true in order to tell Vue.js to inspect the contents of arrays and objects.

Let's see how it works

Before I explain what is going on, let's see the Vue instance.

We have an array called fruits. Then we take the value of the user's input and use it to replace the first item in the array. We then watch for this change and try to render "the first fruit has changed" to the DOM

As you can see, we successfully changed the value of the first item in the array but the action inside the watcher failed to execute. This can be solved by setting deep to true like so

Now if you view it on your browser, you will see that Vue.js can now inspect our array and execute the action stated in our watcher.

Finally, let's build a simple project

We are going to connect to the yes/no API. The way it will work is that our users will type a question inside an input field. Then we will watch for changes in the value of the input field and send a GET request to the API endpoint. Then we will display the result on the webpage. But before sending the request, we will execute a simple validation -- we will check if the user's question ends with a question mark.

Enough of the talk. Let's see how it works.

We will use axios for sending the http request. Head over here to get the axios CDN

This is the template markup

This is the data object

This is the method that will send the GET request**

Then this is our watcher

Our watcher first validates the user's request to check if it ends with a question mark. If the validation passes, it calls the getResult method after 5 seconds.

THANKS FOR READING. I hope that you learned something. Kindly leave your comments/questions below.

HOW TO BECOME A BETTER Vue.js DEVELOPER

timothyokooboh — Thu, 09 Jul 2020 13:01:49 +0000

Hello devs! I want to share some things that I believe can make anyone to level up as a Vue.js developer.

Few hours ago, I deployed a simple e-commerce web app which I made by using Vue on the frontend and node.js/express on the backend.

Having worked with Vue for a while, I feel I should share some tips with you.

If you are reading this, it's either you are already working with Vue.js professionally, you just started learning Vue.js, or you are considering learning the framework.

Whichever category you belong to, I'm sure that you will still find this piece useful.

What exactly is Vue.js?

For the sake of newbies, Vue.js is a JavaScript framework just like React and Angular. It focuses on the view layer (what the users of your application can see and interact with). Hence, it can be used to create powerful user interfaces.

One of the most exciting things about this JavaScript framework is that it is very easy to learn and get started with compared to Angular or React. So within a couple of hours or days of learning Vue, you can start to create amazing web apps by just dropping the Vue.js cdn on your application.

Anyways, without wasting much time, let's dive into the things that can make you a better Vue.js developer. 🤩

1 Let the documentation be your friend. READ IT!

The Vue.js documentation is one of the best documentations you can ever come across. It's nicely written, well explained and has lots of examples.

You can literally learn any Vue concept by just reading through the documentation. While building the e-commerce app, I always referred back to the documentation whenever I got stuck.

So in addition to the tutorial you may have paid for, do well to regularly check out the docs.

2 Build projects

This tip can not be over emphasized.You need to start applying your knowledge of Vue to build projects. Begin with the Vue cdn. Don't wait till you begin to use the cli. You may not appreciate the cli and maximize its benefits unless you have built something with the cdn.

Your first Vue app, doesn't have to be awesome. But as you progress in your learning path, you will naturally begin to build awesome Vue apps 🌟🌟

3
Learn Vuetify

Is Vue.js not enough? Of course it is enough, especially when combined with your knowledge of CSS or SASS or Bootstrap or Tailwind CSS.

So why learn Vuetify?

Vuetify is a material design UI library specifically suited for Vue applications. It has built-in components such as cards, skeleton loaders, dialog box, datatables, buttons, carousel and a bunch of cool UI components that help you to build beautiful Vue apps faster.

The cool thing is that Vuetify is written in Vue.js which makes getting started with it very easy.

4 Learn Nuxt.js

Yes, you got that right! The learning never stops.

If you are coming from a React background, Nuxt.js is to Vue.js what Next.js is to React.

My favorite coding tutor, Max, tagged his Nuxt.js Udemy course as Vue.js on steroids 😃

You think vue.js is easy to work with? Then try out Nuxt.js. Nuxt.js further simplifies the development process of making Vue applications while adding extra capabilities such as server side rendering which undoubtedly improves the SEO of vue.js applications.

So after gaining a mastery of vue.js concepts, learn Nuxt.js.

5 Build projects

Oops! We've said that before.🤔.

Yes, it's intentional! I can't stress this enough. You have to keep using your knowledge of Vue.js to build innovative solutions and make our world a better place.

By so doing, you will become a better Vue.js developer.

THANK YOU ❤️.

How To Add Speech Functionality To Your App

timothyokooboh — Thu, 23 Apr 2020 10:02:21 +0000

In this article, I will show you how to add speech functionality to your applications.

I recently made a simple dictionary app with vue.js using the owlbot-js API. so I needed users to listen to the correct pronunciation of the words. I used the technique am about to show you and it took less than a minute to add speech functionality to my dictionary app.

P.S: On my android phone, I sometimes experience some delay before the voice note begins. But on my laptop, there is never a delay.

So let's begin!

I'm gonna embed a code pen.

First, we initialize the built-in speech synthesis API

const speech = window.speechSynthesis;

Then, we access the DOM to select the text we want to get spoken.

const text = document.querySelector("#text"). innerHTML;

The speech synthesis API has a constructor called SpeechSynthesisUtterance. This constructor receives one argument which is the text we want to get spoken. In our code, this argument is the same as the text variable we declared.

const utterance = new SpeechSynthesisUtterance(text)

So, we created a variable called utterance and assigned it the SpeechUtterance constructor

function sayTheWords(){
speech.speak(utterance);
}

Finally, when our button is clicked, we call the built-in speak method on the speech synthesis API. The built-in speak method receives one argument, which is the utterance variable we declared.

So that's how you can add speech functionality to your app.

You can think of several use cases where this functionality may be useful in your app. For instance, apart from displaying flash messages when a user creates, edits, or deletes a post, you could also send a voice message.

To learn more about the speech synthesis API, you can check out this video by Brad Traversy

He went further to explain how you could select the particular voice, pitch, and even the rate at which the voice note is spoken.

DEV Community: timothyokooboh

What I Learned From Building A UI Components Library For Legacy And Modern Vue.js Applications

Build on top of open-source, headless UI libraries when you can.

Prioritize web accessibility.

Be guided by a set of software engineering best practices.

Define and document a component’s architecture before development.

Test components in real-world usage, not just in isolation.

Create well-written documentation for developers on how to use the new UI library.

Conclusion

Six Factors That Raise The Risk Of Bugs In A Codebase

Seven Lessons I Have Learned From My Experience as a Software Developer

Vue.js: How to maintain atomic design principles when using vendor components

A brief overview of atomic design principles

AppForm.vue

Vendor component wrapper design pattern

Without applying vendor component wrapper design pattern

With vendor component wrapper design pattern

BaseInput.vue

BaseButton.vue

BaseInput.vue

AppForm.vue

Advantages of this pattern

Vuex best practices

Vue 3.0: Debugging composable functions

5 CSS Properties You Probably Did Not Know About

Understanding Watchers in Vue.js

Understanding Watchers

Understanding the handler method

Finally, let's build a simple project

HOW TO BECOME A BETTER Vue.js DEVELOPER

What exactly is Vue.js?

How To Add Speech Functionality To Your App

So let's begin!

So that's how you can add speech functionality to your app.

Thanks for reading.

Simple Dynamic Quiz With Vue js

Rendering lists with progress bar in Vue JS.