DEV Community: Mr_SC

Introducing v-memo a new directive to improve your Vue 3 app performance

Mr_SC — Wed, 24 Aug 2022 22:06:00 +0000

Vue 3 has provided us with several significant performance improvements out of the box but has also introduced some extra manual features that can help up improve our app performance.

In this article, we are going to discuss a new directive called v-memo. This directive has been introduced in Vue 3.2 and to the best of my knowledge, it is not going to be available in Vue 2. The aim of this directive is to help you improve the performance of your medium / large Vue application and it is not intended to be used in small applications.

What does `v-memo` do?

The definition of v-memo is:

v-memo is used to memoize a sub-tree of a component in relation to a fixed set of dependencies values. The sub-tree will delay all future updates until one of the dependencies values changes.

What is v-memo

Even if the above sentence may seem scary, in reality, things are quite simple to understand. What v-memo does is the same that already happens with our computed properties, but just applied to part of the DOM.

This new directive will cache the part of the DOM it controls, and just run an update and re-render it if a specific value changes. These values are manually set by the developers.

A basic example of `v-memo`

Examples are always the best way to understand new technologies, so let’s jump right in and provide a small example to start and see the syntax and usage of this directive:

<template>
  <div>
    ..the rest of the component
    <div v-memo="[myValue]">
      <svg >
        <title>{{MyValue}}</title>
        ...
      </svg>
      <vue-custom-element :value="myValue"></vue-custom-element>
    </div>
  </div>
</template>

Let’s see in detail what the above achieves:

...the rest of the component

The first line that needs explanation is the fact that v-memo is usually meant to be used as part of a component and it should just affect a subset of the component dom. So in this example, we expect the component to actually be bigger than what I just pasted above.

<div v-memo="[myValue]">

Next, we have assigned our v-memo to a specific DIV and all its children elements. When calling v-memo we have to pass an array of values that are going to control the rendering of the sub-tree.

The array accepts one of more values v-memo="[valueOne, valueTwo]” and also expressions like v-memo="myValue === true".

Note: Calling v-memo with an empty array would be the equivalent of using v-once and will render that part of the component just once.

<svg >
  <title>{{MyValue}}</title>
  ...
</svg>
<vue-custom-element :value="myValue"></vue-custom-element>

It is now time to focus on the content of our sub-tree. In my example, I have used a native element “SVG” and a custom Vue element “vue-custom-element”. I have done this to highlight the fact that the HTML included in v-memo can be absolutely anything.

When our inner HTML is a native element (div, SVG, button, form), using v-memo would just be useful when used on very large datasets (like large tables) and or very complex nested DOM, like in the case of a dynamic SVG.

While, using v-memo on a custom component is not only going to stop the rendering of HTML, but it is actually going to actually stop the reactive update of Vue components too (watch, computed, etc..). When used with Vue custom element, v-memo can be very useful for situations in which the rendering of the child component is very costly and we are able to “defer” its update to specific scenarios.

Few examples

This section is going to include a couple of quick examples to provide more context and help understand when this feature would really be useful.

I would like to emphasise that this feature is for advanced users and should just be used for complex applications where small performance improvements are really important.

The wrong case

I am going to start by writing when the use of v-memo is actually incorrect and will not provide any performance advantages.

<div v-memo="[myValue]">
  <p>Static content, no vue values here</p>
</div>

In the above example, the sub-tree included within v-memo does not need to be memorized as it is actually static and will not change (it does not include any Vue variable). The Vue 3 virtual DOM management is able to automatically understand which part of the DOM is static and which one is not.

Adding the v-memo on a static HTML is not going to be useful, no matter how complex the HTML is.

Managing updates

There are cases in which v-memo could be used not only to improve performance but to actually improve the UX (user experience), by controlling the update cycle of the component.

<div v-memo="[allFieldChanged]">
  <p>{{ field1 }}</p>
  <p>{{ field2 }}</p>
  <p>{{ field3 }}</p>
  <p>{{ field4 }}</p>
</div>

In the above example changing an individual field, for example, field1 is not going to result in a re-render. In fact, the new fields will just be shown when all fields have been updated.

I had a situation recently where a child component would update and react to a large JSON dataset. In that case, using v-memo really helped to just trigger the update when all the changes were completed.

Use it in conjunction with v-for

One of the most common use case for using v-memo is when dealing with very large lists rendered using v-for.

<div v-for="item in list" :key="item.id" v-memo="[item.id === selected]">
  <p>ID: {{ item.id }} - selected: {{ item.id === selected }}</p>
  <p>...more child nodes</p>
</div>

In the above example that has been taken directly from the Vue documentation, we see the v-for / v-memo syntax in practice.

Without the use of v-memo in the code above, each change of the “selected” variable would have resulted in a full re-render of the list. The memorization provided by the new directive, allows the framework to just update the rows in which the expression item.id === selected has changes, therefore when an item is selected or unselected.

If we consider a list with 1000 entries. Using v-memo with the above code, would save use the evaluation and re-rendering of 998 entries for each change! Not bad!

Inadvertently stop the child component to trigger updates

The last example is an edge case that I have encountered recently. In most of this article we have emphasises the fact that v-memo will stop the sub-tree from rendering an update, but what is important to realize, is that using this directive will actually stop the execution of any code that may be triggered with an update.

Let’s take the following example:

<div v-memo="[points > 1000]">
  <myComponent :points="points" />
</div>

//myComponent
<isLevel1 v-if="points <= 1000">....</isLevel1>
<isLevel2 v-if="points > 1000">...</isLevel2>
<script>
...,
watch: {
  points() {
    logPointChange();
  }
}

If we assume the inner component “isLevel1” and “isLevel2” to be complex, avoiding their rendering using v-memo seems like a good idea. Unfortunately avoiding re-rendering will also avoid the running of any code within the myComponent. What this means in our example is that the watch registered on the property “points” is not going to run unless the variable “points” changes between the level threshold.

This problem is quite easy to solve, as all we need to do is move the log method to our parent, but it is important to remember that execution is completely truncated by the use of v-memo.

Summary

This new directive is very powerful and with great power comes great responsibility. The use of it should really be the last option in the case in which performance is key and we are working on a large application.

As I will encounter more examples I will come back and expand this post to hopefully help people to really understand how to use this feature (and when not to), but I also urge you guys to suggest other examples or scenarios in the comments below to help future readers.

The importance of vacation for your career

Mr_SC — Mon, 22 Aug 2022 08:22:59 +0000

If you follow me on Twitter you will probably be aware that I am currently in Italy spending my summer vacation with family and friends. In today’s article I am going to share my experience with time off, and the importance of it for your mind and your career.

I am writing this article because I want to change the conception that vacation is not actually something that company likes. We are going to see some real data and cover a few points that will share the importance of time off for both employers and employees.

What is stopping you to go on holiday?

We are going to cover these facts with data later in the article. What I have noticed in my career is that people seem to start and use less and less of their vacation as they progress in their careers.

What this means is that a simple junior developer may still take time off during his birthday to celebrate with friends and family, while a manager or an architect will just take the strictly necessary, and just make long weekends here and there.

What is interesting to note, is that in many occurrences, this was not actually defined by a difference in benefit or a need from the company itself, but it was actually self-inflicted. What I mean by self-inflicted is that the employee is purposely missing out on holiday for two main reasons “fear of not being needed on return” or “Everything will fall apart in my absence”.

This trait is more common in North American countries, but also common in big corporate where big position requires big responsibility. Unfortunately, I am going actually to oppose both of the above reasons.

Everything will fall apart in my absence

You are a manager, you look after projects and teams, how can you ever think to leave the business for even just a week? Who will sail the boat without the captain? Well.. It will continue its course with or without you! 🙂

A long time ago, I was lucky to have a great manager, one that helped me understand fully how things worked. During one of my mentoring sessions, I was discussing the above with him and trying to express how much pressure I felt as “everything was on my shoulder”, his answer was not what I expected.

Even if I very important, and this manager really likes and supported me, his answer was:

Simone remember that everyone is important, but no one is irreplaceable

A great manager in 2016

The above sentence may sound strange at first, you may even think that this sounds like a threat, but in reality, this was the best teaching of my life. What my manager meant, was not that I was not that good but that I had to change my way of working if I was really thinking I was so important to the company.

From that day on and after numerous conversation, I started to underst that it was essential to make sure that while working you not only do your best, but you also make sure to do it in a way where you are not going to be indispensable. I have seen (and read) many cases in which a single individual would run a business and or held a position so strong that could stop a full operation by just taking a single day off.

To be able to take a vacation, you should make sure that your duties and responsibility are defined in a way in which they are “lead” by you, but not “need you”. To better understand this, you should ask yourself the following, are you able to offset all your duties and responsibility to any of your peers tomorrow, or is there anything that “they won’t know what to do”?. If you are “the only one to have production access”, the only one that “speaks with a client” or the only one that “merges PR”, you are doing things wrong, or more importantly, you are defining a position that is hard to let go (and will lead to burnout).

Fear of not being needed on return

In the previous section, we talked about you need to stay and work because of specific duties or responsibilities that do not allow you to let go, but in this section, we are actually going to see this problem from another angle, the one in which employees purposely work in a way to make them indispensable, or jump vacation for fear of losing their job.

During one of my projects, when my team members were told that I was going on vacation for a full month, I was asked “If the company can do a full month without you, are you not scared that they may not need you at all (and fire you)”. Even if I just had this specific question once, I have been in similar conversations multiple times.

The thinking behind this thought is not that wrong, why would a company have to pay you big $$ when your team can actually do everything you do when you are away?

The answer to this will actually surprise you. In fact, being able to set up a project, or a team that is able to self-sustain itself for a limited or unlimited amount of time should make you extremely proud and not scared.

If a team is able to sustain itself, it is not luck, but it is probably the result of your hard work in creating a good team that works together toward the same goals, a team that can self-sustain itself and in the long run, a team that will grow to achieve great results! Another very important side effect of creating such a team, is the possibility, on your return, to be able to offset some of your responsibility and be able to get some more. Doing this will actually result in career progression and I can personally guarantee this as it has been my tactic for over 10 years now. It not only helps you but also helps your own team to take more responsibility and progress!

Another way to answer the above “fear of being laid off” discussion is. In fact, if you are an employer that has an employee that works hard and fulfils his duties well, what would ever be the reason to ever affect this relationship just because he/her decision to take some well-deserved time off?

Finding a good employee is very hard and costly in today’s competitive tech industry, and there is no way an employer would let it go or affect the relationship just for some time off.

Vacation time

In the first part of this article, we have spoken about the need for vacation and the changes that you may need to undertake to be able to take some time off. In this section, we are actually going to talk about the actual vacation time, to see how it should be used, and in what way can it help your career.

Let’s assume have finally decided to take time off.. now what?

I have some small rules that I personally follow, these rules are set and enforced by my Wife that makes sure I follow them during all our vacations! 🙂

Set expectation

Inform your team and your managers that you are going on vacation and that this actually means that you are really going to be offline. You should not say something like “I am going to work a few hours”, “you can reach out when I am out” or “I will check my emails when offline”.

Time off (as you have seen above) is necessary for your brain, your career and your wallet, so you should make sure to do not to do any work for your employer while on vacation. There are small exceptions to this rule (at least for me), where I would check my email once a week if on a long vacation. This is not requested by my employer, but something that I do, to alleviate the work needed on my return to catch up.

Try to switch off

I absolutely love coding and like many other developers, I find it very hard to switch off, but this is really a must-do. To push against my urge to of developing, I follow this small rule:

On a short holiday, I do not bring the laptop with me
I plan a holiday where the Internet is very limited, or very expensive
I make sure to take a full week off-screen on a long vacation
I plan activities that require my body and bring me away from the screen

Our brain needs to rest a little and spending hours and hours of our vacation in front of a computer is really not what our great matter needs to be able to relax. I love doing DIY projects (in case of home vacation) or organising days out on the beach or camping to keep me busy.

Make screen time worth it

As I said above, I try to be away from the monitor or the computer, but this does not mean that I never actually do anything with my laptop while on time off. In those small cases in which I want to spend some time in front of a screen, I also have some small rules to follow.

The first and most important rule is to never work on anything that is work-related. Then I would say that it is important to try and invest in yourself. Being a father makes my free time during a normal week very limited. The lack of time is compensated during holidays in which I try to read articles, listen to podcasts and try new technologies that are needed for my career progress.

It is very common for side projects to start during vacation time, and this is perfectly normal, as these are the main form of personal growth.

What the research says

There is absolutely no reason for you actually to believe me, so I am going to start this post by sharing some research studies on vacation and time off.

The site www.shrm.org stats on vacation are:

Research consistently shows the health benefits of taking vacation time, like improved productivity, lower stress and better mental health.

https://www.shrm.org/resourcesandtools/hr-topics/employee-relations/pages/workers-taking-more-vacation-.aspx

While hbr.org inform us that:

… a staggering number of studies have demonstrated that our work performance plummets when we work prolonged periods without a break. We know that overworked employees are prone to mood swings, impulsive decision-making, and poor concentration.

https://hbr.org/2015/06/dear-boss-your-team-wants-you-to-go-on-vacation

Vacation is not just needed to define your tan line, or improve your sky skills, but it is actually needed for your personal development. I have personally always worked ahead of time to make sure that I have a good set of vacations, spread across the year (around one vacation every 2 months). I personally think that our Brain is like any other muscle of our body, and it needs some rest (not just weekend, but proper rest).

While reading the above sentence you are probably telling yourself…

Oh well, Simone, is easy for you to talk about vacation and time off because you can afford it…

The above sentence unfortunately is just not correct, not only because I have enjoyed my vacation since the beginning of my career, but also because vacation has actually been the main reason for my career progress and success, therefore Vacation has acted more like a long term investment that an immediate loss. This is also defined in the following article where it is said that:

People who took fewer than 10 of their vacation days per year had a 34.6% likelihood of receiving a raise or bonus in a three-year period of time. People who took more than 10 of their vacation days had a 65.4% chance of receiving a raise or bonus.

https://hbr.org/2016/07/the-data-driven-case-for-vacation

Summary

Time off is extremely important, as we have seen above, taking some days away from your day-to-day responsibility is essential. Deciding to take less time off or limited vacation is actually not a good sign and it is counter-productive, as it will result in burnout, the decision to change your job and slow career progress.

While talking about vacation time, we have just focused on the benefit of the actual employee, but there is an indirect benefit for the employer too. Letting employees go on holiday, will actually result not only in relaxed employees but also support their actual technical growth and result in better performance for the company as a whole.

NOTE: Everything I have covered in this article, expect an employer that wants his team to grow and now one that is just employing it! If you work in a company that “expects” you to answer emails on the weekend, work overtime and be available during holidays, you should find a new position immediately 🙂

What is the difference between v-show and v-if in Vue js

Mr_SC — Sat, 30 Jul 2022 13:43:36 +0000

Vue Js offers us a number of directives that are based to improve the development experience. If you are new to Vue Js, you may be asking yourself, what are directives in Vue js?

Directives are special HTML attributes that enhance the developer experience by providing a set of functionality to a specific HTML element and its children. These attributes can either be build-in or custom build. All vue directives are prefixed with “v-” to make them unique.

Zelig880

Show or hide an element

If you are reading this post, big chances are that you have been trying to hide/show a specific component or element and started to encounter some difficulties or have some questions. This post will hopefully include the answers you need. If it does not, please post a comment so that I can expand it to include more information for future readers.

Currently, Vue js comes with 2 different directives that can be used to hide and show a specific component or HTLM element, v-show and v-if.

// Example of v-if
<template>
  <main>
    <h2 v-if="showHeading" >This is my heading</h2>
    The rest of the component....
  </main>
</template>

// Example of v-show
<template>
  <main>
    <h2 v-show="showHeading" >This is my heading</h2>
    The rest of the component....
  </main>
</template>

For new users (and sometimes also advanced ones) these directives seem to be the same as they both achieve the same result of handling the visibility of the specified element, but behind the scene, these are actually different. This difference can actually turn into unwanted bugs or side effects.

What is the technical difference between `v-show` and `v-if`

These two directives are extremely different behind the scene, even if they offer the same end result.

The main difference exhibited by these directives when inactive (when the value passed to it is false) is that v-show actually renders the component or element within the DOM and applies it css declaration of display: none while v-if excluding the component of the element completely from the rendering of the component.

We are going to analyse these differences with a real example. If you would like to see the code yourself you can follow this link to the Vue SFC playground.

Let’s write a simple example that should not show any of the elements on screen:

<script setup>
import { ref } from 'vue'

const showElement = ref(false)
</script>

<template>
  <div v-if="showElement">Example of v-if</div>
  <div v-show="showElement">Example of v-show</div>
</template>

The above code produces a completely empty canvas, but the HTML hides some hidden surprises:

<div id="app" data-v-app="">
  <!--v-if-->
  <div style="display: none;">Example of v-show</div>
</div>

As the HTML above shows, the HTML tag created with v-show is actually included in the DOM but hidden using CSS while the one declared with v-if has been completely removed and it is just recognizable by the \ comment left by the Vue compiler.

Why does it matter?

Even if the difference to our eye is inexistent, the actual difference in technology and computing terms is massive. Knowing when to use them is very important as they both share important advantages and disadvantages. Using v-if would reduce the JS required to render the page as the HTML or component (and all its children if it has any) will not be loaded at all while using v-show maybe more costly at first (as all resources are loaded even if not used, but will result in a faster loading for the end client.

There is no “one rule to rule the all” situation here as the solution really depends on the use case, but I am going to detail below my personal thinking used when trying to decide which direction to use.

V-IF

I would personally use this directive in the following cases. When referring to “component” in the following list, we refer to the element of component that is assigned to the v-if directive.

If the component may NOT actually be rendered at all (for example just if a user is an admin)
If the component is very complex (nested components within the component )
If the component requires lots of API requests to fetch its data
If the component is not a primary component
If the component should NOT keep state between different renders

V-SHOW

I would personally use this directive in the following cases. When referring to “component” in the following list, we refer to the element of component that is assigned to the v-show directive.

When the component will be rendered on a normal user flow
When the component would take a long time to render (for example it has a API request that takes 1 second)
When the component is very simple.
When the component should just be mounted once
When required to use $refs on load even when hidden

Possible side effects or issues caused by miss-use

I have written this article because there can be a number of issues or side effects caused by the misuse of his directives.

$refs to available with v-if

The first and most common issue is that due to the fact that using v-if prevent the element from actually being rendered on the page, also means that refs are not available (as there is nothing to assign to ref in the DOM).

If you require to access the component even if it is hidden, you should use v-show instead.

The component is mounted multiple times

A very advanced (or hard to find a bug) is when you require mounted to just happen once within your workflow.

Due to the fact that v-if is just rendered in the DOM when its value is true, also meant that all his methods and lifecycle are just triggered when the value of v-if is true. What this means is that creating a component that would toggle between its visibility using v-if will mean a full remount of the component.

A live example can be seen in the following Vue SFC playground. In this example, we can see that the v-show element is triggered immediately, while the v-if is just triggered when we click the checkbox (and over and over again if we click and unclick it).

This can cause problems, for example in one example we were running a “log” that was recorded when a section of the page was shown but showing it using v-if was actually resulting in incorrect data being recorded.

State is lost between renders

It can be very common that you may be required to keep a state between different renders of a component. Let’s take for example a sidebar that allows the user to keep notes or do other actions. If you would use v-if to show the sidebar, its content would disappear and reset every time the sidebar is opened.
I have personally seen people creating vuex implementation and other hacks to avoid this issue, while a simple solution would have been to use v-show instead.
NOTE: It is also possible to cache a component while using v-if using <a href="https://vuejs.org/guide/built-ins/keep-alive.html" rel="noreferrer noopener" target="_blank"><KeepAlive></a>, but this is an advanced concept and misuse of it can result in slow application and performance.

Summary

I really hope the above will help you write more performant code and provide you with the information you need to make the correct choice in the future development of your application. As I already mentioned above, please feel free to comment below if you have any comments or personal examples that could be added to this article to support future users.

How to use Watch in Vue 3 with the Composition API

Mr_SC — Sun, 24 Jul 2022 21:34:04 +0000

In this article, we are going to cover in detail what watchers are and how they can be used in Vue js 3 using the Composition API and Script Setup. I usually like to cover both APIs in the same post, but in this case, there are a few too many differences that would make the article complicated, so I have decided to split it into two separate articles. You can find the Options API on this post: How to use Watch in Vue 3 in Option API.

In this post, I am going to provide as many details as I can to make it easy to comprehend, but a basic understanding of Vue Js and its lifecycle is beneficial.

What are Watchers in Vue Js

Before we learn how to use watch Vue Js, we should first define what this option actually is and when we should use it.

A watchers provide Vue Js users the ability to produce side effect in reaction to a change in state in one or more reactive variables.

Watch are very similar to computed properties as they are both defined as a feature that allows the user to “watch” for a property or data change. Even if it is common for new Vue developers to get confused between these two options, there is a clear distinction between them.

Computed properties return a value and do not produce any side effects. So for example a Full name could be a computed property or a sum of the available rows can be a computed property. Computed property should do nothing else than produce derived values and never trigger any other action within them.

Watchers on the other hand are purposely meant to be created to produce side effects. So for example recording some logs when the users change a selection, or triggering an API when a certain condition is met. This is a perfect example of watchers as they do not return any value, but just trigger an action as a consequence of one or more reactive property changes.

Watchers are not extremely common and you will probably end up using them just on special occasions, but they are an extremely useful feature for a complex component that relies on side effects (logs, API calls, evaluation from dataset).

Watchers and Vue Js lifecycles

Before we move on to discuss how to use this feature is important to understand when this feature takes place and when it is triggered. Understanding its placement within the Vue lifecycle will not only be beneficial to use this, but it will also help you comprehend advanced use cases.

To fully understand the watch option, we need to learn “what” triggers it, and “when” the triggered method takes place.

What triggers a watch to be called

As we have previously mentioned watch is triggered by a “change in state”. What this means is that a watch, like computed, is directly related to one or more variables (data, props, computed and even Vuex getters).

When the variable looked at by the watcher changes, the method assigned will be called. Before we move on to try and understand when this actually happens with the Vue lifecycle, we are going to cover a couple of fo simple examples to clarify the above paragraph.

If you have used Vue Js at all, you are well aware that a computed property will re-evaluate as soon as anything that is part of its method block is changed.

<script setup>
import { ref, computed } from 'vue'

const username = ref('Zelig880');

const myUsername = computed(() => {
  return `My username is: ${this.username}`;
})
</script>

In the above example, the computed property myUsername will trigger as soon as the ref username changes. So while in a computed method, any reactive reference used within its body is going to be observed, in the watch method things work differently as the “watched” variable(s) need to be declared as part of the function argument as shown below:

watch(question, async (newQuestion, oldQuestion) => {
<script setup>
import { ref, computed } from 'vue'

const username = ref('Zelig880');

watch(username, (newUsername) => {
   // Do something with the updated value.
});
</script>

In the above example, a watch method would be triggered if the username refs change. I want to emphasise that watchers and computed are not the same and this example is just used to support the understanding of the feature.

When is `watch` triggered

In the above section, we have learned that watchers are actively listening to specific variables and will trigger their method as soon as any of these variables change.

In this section, we are going to analyse the Vue lifecycle and understand at what state are these functions actually triggered. Not knowing when the method is actually triggered is usually the result of dirty code and unnecessary hacks.

To ease of understanding I am going to paste part of the lifecycle diagram from the Vue documentation:

https://vuejs.org/guide/essentials/lifecycle.html#lifecycle-diagramThe reason why I have just passed the middle part of the lifecycle is because watchers are triggered right here at the same time as the beforeUpdate lifecycle hooks are called.

For the reader that has just seen this diagram for the first time, the Mounted lifecycle in the middle of the image symbolizes the component being completely loaded and rendered in the DOM, while the dotted circle around it represent the loop that happens at any time any change of a reactive property of a component (data, property, computed).

The main reason why I wanted to write this section is to emphasise two important points:

Watchers are not called when the component is first mounted (there is a special flag to make this happen that we will cover later).
Watchers are called “before” the component is re-rendered. So the DOM is still displaying the old values.

Let’s create a simple chronological list of how things would take place to:

Component Instance is called <myComponent firstName=.... />
The component is mounted and displayed in the DOM – NOTE: The watch is NOT called!
The property firstName is changed by the parent
The Component lifecycle started the update cycle
The Watch method is triggered
The Component is re-rendered with the new value

As we will cover later in the article, it is possible to trigger a watch effect after the DOM is re-rendered and there is no need to create any specific hack. I know I have already said above, but it is really important to understand this because the code included in the watch method should never rely on the updated DOM (so we are not supposed to check the DOM or its state).

Real-life examples

Let’s cover a couple of examples and learn more about this Vue Js feature. As mentioned at the start of this article, we are going to cover Option API examples only and we are defining them using the Single File Component (SFC):

<script setup>
  import { ref, watch } from 'vue'

  const selected = ref(0);
  watch(selected, ( newValue, oldValue ) => {
    triggerLog(newValue);
  })
</script>

In the above example, we are triggering a log call as soon as the selected data is changed. To be able to use watch using the composition API and the script syntax, we have to first import it from vue:

import { ref, watch } from 'vue'

After the watch is imported, we are able to call it once or multiple times. The first article accepted by this feature is the actual ref, computed or store getters that we want to observe, in our case selected.

The second argument is the callback function that we want to trigger any time the watched variable changes. This callback accepts two arguments, The first argument includes the new value of the observed variable, while the second consists of the old value.

The above was just a simple example, but it is not time to start and introduce different options and features of this feature, starting with multiple watches and inline getters.

Watch multiple variables and inline getter

As I have already defined at the start of this article, I have decided to split up the documentation between Composition API and Options API due to some differences that would have made the article to complex to follow.

The ability to watch multiple variables at once or set an inline getter is just available within the Composition API and a workaround needs to be implemented to achieve the same in the Options API.

I have been using watchers for quite some time, and I was very excited when this features landed within Vue 3 as it was the source of verbose and unclean code.

Let’s analyse first the need to watch for multiple variables. This is a very common scenario when completing a form that should emit a side effect. Let’s reuse the above example with a few more inputs:

<script setup>
  import { ref, watch } from 'vue'

  const name = ref(''),
        surname = ref('');

  watch([ name, surname ], ( newValue ) => {
    triggerLog(newValue); //newvalue is an array including both values
  })
</script>

In the above example, we have used an array as the first parameter of our watch function and used it to pass multiple refs to it [ name, surname ]. The second part looks identical to our first example but I has a hidden difference as the value of “newValue” (and “oldValue” if we would have used it), is not just the value that changed, but it is an array including all the value that we are watching.

I am going to provide a chronological example to help understand these values.

<script setup>
  import { ref, watch } from 'vue'

  const name = ref(''),
        surname = ref('');

  watch([ name, surname ], ( newValue, oldValue ) => {
    triggerLog(newValue); //newvalue is an array including both values
  })
</script>

// Name changes to Simone
//OUTPUT of newValue: ['Simone', '']
//OUTPUT of oldValue: ['',''] 

// Surname changes to Cuomo
//OUTPUT of newValue: ['Simone', 'Cuomo']
//OUTPUT of oldValue: ['Simone','']

As we can see from the above example, the value of newValue and oldValue includes all values that we are watching and not just the ones that we are changing. I would suggest using array restructuring to improve readability:

  watch([ name, surname ], ( [ newName, newSurname] ) => {
    ...
  })

Now it is time to introduce the second improvement, the ability to pass inline getters or computed properties as part of our observed value.

<script setup>
  import { ref, watch } from 'vue'

  const age = ref(0);

  watch(
    () => age.value > 50, 
    ( newValue ) => {
      triggerLog(newValue);
    })
</script>

In the above example, we are going to trigger a log just if the value of age if greater than 50. This feature was available in the Option API , by using computed, but having the ability to declare these getters directly within the Watch function is really going to improve the development experience.

Please note that due to the fact that we accessing a ref, we have to use age.value as explained in the Vue 3 docs.

A very important note when using inline getters, is that our watch is just going to be triggered if the returned value of our getters changes. This means that the watch callback is not going to be changed if the value of age changes multiple times unless the value fluctuates between the value of 50. So for example:

<script setup>
  import { ref, watch } from 'vue'

  const age = ref(0);

  watch(
    () => age.value > 50, 
    ( newValue ) => {
      triggerLog(newValue);
    })
</script>

// Age change to 20;
// Watch NOT triggered

// Age change to 40;
// Watch NOT triggered

// Age change to 60;
// Watch triggered

Before we move on to the next features, I wanted to share that watch is able to accept a mixture of getters and refs as part of its observer variable array:

  watch(
    [ simpleRef, storeGetters, () => age.value > 50 ], 
    ( newValue ) => {
      triggerLog(newValue);
    })

Watch reactive objects – AKA DEEP

Until now we have always looked at refs and getters, but the watch the method is also able to support complex objects as the one declared using reactive.

Differently from the Option API, the watch method is able to handle complex objects out of the box and automatically apply the “deep” option if it detects an object as it observed values:

var form = reactive( { name: '', surname: '' } );

watch(
  form,
  (newForm) => {
  }
)

It is important to realize that observing objects requires traversing the object properties and this can be very complex for large objects and should be used with caution. Watching a large object may result if a slow and resource-heavy code execution.

Immediate trigger – AKA immediate

It is now time to cover another scenario that we would likely experience during real-life development of a Vue 3 application. In this section, we are going to cover the need to call our Watcher immediately on mounted. This is usually needed when the callback function is needed to set some specific state on the application and needs to be run at all code iterations, even on the first one.

This is achievable using two different methods. The first involves the use of the Composition API directly without the use of “watch”, and the second uses a new method called “watchEffect”.

Immediate watch

Due to the syntactic sugar of the composition API, solving this problem does not actually need any specific feature as we are able to “trigger” our callback manually:

// Watchers triggered ONLY if the "src" variable changes from its first value
<script setup>
  import { watch } from 'vue'
  const imgSrc = defineProps(['src'])

  watch( imgSrc, preloadImage );
</script>

// Watchers triggered on load too
<script setup>
  import { watch } from 'vue'
  const imgSrc = defineProps(['src'])

  preloadImage( imgSrc );
  watch( imgSrc, preloadImage );
</script>

Using the “watch” method out of the box would not provide the ability to trigger it immediately, but the use of the composition API makes the code to achieve this extremely simple. The only difference between the two examples above is the addition of a manual call of the method “preloadImage”. Due to the nature of the composition API, this method is going to trigger very early within the Vue lifecycle (even before the component is mounted). If the method needs to actually run after the DOM is completely rendered, we would need to wrap it in an “onMounted” callback:

<script setup>
  import { watch, onMounted } from 'vue'
  const imgSrc = defineProps(['src'])

  onMounted( () => {
    preloadImage( imgSrc );
  } );

  watch( imgSrc, preloadImage );
</script>

WatchEffect

In this article I am just going to cover the basic of this feature, as I personally believe it to be quite complex and I would not want to make this article too complex as it is intended for newcomers.

The watchEffect is a different iteration of watch that runs immediately when a component is first rendered. If you have ever used the composition API, watchEffect would be similar to the use of the immediate option.

As mentioned above I am purposely avoiding providing more information and code example in this post.

Run after DOM manipulation – AKA Flush

We have reached the last option available within this Vue Js feature. As we mentioned before, watch are triggered before the component is fully re-rendered, but this can actually be changed using the “flush” configuration.

Using “flush” will make sure that our watcher is called after the component is fully re-rendered and should be used for methods that require the DOM to be fully updated with the new values.

watch(
  user, 
  ( newValue ) => {
    this.$refs.test.style = ....
  }, 
  { flush: 'post'
 }
)

The use of flush is very important when the side effect included in the watch callback requires information included in the DOM. Some developers mistakenly use “nextTick” within the watch effect to overcome this issue, but using the flush option is actually the preferred option.

Summary

I have used Vue JS for many years, but just recently was really made aware of all the methods available when using the watchers feature. The above post is hopefully going to help you in using this feature correctly and avoid hacky solutions for problems that can easily be fixed with the use of a single setting.
It is time to say goodbye and as always, please make sure to leave me a comment or feedback to improve this post for future readers and subscribe to my newsletter to be notified of future posts.

Comprehensive guide on Watch in Vue 3

Mr_SC — Sat, 16 Jul 2022 23:38:10 +0000

In this article, we are going to cover in detail what watchers are and how they can be used in Vue js 3 using the Options API. I usually like to cover both Option API and composition API in the same post, but in this case, there are a few too many differences that would make the article complicated, so I have decided to split it into two separate articles. You can find information on how to use Watch in the composition API in this post: How to use Watch in Vue 3 in Composition API.

In this post, I am going to provide as many details as I can to make it easy to comprehend, but a basic understanding of Vue Js and its lifecycle is beneficial.

What are Watchers in Vue Js

Before we learn how to use watch Vue Js, we should first define what this option actually is and when we should use it.

A watchers provide Vue Js users the ability to produce side effect in reaction to a change in state in one or more reactive variables.

Watchers and Vue Js lifecycles

To fully understand the watch option, we need to learn “what” triggers it, and “when” the triggered method takes place.

What triggers a watch to be called

As we have previously mentioned the watch option is triggered by a “change in state”. What this means is that a watch, like computed, is directly related to one or more variables (data, props, computed and even Vuex getters).

If you have used Vue Js at all, you are well aware that a computed property will re-evaluate as soon as anything that is part of its method block is changed.

computed: {
  fullName() {
    return `${this.firstName} ${this.middleName} ${this.lastNam<span style="background-color: inherit; font-family: inherit; font-size: inherit; color: initial;">e}`</span>;
  }
}

In the above example, the computed property fullName will trigger as soon as either first, middle or lastName is changed. The way in which these “related” variables are declared in a watch method is quite different as the actual name of the watch is the link to the reactive variable:

watch: {
  firstName(){
  }
}

In the above example, a watch method would be triggered if the firstName variable changes. I want to emphasise that watchers and computed are not the same and this example is just used to support the understanding of the feature.

NOTE: you can just listen to a single variable at the time when using watch while using the options API. To listen to more variables you would either have to declare multiple watches or create hacks with computed properties

When is `watch` triggered

In the above section, we have learned that watchers are actively listening to specific variables and will trigger their method as soon as any of these variables change.

To ease of understanding I am going to paste part of the lifecycle diagram from the Vue documentation:

The main reason why I wanted to write this section is to emphasise two important points:

Watchers are not called when the component is first mounted (there is a special flag to make this happen that we will cover later).
Watchers are called “before” the component is re-rendered. So the DOM is still displaying the old values.

Let’s create a simple chronological list of how things would take place to:

Component Instance is called <myComponent firstName=.... />
The component is mounted and displayed in the DOM – NOTE: The watch is NOT called!
The property firstName is changed by the parent
The Component lifecycle started the update cycle
The Watch method is triggered
The Component is re-rendered with the new value

Real-life examples

...
data() {
  return {
    selected: 0
  }
},
watch: {
  selected(oldValue, newValue) {
    triggerLog(newValue);
  }
}

In the above example, we are triggering a log call as soon as the selected data is changed. Watchers are part of the available option within the Options API and are exposed as an object named watch as seen above.

The name of the watch has to be equal to the variable that we may want to listen to. So in our example, we called the watch “selected” as we want it to be reactive to the “selected” data. Trigger a log after a user interaction is a very common use case for a watch effect.

The watch provides 2 arguments. The first argument includes the new value of the observed variable, while the second includes the old value.

Nested Keys

In the above example, we are observing a single variable, but there are times in which you may want to watch a nested key within a complex object.

To do this, we can use a dot-delimited notation as shown in the following example:

...
data() {
  return {
    user: {
      firstName: '...',
      lastname: '...'
    }
  }
},
watch: {
  'user.firstName'() {
    triggerLog();
  }
}

NOTE: Expressions are not supported and just simple paths should be declared.

Deep

Until now we have always looked at a single value (either directly or by selecting a specific key of an object). This was not done to simplify the example, but it is actually due to a limitation in the watch option.

In its default form, a watcher will not react if a complex (deep) object is passed to it. Luckily for us, observing complex objects is very simple as it just takes a simple configuration called “deep” to be defined.

...
data() {
  return {
    user: {
      firstName: '...',
      lastname: '...'
    }
  }
},
watch: {
  user: {
    handler(newValue, oldValue) {
      //both newValue and oldValue are the FULL object and not just what changed of it!
    },
    deep: true
  }
}

To be able to declare further configurations like “deep” we have to declare our watchers in a different format by declaring the method within a function called “handler” as shown above.

You may be asking yourself why the hassle of having to declare the watch as “deep” and what is the reason behind not making it default. As mentioned in the Vue documentation, the reason behind this decision has to do with the computation complexity required when “deep” is used.

Observing objects requires traversing the object properties and this can be very complex for large objects and should be used with caution.

Immediate – eager

It is not time to cover another important configuration available within the watch option. This one is called “immediate” and it is used to inform the Vue JS framework to trigger our watch immediately as soon as the component is mounted.

If we wanted to re-use the lifecycle diagram as shown before we would need to expand it as using the “immediate” option would mean that the first instance of the watch would actually happen before the component is fully mounted.

Below is a simple example of the use of watch that would trigger immediately:

props: {
  termsAccepted: Boolean
},
watch: {
  user: {
    handler(newValue) {
      if( newValue === true ) triggerLog();
    },
    immediate: true
  }
}

Flush

Using “flush” will make sure that our watcher is called after the component is fully re-rendered and should be used for methods that require the DOM to be fully updated with the new values.

...,
watch: {
  user: {
    handler(newValue) {
      this.$refs.test.style.....
    },
    flush: true
  }
}

Summary

How to use $refs in Vue 3 with Composition API and Script Setup

Mr_SC — Thu, 30 Jun 2022 22:23:23 +0000

This post is going to explain how to use Ref in Vue 3, while using the Composition API and the Script Setup. The usage of references when using the options API is unchanged, but Vue 3 provided us with two different ways to define the component script block, Composition API and Script Setup.

In the first part of this article we are going to introduce Refs, but if you are already familiar with this feature and you just want to know how to use Ref with the Composition API or the Script Setup, you can jump to he section called: Ref in Composition API example or Ref in Script Setup example respectively.

What are $refs in Vue

In Vue js, $refs provide you the ability to access the DOM element of a specific HTML element or custom component available within your template.

In simple words, applying the ref attribute to a specific element in your template, give you the ability to obtain a direct reference DOM element, this is the same result that you would get when using document.getElementById, document.getElementByClassName or any other similar API resource.

When would you use $refs

Accessing DOM references of HTML elements is not very common during your day-to-day activities, but it is an important feature to learn. Being able to use refs successfully unlocks a full set of implementation, bringing your development skills to another level.

It is important to clarify that refs should not be used unless strictly necessary. Using DOM manipulation can be costly, and when possible it is always suggested to use the existing Vue APIs to try and achieve your needs (props, data, and computed).

Here are a few examples that would require you to access the DOM element using $refs:

Having to focus on a component after a specific event but calling
Having to change specific styles that cannot easily be handled by classes ( this should not be handled using v-bind in CSS see this post for details: https://zelig880.com/how-to-use-variables-in-css-with-v-bind-in-vuejs-3 )
Having to fetch specific information of the element, such as height or offset values.

How to use $refs with Composition API

It is now time to learn how to use this feature while using the Composition API. If you have been using the Options API and have previously used this feature, you know that an object was available within the component context (accessible with this) and all refs were stored with the this.$refs object.

In the Composition API and Script Setup, we have not only lost access to the context, but also lost the ability to access the $refs object.

An HTML reference using the Composition API is defined the same way you would define any other variable using the syntax const variableName = ref(null).

Usage of DOM reference requires two steps. First, you would declare a variable, initializing it to null, then you need to assign that variable name as a “ref” attribute on the element.

Let’s write two simple example, for the Composition API and the Script Setup respectively

Ref in Composition API example

<script>
import { ref } from "vue";
export default {
  setup() {
    const myReference = ref(null);

    return {
      myReference
    };
  }
};
</script>

<template>
  <h1 ref="myReference">I have access to the DOM reference now</h1>
</template>

Ref in Script Setup example

<script setup>
import { ref } from "vue";

const myReference = ref(null);
</script>

<template>
  <h1 ref="myReference">I have access to the DOM reference now</h1>
</template>

The use of this feature is quite simple and even if we have lots of access to the $refs object, we are still able to make use of DOM element quite easily. In the next section, we are going to use this method and understand how it is defined and updated during the Vue lifecycles

Why is the ref null in the setup function?

In this section, we are going to answer an important question that may arise quite quickly after you try to use the Ref feature of Vue js. I have personally fell for this simple detail and I wanted to make sure we cover it in details in this post.

If we would try to access our variable within the setup function, we would be quite disappointed as it will result in a null response:

<script setup>
import { ref } from "vue";

const myReference = ref(null);

console.log(myReference.value); <-- This will output null
</script>

<template>
  <h1 ref="myReference">I have access to the DOM reference now</h1>
</template>

The reason behind this behaviour is plainly explained in the Vue documentation (I am not sure how I missed it), but it states:

(talking about refs) It allows us to obtain a direct reference to a specific DOM element or child component instance after it’s mounted.

https://vuejs.org/guide/essentials/template-refs.html

A reference cannot be accessed until the component is mounted, because that is the lifecycle that handles the creation of the HTML. When trying to access the variable directly, like I did in the example above, would have triggered the console.log even before the “beforeCreated” is reached as explained in the lifecycle Hooks documentation.

To be able to access our reference we need to make sure that the component is actually rendered, therefore call our method within the “onMounted” hook:

<script setup>
import { ref, onMounted } from "vue";

const myReference = ref(null);

onMounted(() => {
  console.log(myReference.value); <-- This will output a DOM node
})
</script>

<template>
  <h1 ref="myReference">I have access to the DOM reference now</h1>
</template>

Summary

Even if things have changed since the Options API, the syntax required to access the DOM elements is still quite simple. The Vue core team has done a fantastic job of really making things simple while providing a very powerful API.

As I already mentioned above, accessing the DOM node directly can be costly and should just be done when no other options are available.

How to use Slots and Attrs with the Composition API

Mr_SC — Fri, 24 Jun 2022 20:31:19 +0000

In this article, we are going to describe how to successfully access slots and attributes while using the Composition API and Script setup syntax. The use of these features while writing components using the Options API was quite simple, as all context was available within the “this” scope, but since the introduction of the composition API and the script setup, things have changed slightly and this post is going to show you how to use this great features.

What are Slots and Attrs

As with every post, it is important to spend a few words to ensure that all readers are aware of what Slots and Attrs are and how they can be used within the Vue framework.

Slots in Vue js

We start by spending a few words on Slots. From a great article on the site dev.to slots are referred as:

Slots are a reserved space offered by vuejs to display content passed down from one component to another.

https://dev.to/suniljoshi19/understanding-slot-in-vue-js-1j7p

Slots are usually defined and used within the <template> block of the Vue single file components (SFC) as shown in the following example:

//MyButton.vue
<template>
  <button>
    <slot></slot>
  </button>
</template>

//Parent of button
<template>
  <my-button>
    This is going to be placed where the slots are <bold>Also accept HTML and components</bold>
  </my-button>
</template>

We are not going to cover in detail how to use slots, but it is enough to know that during your component development, you will be required at times to make your component more flexible, and slots are going to be the feature that you were looking for.

Slots are also referred as $slots, because this is the syntax used to access them into the component template.

Attrs in Vue 3

It is now time to spend a few words on what attributes are in Vue 3. I am actually emphasising the Vue version as Vue 3, because the Attribute object, also known as $attrs, has actually changed. If you are interested in learning more, you can read this article titled: Build Advanced Components in Vue 3 using $attrs.

The attribute property is an object that contains all the ids, classes, attributes, events and data of a component. Attributes are referred to in the main Vue documentation as Fallback attributes. This name refers to the fact that the $attrsincludes all the “undefined” properties that a component may have.

Here is a quick example of the attribute object on a custom component:

//Parent.vue

<my-button
  data-cy="button"
  class="dark-button"
  id="the-button"
  @click="doSomething()"
  aria-label="A nice button"
  disabled="true" 
  undefinedProperty="ops"
/>

//MyButton.vue Attribute object

{ 
  aria-label: "A nice button"
  class: "dark-button"
  data-cy: "button"
  disabled: "true"
  id: "the-button"
  onClick: $event => (_ctx.doSomething())
  undefinedProperty: "ops"
}

While the slot component is more aimed at an advanced use-case, the use of the attrs object is very common while developing Vue application.

Before we move forward, it is very important to mention that the attribute object is automatically assigned to the root element of a custom component. So in our example above all the parameters will be assigned to the <button> element.

How to access $attrs and $slot in the `<template>`

We start with the simple solution that is accessing these properties within the template of your component. This syntax is not actually changed and it has stayed the same since Vue 2.

Accessing these two objects within a component is done using the $slots and $attrs variables:

<template>
  <button>
    <span
      :id=<meta charset="utf-8"></meta>"$attrs.class"
      :aria-label="$attrs['aria-label']
      class="[ 'the--slot-is-an-svg': $slots.default().type === 'svg' ]"
    >
      <slot></slot>
    </span>
  </button>
</template>

As the above example shows. Accessing the slots and further attribute is extremely simple and clean. It is important to realise that the use of $slots using its actual object declaration is not very common and it is just expected from an advanced component. If you want to learn more about slot you can read my article on slots.

How to access Slots and Attrs using the Composition API

Even if the syntax sugar to retrieve Slots and Attrs in Vue 3 has changed, accessing these parameters is still quite simple. In Vue 2 (or Vue 3 while using the options API) access to the component context was available within the this keyword. So slots and attrs were respectively this.$slots and this.attrs.

In the composition API we have lost access to the context to this. To access these objects in Vue 3, we will have to use the arguments available within the setup function. In fact, the context previously available within this is now being passed as the second argument of the setup method.

// Example using the context object
<script>
export default {
  setup(props, context) {
    console.log( context.slots );
    console.log( context.attrs );
  });
}
</script>

//Example using onject destructuring<meta charset="utf-8"></meta>
<script>
export default {
  setup(props, { slots, attrs }) {
    console.log( slots );
    console.log( attrs );
  });
}
</script>

The main difference from the previous example is that the variables have dropped the $ in their name.

How to access Slots and Attrs using the script setup

We have reached the example of our article. So far we have covered both template and Composition API. It is time to complete by the post by also defining how to access these arguments while using the script setup.

Since moving to Vue 3, I have spent lots of time googling around how to do something in Vue 3 due to the small changes in syntax and the <script setup> is the most interesting of all as not only has lost access to the context provided in the this keyword, but it also lacks access to the setup function, preventing us to access to its argument.

Luckily for you, this does not mean that these methods are harder to access at all. In fact, the amazing Vue core team has defined some easy-to-use composables that provide us everything we need to use slots and attrs.

The composable that we are going to use are useSlots and useAttrs. This information is accessible in the script setup documentation. If we would replicate the above example with a <script setup> syntax sugar we would write the following code:

<script setup>
import { useSlots, useAttrs } from 'vue'

const slots = useSlots()
const attrs = useAttrs()
</script>

Conclusion

I have written this article to hopefully save you some time googling around. Luckily for us, even if things have changed from the previous version of Vue to the current, it is still pretty simple to access these component properties.

Before saying goodbye, I would like to ask you to leave a comment if this article was useful and provide any feedback that may help me make this more useful for future readers.

The importance of Headings element for an accessible page

Mr_SC — Sat, 18 Jun 2022 22:52:50 +0000

If you are reading this post, chances are that you have started to think about improving your understanding of accessibility and have been trying to write pages that are semantically correct. In this article, we are going to cover one of the most common mistakes made by developers. The misuse of Heading elements (H1, H2, H3…) within a page.

Accessibility is not simple to learn, but learning good semantics and writing well-defined HTML can help us achieve very good results with minimal effort, and today I want to share with you how headings should be used and the pattern that you should avoid to improve your code quality.

Heading is a very important element for visually impaired users. In fact, all screenreaders and smartphones include features that allow navigation of pages through their headings. This method of navigation provides a user with the ability to quickly listen to the different heading and jump to the content that they are interested to read.

A page with wrong headings, missing headings or wrong use of them, would make this navigation method unusable and force a user to tab through the full page.

What are heading tags

Headings tags, as the name suggests are elements used to define the title, subtitles and any other heading within our page. This comes in six different levels where 1 is the most important, all the way to 6 which should be for the least important information.

Heading tags are used within HTML using the following syntax:

<h1>Heading 1</h1>
<h2>Heading 2</h2>
<h3>Heading 3</h3>
<h4>Heading 4</h4>
<h5>Heading 5</h5>
<h6>Heading 6</h6>

Browsers have pre-defined a set of styles, usually in the form of font size, font weight and margin for each of these headings. So the above code would display something like this:

Screenshot of the different styles applied to the Headings element by the browserAs displayed by the above screenshot. The different levels of importance are clearly defined by the browser. Heading 1 which is usually expected to be used for the page title is the most prominent while heading 6 which is usually set for a minor subchapter is very small, almost as close as a paragraph.

These headings are the same that we have been for hundreds of years in printed newspapers. The different size provided by the bowsers is a clear sign for us of their importance and hierarchy on the page.

As we will shortly see, these pre-set styles are both a blessing and a curse, as they are the main issue for which developers are driven to create unaccessible HTML.

The common mistake while using tags

The most common mistake while using the heading element, is to use them for the way they look and not for what they actually symbolize. Unfortunately, the browser styles that are applied to these elements, instead than help users, have driven them to actually make mistakes.

In the following few sections we are going to describe a couple of examples that would result in the wrong HTML:

Missing Heading

The idea behind the use of headings is that a page should include as many headings as needed to define its content, but they should be starting from H1 and should be sequential without any heading missing.

This occurs when one or more headings are missing. As I said above we always have to start from H1 and need to ensure that the heading follows the correct order. In the following example, we have mistakenly missed <h2>. This is a very common mistake because people choose to head at times due to their “look” instead of for their semantic reasoning.

// WRONG
<body>
  <h1>My Article</h1>
  <h3>Getting started</h3>
  <p>A very long and interesting text</p>
  <h3>Conclusion</h3>
  <p>This was a great article</p>
</body>


// CORRECT
<body>
  <h1>My Article</h1>
  <h2>Getting started</h2>
  <p>A very long and interesting text</p>
  <h2>Conclusion</h2>
  <p>This was a great article</p>
</body>

Use multiple H1

Using the main header, <h1> multiple times can actually be done as there is no actual rule against it. I personally have always tried to stick with just one main heading when developing any webpage. I feel any webpage will always have a single title, and I can personally not find a good excuse to ever define multiple H1s.

If we consider a newspaper to clarify this issue. You will never see a newspaper with 2 titles, so why should you see a webpage with them?



// WRONG
<body>
  <h1>Website Title</h1>
  <p>A very long and interesting text</p>
  <h1>Author name</h1>
  <p>Author information</p>
</body>

// CORRECT
<body>
  <h1>Website Title</h1>
  <p>A very long and interesting text</p>
  <h2>Author name</h2>
  <p>Author information</p>
</body>

How to avoid heading misuse

Luckily for you, today I am going to share with you a very simple trick that I have used for years now. This small change in my code has really helped me, and many of my colleagues to embrace the real meaning of headings and helped us define beautiful designs without the need to produce unaccessible HTML.

The idea is to separate the heading style from its actual semantic meaning. By separating them, we will be able to avoid the issue that makes us mistakenly use the wrong headings. In the following code snippets, we are going to declare standalone classes that can be used to “style” our headings:

// style.css

// The following will be used as our H1
.xxl { 
  font-size: 2rem;
  margin-bottom: 0.875rem;
  font-weight: bolder;
}

// The following will be used as our H2
.xl{
  font-size: 1.5rem;
  margin-bottom: 0.75rem;
  color: blue;
}

// The following will be used as our H3
.large{
  font-size: 1rem;
  margin-bottom: 0.75rem;
  color: green;
}

In the above code, we have defined 2 classes that “replicate” the style of the first and second and third heading. The idea behind the above code is to not only provide us with reusable style but also provide us with names that just refer to styling and not to any semantic reasoning.

Now that our style and our heading are not aligned, we would hypothetically be able to achieve the following headings

Screenshot of the different headings produced using custom classes.While writing correct HTML as shown below:

 <body>
    <h1 class="xxl">This is my large title</h1>
    <h2 class="large">This is my very small heading</h3>
    <h3 class="xl">This is an heading that is way to large for its level</h3>
  </body>

As you have probably noted, the names of the classes do not directly align with the heading level. This is actually been done on purpose to define a better separation between the actual heading element and a set of styles that can be applied to HTML elements.

NOTE: The above example is completely inappropriate because it inverts the use of heading and provides the wrong visual clue (by showing a smaller heading for H2 that it does for H3), and it has just been done for demo purposes.

Conclusion

It is very unfortunate that in 2022 the web is still not a very accessible place. There is nothing stopping us to work a bit harder and work toward a web accessible to everyone.

The solution I have provided you is not actually rocket science, but it is all you actually needed to start and improve your HTML to help the visually impaired user. The use of these classes has been around for quite some time, as it is available in many design systems and frameworks like Bootstrap and Tailwind.

My hope for this article was not to teach you to use CSS to define some style, as I hope you were well aware of that usage. What I hoped to share is the importance of the heading element itself. The separation of the style and its semantic meaning is just needed to help you understand its real usage and think twice before using it inappropriately within your HTML pages.

The final message is quite simple. Use heading in their correct order, and make sure to apply them appropriately to support the content of your page.

How to use variables in CSS with v-bind in VueJs 3

Mr_SC — Thu, 09 Jun 2022 14:29:54 +0000

Frontend frameworks like VueJs, React and Svelte offer great flexibility in the development of UI components. The simplicity in which we can create components with dynamic properties offers the possibility to solve complex requirements with just a few lines of code.

If you have been using VueJs, you are probably aware of the limitation that prevented you to use props, data and computed properties within your component styles. Developers had to resort to the use of hacks to make styles dynamic, usually at the cost of more verbose code and untidy code.

Since the release of VueJs 3, we have a built-in solution that allows us the use properties directly within the <style> tag of our Single File Component (SFC). This feature is called v-bind in CSS and this post is going to cover in detail how to use this new feature, and what it actually means behind the scene.

I am a strong believer that an issue is best explained when the reader has full knowledge of the problem we are trying to solve. If you are aware of the issue and just want to see how to pass variables in CSS in Vue 3 you can jump to the next chapter named “v-bind in CSS in practice”, if on the other hand this is new to you and want to really understand this concept I suggest you read on.

Introduction – a real-life example

There can be many situations in which you may want to create dynamic CSS properties. In this section, we are going to provide a few scenarios that may require the use of dynamic variables and therefore provide context to be used in our next sections.

Button with multiple styles

This is probably the most common example that would require the use of variables in CSS. In this scenario our requirements are:

Create a button component that allow an user to specify its look and feel with the use of properties. The button woud accept a property of colour that will be used to define the component background color

The above requirement is extremely typical in component-based architecture. Even if simple, a fully developed component could require many properties to be configured. The most common solution for this issue is the creation of a “rigid” set of colours available and hardcode them directly using CSS classes, like “button-primary”, and “button-secondary” and then define the CSS for the specific style .button-primary: { background-color: red }

Dynamic Background image

A few years ago I was asked to create a component that would allow the creation of fancy cards. This card could be highly configurable and one of the requirements was to allow properties that defined its background image.

Many developers may think that a solution to this problem would be to use a <img> tag. Doing so would remove the need for a dynamic CSS variable, but unfortunately, this would not be semantically correct as a background image should be defined with CSS and if it is really just for decoration purposes. There are very important accessible distinctions between a background image and an image element as mentioned in this article on W3Docs.

Another possible solution for this requirement would be the use of JavaScript to dynamically change the value of the background image of a specific element. Even if this resolution would solve our needs, it would still create more code than we need and leave our components untidy.

Dynamic Sizing

In the third and last example, we are going to add some complexity to our requirements. Nowadays flexbox and grid have made layout and dynamic sizing much easier than it was a few years ago. There are still situations in which these two CSS features are not enough and some complex logic may still be required for us to achieve our needs.

A typical use case for the need for javascript and logic would be a page that needs to specify an element size depending on the number of items available on-page or set the height of a component depending on the amount of text that the page contains. I have had to develop both of these examples by hand and it was not a very clean solution as the framework would not allow me to do so.

V-bind in CSS in practice

It is now time to implement the above examples with the use of the new feature v-bind in CSS. The usage of the feature is very simple as it just requires you to use any property, computed property or data variable directly within the style section of your single file component.

The variable need to be wrapped into a v-bind method. So for example if we want to define a button component that accepts a colour property using the options API, we will write something like this:

<template>
  <button class="button">Click me</button>
</template>

<script>
export default {
    props: {
        colour: String
    }
}
</script>

<style>
.button{
    background-color: v-bind(colour);
}
</style>

The above code shows the simplicity and the power of this new feature. As you can see there is no need for any CSS preprocessor like LESS or SASS, as this new feature takes full advantage of CSS variables which we will cover later in this post.

Using dynamic CSS variables is not only possible while writing components using the options API, but it is also available with the newly introduced <script setup>. The example below shows how the above code can be translated into the script setup.

<template>
  <button class="button">Click me</button>
</template>

<script setup>
const props = defineProps({
  colour: String
})
</script>

<style>
.button{
    background-color: v-bind(colour);
}
</style>

The two examples shown above make use of simple properties. In the example below we are going to make use of a nested variable available within our data object.

<script>
export default {
    data() {
        return {
            styles: {
                backgroundColor: 'red',
                color: 'blue'
            }
        }
    }
}
</script>

<style>
.button{
    background-color: v-bind('styles.backgroundColor');
    color: v-bind('styles.color');
}
</style>

The use of nested properties is very similar to the simple example provided previously in this post. There are two main differences when using nested properties:

The variable name needs to be wrapped in quotes
The syntax used to access deep variables is the same one used in Javascript with the use of the “.” to delimiter the object structure.

Reactive CSS variable

It can not be a Vue post unless we talk about reactivity. The Vue Js framework is built on top of a powerful reactivity system, that allows it to be fully reactive to any change that a user action or change may incur. This reactivity can also be used to our advantage within our CSS.

<template>
  <button class="button" @click="changeBackgroundColor">Click me</button>
</template>

<script>
export default {
    data() {
        return {
            backgroundColor: 'red'
        }
    },
    methods: {
        changeBackgroundColor() {
            this.backgroundColor = 'blue';
        }
    }
}
</script>

<style>
.button{
    background-color: v-bind('backgroundColor');
}
</style>

In the code above our background colour will change from ‘red’ to ‘blue when the button is clicked.

How does v-bind in CSS works behind the scene

The last part of this article is going to go behind the scene and try to understand how this feature is working within the VueJs framework.

When I first learned about this feature, I has the impression that it would be a build time feature and would just work on the first render, hence not responsive. Luckily for you all, I was wrong. As you have seen from the previous chapter, this feature is fully responsive and works throughout the lifecycle of your component.

The way this feature works behind the scene is by defining CSS variables and assigning them to the root of the current component. If we take the example above in which we define a backgroundColorproperty, the code would look like this:

screenshot of v-bind in CSS from the Vue SFC playgroundAs the above image shows, the backgroundColor variable is actually being turned into a CSS variable named --472cff63-backgroundColor. The extra character in the name ensures that there is no conflict in the variable name.

The beauty of this implementation is that it enhances the development experience, as the variables are easily identifiable and easily changeable within the browser’s development tool. The following screenshot shows the how easy it is to grasp the variables:

Screenshot of the chrome developer tools that are showing the CSS variable being set from Vue JS ### Conclusion

If we look back at the real-life example section that we used to start this post, we can start to understand how clean and flexible our solutions could be. Defining complex layout dimensions can easily be achieved using a simple computed property, or developing a set of button styles can be executed using a simple data property containing all the possible iterations.

I have personally been waiting for this feature for a very long time, as I have time and time again had to work around and write hacks to achieve very simple solutions. Even if you may think that you have no current need to use the v-bind in CSS feature, I can guarantee you that you will surely have need of it soon after its discovery.

I hope you find your own use of this great feature, and please feel free to post below a comment on real scenarios in which you used the above feature to help new readers.

My 10 Years Experience as a Javascript Software Engineer

Mr_SC — Mon, 02 May 2022 22:40:34 +0000

I like to always symbolize important events with a nice post, this gives me the chance to stop and really think about the numerous events and challenges that I had to surpass to be able to achieve this big milestone. When someone starts a new career, it usually feels like a jump into the unknown, as we are completely unaware of what will happen in the years to pass.

In this post, I am going to share my feeling, successes and failures, with the hope that this will help you give some clarity to your own path. It is true that no story is the same, and your paths and career may be very different from mine, but the aim of this post is to highlight what lies behind my current strong self-esteem is actually a multitude of failures and uncertainty.

Before I even started – Over 10 years ago

If you follow me on any social network or joined me at any social event, you will already know that my career as a developer was not actually planned. I spend my teens studying toward a Business Management and Economics degree and own my own cafe for 18 months before my career in development actually started.

At the time, the internet did not have things such as #100daysOfDevs, and boot camps were not very common where I come from, so my expectation of becoming a self-thought developer was very limited. I am not going to go into many details as this is not the scope of this post, but what you should know is that I managed to get my first ever developer job with very limited tech knowledge and experience (a couple of months of YouTube and side projects in the evenings).

If you are currently working to get your first developer job, you are probably already saying that I have been lucky and that things do not work this way anymore. But as someone that has helped many people find their first developer job and is still heavily involved in interviews, I can guarantee that this is still possible. When I look back at that young me, I can see something that still flows strong into my vein – Passion!

The similarities between me many years ago, and the apprentices that I currently interview or help is the willingness to succeed. If there is something that you have to get out of this post is this, your actual skillset and portfolio are just a very small portion of what is needed to get a job (and progress in your career) is the willingness to learn, the passion to succeed and ability to accept criticism. Never go into an interview expecting a company to give the job because “you are the guy”, or because “you know all that there is to know” because I can guarantee you that you will fail miserably. I am not saying that you do not know enough, but I can say that there is so much to learn that in 10 years I have personally just scratched the surface, so your few months of learning can surely not be a match (or at least is not a good attitude to start with 🙂 )

Junior developer – the biggest imposter in town

I still remember vividly that while I walked to my office for my first day as a developer, my legs were shaking uncontrollably. During the journey to the office, I could not stop but to think that I was a BIG imposter and that I managed to get the job by fooling the interviewer, but that I actually had no idea what I was meant to do and if I could even complete a simple task that day.

Unfortunately, this feeling is not an easy feeling to actually remove and it stayed with me for quite a long time. No matter how hard you work and how much you learn, the tech industry is so wide that you will easily find yourself in conversation or in tasks that are beyond your conform and the feeling of imposter will pop back in faster than you can even imagine.

If this is currently happening to you, I can guarantee you that it is totally normal and that you are not an imposter. A company never provides you with an opportunity because they expect you to be ready for your day to day job, but because of what you will be able to provide in the long run, it is an investment in who you are, not what you know right now! Take the time to learn, work hard and with time you will be able to control this feeling.

Unfortunately, Imposter Syndrome will actually be something that you can get rid of, but it will stay with you for the rest of your career. I personally still feel like an imposter on a daily basis on my job, but as I said before, with time you will be able to “control this feeling” and use it as a weapon to focus your learning and improve yourself.

There are many posts and books that cover imposter syndrome and I greatly suggest you get to know it a bit before you get started in your career. You will never be fully prepared, but the knowledge of it may help you alleviate the feeling! I found this blog post from Codementor to be a lovely resource to read: https://www.codementor.io/blog/imposter-syndrome-deypemtirw

Still a junior, new company

Just 6 months have passed since my first ever experience, and I started to feel ready for my next position. As a new developer, you will start to feel invincible, and think that there is nothing else for you to learn in your current position (or so I felt at the very start), so I decided to move on and progress in my career.

The following graph is a precise representation of how your career will work out (or at least the internal feeling):

https://medium.com/@victorcodes/flattening-the-learning-curve-as-a-software-developer-25b7954d84daIt was my first job, I got carried away and was naive with myself in expecting to know it all! When I found a new position and started my new job, I realised that I just knew what I was exposed to and that was not much at all. In my very first experience, I was just used to defining static HTML and CSS (simple ones with no form or nothing), but in my new position the scope of the technologies used grew more than 10 folds and I found myself back to that uncertainty zone with shaky legs.

The above graphs won’t just happen once, but they will happen over and over again in your career. The drop to “discouragingly realistic”, as scary as it sounds, is actually going to be the starting point to your next career growth. As the wise Socrates once said:

https://www.azquotes.com/quote/667157Finding things that you do not know and working to put them into practice, is the drive you need to succeed and improve.

Mid Developer – One of many

In this section, we are fast-forwarding a couple of years. I spent over 6 years in the same company, so this and the following sections will all take place in the same company. Even if I worked in the same company, the company growth and different projects have still provided me with many opportunities to go through the learning cycle that has been shared above.

At this stage, I was starting to control my fear of the unknown and have a good attitude toward failure. The main problem during this phase of my life was that I was just average, I was just “one of many” other developers. Coming down from the “hill of naive confidence” makes you realise that you are not special, and that is a big blow for someone as competitive as me.

There is nothing wrong with being an average developer and working your day to complete your goals. I have meet many fantastic developers that are happy to be in this place and have no incentive to move forward (unless due to time). I took a very different path, I worked toward a greater goal, I set myself a very hard and unachievable task and I worked hard day in and day out to succeed.

I still remember back in my mid-20s, I sat down with my wife and during a conversation I share my plan with her. At this point, I had just 2 years or so of experience and was well aware that I was still a junior and had lots to learn, but I told my wife “In 5 years, I a going to be the CTO of the company”.

Looking back at where I was and comparing it to where I am now, I can easily see that I was extremely naive (even if I achieved most of my goals as we will see later), but that small conversation was the base of my current success. What that promise did, was set the foundation for my learning strategy, it provided me with the strength necessary to stand up after failures.

I spent the next few years of my career focusing on what I did not know, learning from my peers, listening and taking notes. I repeated the above learning cycle over and over. I did not just do my work, but I also looked at what my superior did, I requested active feedback, I took my chances to move forward and as already mentioned I failed many times, but with perseverance also comes success.

This path that I call the “fast track” is not simple, and it is not what everyone is supposed to follow. But even if you do not do this at the same speed that I did, you may still want to take this as an example of what will be needed of you to progress further. It is true that after 4-5 years you may be called a senior (that is what I meant above when you move forward because of experience), but the truth is that if you REALLY want to move forward if you want to feel like a senior and remove that feeling of imposter within you, you have to master your skills, you have to push your boundaries and do this over and over.

Being a developer is not easy due to the nature of the tech industry, but being a good developer is even harder. Long story short I managed to become a tech lead and looked after over 40 developers in less than 5 years of experience. I did so with hard work and dedication and you can too.

Senior Developer – In control of my weakness

We are now 5 years into my career (halfway) and I am now what is called a senior developer (I felt like one and was called one), but I still had a long way to go. The tech career is not all around coding, and moving forward in the career ladder, will start to expose skills that are less “technical” and more “managerial”. Your expertise will be less driven by your ability to code, and more by your skill to lead.

When I became the tech lead, many people within my wide team were more experienced than me, and many others were more specialised than me, so I started to feel like an imposter again (yes, more learning to come for me). Luckily for me, I had the opportunity to be supported by great managers that really saw in me, what I could not see yet, and supported me all the way.

What I learned over time was that the main reason why I was given the opportunity to lead people was not related to my technical skills, but my attitude toward the wider team and learning. The scope of this is a bit too wide to just cover in a small chapter, but I am going to give you a small insight into what I have learned to have been my recipe for successful leading:

Be humble

I have not mentioned this in the previous chapter as I think it makes more sense to do it here, but being humble has helped me from my very first day and still does now. I never lie about my ability, and I am super clear about what I know and what I do not know. This not only clearly defined who you are to others, but it also provides a clean slate for you to be able to ask for help and reach out for new learning opportunities

Accept other people’s skills

I have seen many senior developers being too stubborn to accept being wrong and or accept not knowing something. In my career, I have actually done the opposite, no matter my position. I have actually always praised others’ speciality and openly trashed my suggestion/solution for one of my peers (at times even junior). This may sound similar to the previous point, but is just a consequence of it. In the previous one, I was happy to accept my weakness, here I am happy to accept other strengths.

Share your failure

The world is full of superheroes (thanks to marvel). Social media platforms are full of great stories of success (like this one maybe), but the trust is that I have always been very clear about my failure. I am happy to share that I am only a human and this really helped me to break up the wall between me and my colleagues.

Delegate

I have covered this point slightly above in my previous story, but I want to emphasise the importance of delegating. Your brain is just a muscle and there is no way for you to learn absolutely everything that passes your way, or even if you have the available memory to learn anything that there is to know, there may not be enough time for you to do so.

Knowing that these two resources are finite, it is very important that you work around them by trying to delegate what may not be important to you and focus on what really matters.

Speak for your audience

As you become a developer, chances are that you will be called a “nerd”.

https://www.geekwire.com/2013/study-women-choose-computer-science-careers-nerd-stereotypes/If this happens it does not mean that you look anywhere close to the above image, or that you have anything wrong, what this means is that you are not speaking the language of the people that are around you, and have bored them with things that they have absolutely no interest in.

I use the above description to explain the skills necessary to communicate effectively with people around you (either face to face or by email). No matter what meeting or conversation I have, I always ask myself these two questions:

Does the person on the other side of this conversation know what I am talking about?
Does the person on the other side of this conversation care about the subject that I am sharing?

If the answer is no to any of the questions above, then you should stop right now and try to change the way you express yourself to be more in line with the people around you. If you are attending a management meeting never talk about bugs and code smells, but turn this into “maintenance costs” and “code quality”, if you are talking with a junior developer do not use the complex terms, but provide simple examples to explain the situation.

I have been fortunate to have attended a management school that has thought me this and I can clearly say that it has been an invaluable asset.

Summary

Before we move to the next chapter, I am going to share just a few more words to provide a real-life example that encapsulates all the points above. In my initial time as tech lead I was challenged over and over (not all the seniors were happy with my position), and there is a single meeting that is clear in my mind:

We were having an architecture meeting attended by many managers and seniors. During this meeting, I was asked a specific question and require to come up with a solution to a problem. Instead, than give them a solution on top of my head, I clearly defined that I would prefer for a less experienced team member to help us here (mid developer so not part of this current meeting). My public call for help was confronted by a senior denoting to my managers that I was not meant to be in that position as I could not “fulfil” the role that was necessary for me. As you may imagine, I felt helpless and totally not in control (yes my legs started to shake, but I was sitting luckily). The only feeling I had was of total failure, I thought I was really an imposter and I should not have been there. But luckily (as I said before I had a great manager), my COO actually took over and replied “Simone is actually the right person for this job because he can accept his weakness, not the other way around”. This was a great eye-opening moment for me, I will cherish that moment for the rest of my life.

The big leap – Software Architect

I am realising that this post is getting very long, but 10 years are 10 years. So I am going to jump a little forward. In the previous chapter, I was enjoying my new power as a tech lead and worked toward many new skills necessary to succeed in that position, but the years have now passed and I have decided to move on. As we learned before moving company can be pretty traumatic as you are catapulted down to the “discouragingly realistic”, but I was ready for it and happy for a new challenge.

After 6 years in my company and around 4 as a tech lead, I decided to move forward and joined my current position as a Software Architect in This Dot (I was not an architect when I was employed but got promoted to one after a few months).

Here I am, with 7 years of experience and a long list of previous successes, scared again of a new challenge! Until now I have worked in local businesses around Wales, and moving to an international company opened a new set of “insecurity” within me….

What if people in Wales are actually not as good as the people oversees

How will I get help working remotely, how will I apply my existing skills

The above thoughts and many more twisted and turned in my head for many months until I finally started. At that moment I have started to realise something (of course seniority also helps here), that no matter the difficulties and challenges that I will be provided with, what matters the most is the willingness to succeed.

You may remember the above sentence, in fact, that was the same sentence I used to explain what makes a good candidate for a junior developer role! That same spark that I personally see in people’s eyes when they apply for their first job, the same one that I had many years ago, is the one and only real skill you need to succeed!

Since joining This Dot I have met amazing developers with CVs that make mine look useless, worked in great companies and delivered many great projects. I am still experiencing “imposter syndrome” from time to time and this is totally fine, but my 10 years of experience have opened my eyes and made me realise that no matter the challenges, in time, I will succeed.

Conclusion

We have now reached the end of this post. A post in which I have shared numerous instances of “shaking legs”, “failure”, great weakness and ongoing setbacks. As many people say, people usually see success as luck and or given, but I personally started from nothing and worked my way up. I worked hard for it, I did not just wait for the future to land on my legs, and that comes with a price (endless hours of learning and constantly working outside of my conference zone).

I have recently achieved another milestone in my career by writing a book that I wished I had when I first started my career. If you enjoyed the above post I suggest you get a copy (It is just 5$ with the following code – https://leanpub.com/beyond-coding/c/10-years-post ).

It is time to say goodbye and continue my career for another 10 years and see where that brings me. I have learned now that you never reach the end, and at every turn, there is a new beginning. May your career be as fruitful as mine and please reach out if there is any help that I can give you or comment below if you found this post useful.

How to use REST Client with Laravel authentication token

Mr_SC — Thu, 25 Feb 2021 00:13:29 +0000

In this post we are going to explain step by step how to use the Rest client visual studio code extension with Laravel.

What is REST client

Rest client is a Visual Studio code extension that enable the user to trigger HTTP request directly from your IDE.

The extension can be found in the Visual Studio code marketplace (https://marketplace.visualstudio.com/items?itemName=humao.rest-client) or by searching for it within VS code.

If you have ever used tools like Postman before, this is going to achieve a very similar result, with some added feature, that have convinced me to drop postman and start to use it in all my projects.

Pros on using REST client Vs Postman

It is free to use and has no string attached
The HTTP collection/files can easily be added as part of your source code and therefore are easy to share
The HTTP are written in code, make them simpler to understand (as we are developers)
The HTTP files are written, modified and run directly form your IDE

How to use it (the basic)

The homepage of the extension does a very good job at explaining in a few words how to make this extension work.

The steps are very easy:

Install the extension
Create a file with extension .http or .rest
Write a valid endpoint (https://zelig880.com)
click the “send request” button that appears on the request

That is all it needs.. as you can see, it is simple and powerful!

How to use it with authentication

Like with every hello word example, the real life is a bit more complicated and cruel.

The above example will work perfectly for all GET request that are open to the public and do not require any sort of authentication. But as we know that is not always the case.

In the following example I am going to cover the steps necessary to authenticate and use the authenticated token for request in a Laravel environment.

It is important to bear in mind, that the following example should work with most API that explicit a Bearer token authentication.

Our steps

The steps necessary to successfully send a POST request with token are:

Write a POST request to the Login page with username and password
Give a name on that request
Link the response of the Auth request to any other request that require the token

The actual code

In our first step we are going to create a request to the login controller of our Laravel app. In this example I am using a test username and password (the one used in the application seeder), but if needed, you can set this value as environment variables as displayed in the extension documentation.


POST https://localhost:3000/login
content-type: application/json

{
    "email": "test2@test.com",
    "password": "password"
}

In the above file we are introducing a couple of new aspect. Let’s cover them all to rovide a better understanding of the tool:

POST https://localhost:3000/login

In this line we are setting the URL that it is going to be using in the request, but this time we are also specifying the request type (in this case POST).

content-type: application/json

Next we define a request header. The extension allows you to enter all valid request header for your request, but in our case we just need to define the content type to be able to send the POST information.


{
    "email": "test2@test.com",
    "password": "password"
}

Last but not least, we are able to define the information that we want to send over the wire.

Sending this request will result (in case in which the username and password are actually correct), in a successful returning a code 200.

In our next step we are going to learn how to “save” the token returned within the above request, and easily use it in subsequent request.

Before we move on, we are going to make two changes to our request. We are first going to give it a name, using the syntax # @name auth, and then we are going to define a file environment to easily be able to manage my files

@baseUrl = http://localhost:3000
@email= test2@test.com
@password = password

# @name auth
POST {{baseUrl}}/login HTTP/1.1 
content-type: application/json;charset=UTF-8


{
    "email": "{{email}}",
    "password": "{{password}}"
}

It is now time to create a new request, this time taking full advantage of out “auth” request token.

A single HTTP file can have multiple request. I personally create one for each major endpoint of my API. To divide 2 request you just need to add ###


...previous request

###

GET {{baseUrl}}/secure/endpoint
Authorization: Bearer {{auth.response.body.token}}

The example above is requesting content from a secure endpoint that requires out bearer token to fully function.

As previously mentioned, we had named out first request with the name of auth. Doing so will allow us to just access the response of that request like a normal variable as shown here:

Authorization: Bearer {{auth.response.body.token}}

Conclusion

You are now able to create many HTTP file, and fully document your API. If you have any comment, or feedback to improve this article, please do not esitate to comment below.

How to use Props in VueJs

Mr_SC — Wed, 09 Dec 2020 23:27:39 +0000

In this post we are going to explain how to use properties using the VueJs framework. The post expect a basic understand on the framework itself and will not cover the basic configurations.

First and foremost, we should introduced what Properties are in VueJs. My definition of props is:

VueJs properties are variables (static or Dynamic) that can be passed to a component from its parent.

VueJs Props definition

Properties are not unique to VueJs, in fact if you have ever used any other framework such as RectJs or Angular you have surely used them before.

When creating a component based architecture ( that is provided by VueJs and other frameworks), you need to have a way to pass information between components. Properties offer just such a feature.

A simple example of a property is showed below. Properties in VueJs can either be static (if the property name is not prefixed by “:”), or they can be dynamic and therefore being driven by an existing variable (either Data or computed).

<template>
  <div id="app">
    <Basic 
      staicValue="static string"

      :dynamicFromData="myValue"
      :dynamicFromComputed="myComputedValue"/>
  </div>
</template>

<script>
import Basic from "./components/Basic";

export default {
  name: "App",
  components: {
    Basic
  }
,
  data(){
    return {
      myValue: "A special string"
    }
  },
  computed:{
    myComputedValue(){
      return `${this.myValue}, really special `;
    }
  }
};

In the above example we are passing variables using three different methods. Simple string, value passed from the data and finally a computed property. It is important to know that variable can have different values. They can be boolean, string, integer, arrays, object and even methods (even if I do not suggest to do this in Vue).

Props definition

It is now time to start and really define how powerful Props are in VueJs and what you can do to really make the most fo this feature.

The following example are going to increase in complexity, so if you want to see the final result and see what I would suggest to be a very complete implementation of properties you can just hump at the ed of the page where you will also find a link to codesandbox.

Basic Props – Array

As you will learn in this article, Properties can be quite complex. But VueJs always allows us to slowly learn its powerful skills.

In the following example we are going to define properties without specifying any of its core values. This method of declaring properties is not really suggested for development, and it should be avoided if possible.

export default {
  name: "basicProperty",
  props: ['basic', 'property2', 'property3']
};

In the above example we have declared 3 different properties, but they do not have any other information and the framework will not be able to know their type, if they are required, if they have a default value,etc.

Basic Props – Types

In the first example we have declared properties using a simple array of string. In the current code snippets, we are going to still keep things simple, but we will modify our declaration to be completed using an Object.

This small change, differently from the first example, will allow us to build up the complexity of our property overtime.

To be able to use the Object declaration, we also need to start and introduce a new feature of the Vue property “Type”.


export default {
  name: "basicObject",
  props: {
    value: String,
    age: Number,
    enabled: Boolean
  }
};

In the example above, we have declared 3 different properties. This time we have defined a type for each of them. As you well know, Javascript is a loosely types language, and type declaratorio is usually only achieved with the use of external tools such as typescript.

VueJs provide a simple type declaration integration with its Properties. This is quite powerful (as you will also see later when we introduce validator), as it can support the user of the component in making good use of its variables.

The available types are:

String
Number
Boolean
Array
Object
Date
Function
Symbol

If you pass the wrong type to a component, Vue will NOT render the component and provide you a well defined error message.

Basic Props – Required

So far we are able to define endless properties and also assign types to it. In this paragraph we are going to introduce another feature called “required”. This feature will allow us to define required (or optional) properties within our component.

Failure to provide a required property will result in an error and the component will not be rendered.

export default {
  name: "required",
  props: {
    value: {
      type: String,
      required: true
    },
    age: {
      type: Number,
      required: false
    }
  }
};

As you may have noticed, to be able to add further details to our property, we have been forced to change our propety to be an object itself.

If this is the first time that you look at this, it may look complicated, but if you continue to read things will soon start to make sense.

Providing a required string is very beneficial, as it will save you from having to write inline validation such as <div v-if="requireProp" :value="requiredProp" />.

Default

Adding a required props is great as it saves us the need to define lots of manual error checking, but what can we do if the value is not required?

Well, in this case we can use Default. In fact the use of default is actually suggested when the required flag is set to false. This will make sure that we are aware of the values that is being parsed by the template.

The default value must either be a nullable value, or it has to be in the correct type (so if a property is a string, the default need to be string too).


export default {
  name: "default",
  props: {
    value: {
      type: String,
      required: true
    },
    age: {
      type: Number,
      required: false,
      default: null
    },
    label:{
      type: String,
      required:false,
      default: "Your name is"
    }
  }
};

Before we move on, it is important for you to be aware that when declaring a default for Object or Array property, you will need to define it as a factory function:


    propObject: {
      type: Object,
      default: function () {
        return { message: 'hello' }
      }
    },
    propObject: {
      type: Array,
      default: function () {
        return ['blue', 'red', 'orange']
      }
    },

Please bear in mind that in years working in vue, I had to use the above very rarely, as it is not very common to have default complex types, as it is usually easier to use computed property to simplify the code.

Validator

Most of the components that you have probably seen around the internet and proposed in stack overflow, will probably have just the above mentioned features (type, required, default). In fact that is the most accepted props declaration.

In this section, I am going to introduce a very useful feature of the property called validator.

There are cases in which developer miss the opportunity to use Validator (I am usually guilty of this), by overthinking it and implementing complex computed properties. As with all the features mentioned so far, failing to pass the validator function will produce a nice and readable error ( much easier and safe that our own computed implementation.



export default {
  name: "Vaidator",
  props: {
    colour:{
      type: String,
      required: true, 
      validator: function (value) {
        return ['green', 'red', 'orange'].indexOf(value) !== -1
      }
    }
  }
};

The validator is declared as a function that will be fulfilled if its value returned is true. I usually would not suggest to add too much complexity into this, and make sure they include the minimum required logic.

Conclusion

VueJs is has gain great support for being so simple to use. But as shown in this article, it also provide its users with very powerful built in tools ready to be used.

Implementing properties as shown in this article, would really benefit your day to day development. A well defined implementation of properties (and all other features offered by Vue), not only will support you in speeding up development. It can also be used by error tools (like sentry) and/or other developers, but supporting them in using the component to its best.

Link to the codepen used to develop this article can be found here: https://codesandbox.io

DEV Community: Mr_SC

Introducing v-memo a new directive to improve your Vue 3 app performance

What does v-memo do?

A basic example of v-memo

Few examples

The wrong case

Managing updates

Use it in conjunction with v-for

Inadvertently stop the child component to trigger updates

Summary

The importance of vacation for your career

What is stopping you to go on holiday?

Everything will fall apart in my absence

Fear of not being needed on return

Vacation time

Set expectation

Try to switch off

Make screen time worth it

What the research says

Summary

What is the difference between v-show and v-if in Vue js

Show or hide an element

What is the technical difference between v-show and v-if

Why does it matter?

V-IF

V-SHOW

Possible side effects or issues caused by miss-use

$refs to available with v-if

The component is mounted multiple times

State is lost between renders

Summary

How to use Watch in Vue 3 with the Composition API

What are Watchers in Vue Js

Watchers and Vue Js lifecycles

What triggers a watch to be called

When is watch triggered

Real-life examples

Watch multiple variables and inline getter

Watch reactive objects – AKA DEEP

Immediate trigger – AKA immediate

Immediate watch

WatchEffect

Run after DOM manipulation – AKA Flush

Summary

Comprehensive guide on Watch in Vue 3

What are Watchers in Vue Js

Watchers and Vue Js lifecycles

What triggers a watch to be called

When is watch triggered

Real-life examples

Nested Keys

Deep

Immediate – eager

Flush

Summary

How to use $refs in Vue 3 with Composition API and Script Setup

What are $refs in Vue

When would you use $refs

How to use $refs with Composition API

Ref in Composition API example

Ref in Script Setup example

Why is the ref null in the setup function?

Summary

How to use Slots and Attrs with the Composition API

What are Slots and Attrs

Slots in Vue js

Attrs in Vue 3

How to access $attrs and $slot in the <template>

How to access Slots and Attrs using the Composition API

How to access Slots and Attrs using the script setup

Conclusion

The importance of Headings element for an accessible page

What are heading tags

The common mistake while using tags

Missing Heading

Use multiple H1

How to avoid heading misuse

Conclusion

How to use variables in CSS with v-bind in VueJs 3

Introduction – a real-life example

What does `v-memo` do?

A basic example of `v-memo`

What is the technical difference between `v-show` and `v-if`

When is `watch` triggered

When is `watch` triggered

How to access $attrs and $slot in the `<template>`