I was standing in the middle of a new office, laptop bag on my shoulder, surrounded by people who moved through the space with the easy confidence of people who knew where the bathroom was. My first day at a new company after 7 years at the same place. And my legs — my own legs, which had carried me faithfully through three decades of life — were quietly threatening to give out.

But I’m getting ahead of myself.

Home

For 7 years, I worked at the same company. Long enough that I stopped noticing the office smell. Long enough that I had opinions about which elevator was fastest. Long enough that the codebase, with all its quirks and legacy decisions and that one component nobody wanted to touch, felt like a place I genuinely knew.

I was a frontend developer, and I had a framework that just clicked for me — the kind where the mental model makes sense, where you stop thinking about syntax and just think about the problem. If you’ve had that with any tool in your career, you know what I mean when I say that leaving it felt a little personal.

But the offer was good. Better than good. And somewhere under the comfort and the familiarity, I knew it was time.

So I wrote a warm resignation letter (no reason stated — I’m a professional), gave a long notice period, and told myself I was ready.

The Decision I Couldn’t Stop Second-Guessing

Except — I almost didn’t go.

Before any of this, there was a period of time I can only describe as spreadsheet hell with feelings. I had an offer. A good one. And instead of just saying yes like a normal person, I spent weeks dissecting it from every possible angle.

The salary comparison. The tax implications. The benefits delta. The contract clauses — oh, the contract clauses. I read that thing like I was studying for an exam I couldn’t afford to fail. Notice periods, non-compete terms, probation conditions. I highlighted things. I asked questions. I asked more questions. I built mental models and then dismantled them and then rebuilt them slightly differently.

I told myself it was due diligence. And it was, partly. But if I’m honest, a lot of it was also just fear dressed up as analysis.

Because underneath all the numbers and clauses, the real question I kept circling was simpler and harder than any of them: what if I leave and it turns out I was wrong? What if the new place isn’t better — just different, and unfamiliar, and harder, and I’ve given up something I can’t get back?

I had built something at my old company. Not just skills or tenure, but a kind of rootedness. I knew the people, the politics, the unwritten rules. I knew which meetings actually mattered and which ones you could half-attend. That kind of knowledge takes years to accumulate and approximately one resignation letter to lose.

In the end, I said yes. Not because the uncertainty went away, but because I realized it wasn’t going to — and waiting for certainty that was never coming wasn’t a plan, it was just delay.

The First Morning

I wasn’t ready.

The new office was fine. The people seemed nice. My assigned buddy greeted me with the kind of patient energy that suggested he had done this before — walked a bewildered new hire through a codebase and survived to tell the tale.

He opened the repository.

I had been told the stack was different from what I was used to. I knew this going in. I had even, in the weeks before, watched a few tutorials. How different could it be, I had thought.

It was different.

The folder structure unfolded like a map of a city I’d never visited. Patterns I didn’t recognize. A monorepo so large it had its own weather system. Somewhere, a build process was running, and it was in absolutely no hurry.

I nodded along as he walked me through things. I said “ah, interesting” at appropriate intervals. I was performing the facial expression of a person who understood what was happening.

Inside, I was running on pure static.

The Dizziness

At some point in the afternoon, I stood up to get water and realized the room was tilting slightly.

Not dramatically. Not movie-style. Just… a quiet, persistent suggestion from my body that things were perhaps not entirely okay. My legs felt like they were borrowing confidence they didn’t have. My head was somewhere between present in this office and orbiting slowly above it.

I found a quiet corner — a stairwell, I think — and just stood there for a moment.

It’s funny, the things your body holds onto without telling you. I had spent weeks wrapping up projects, saying goodbyes, convincing myself this was just a job change. A normal, adult, career-growth kind of decision. But somewhere in the machinery of me, it had been registering something else entirely: you are leaving home.

And now, standing in a stairwell that smelled faintly of industrial cleaning products, my body was submitting its formal complaint.

Imposter in the Building

I went back to my desk. Opened the codebase again. This time with the specific energy of someone who has accepted that they are, temporarily, completely lost.

The imposter syndrome had arrived — as it always does — not dramatically, but matter-of-factly, like an uninvited guest who helps themselves to your fridge. These people all know what they’re doing, it said. You don’t even know what this component does. You’ve been faking it for years and today is the day everyone finds out.

I want to tell you I had some profound response to this. A mantra, maybe, or a stoic reframe.

What I actually did was eat a snack, drink some water, and ask my buddy a question I already half-knew the answer to, just to hear someone explain something in a way that made sense.

And then I asked another question. And another.

Slowly — not that afternoon, but over the days that followed — the map started to have landmarks. The patterns started to have logic. The new stack stopped feeling like a foreign language and started feeling like a dialect I was learning. I found the bathroom. I found the good coffee. I found, one conversation at a time, people I actually liked.

What I Know Now

Leaving somewhere you’ve spent years isn’t just a career decision. It’s a small kind of grief — quiet and easy to miss, but real. You’re not just changing jobs. You’re leaving behind colleagues who became friends, a codebase you understood deeply, a rhythm of days that had become second nature.

And when you arrive somewhere new, you don’t just feel like a beginner at the job. You feel like a beginner at existing there. Every small thing — where to sit, who to ask, how the meetings run — requires conscious effort that used to be automatic.

The dizziness, I’ve since decided, was just all of that landing at once.

It passed. Most things do.

And if you’re somewhere in the middle of your own version of this — standing in a metaphorical stairwell, legs uncertain, codebase incomprehensible — I’ll just say: drink some water. Ask the obvious question. Give yourself the two to four weeks it actually takes for a new place to start feeling like somewhere you belong.

You’ll find the bathroom eventually.

Still learning the new stack. Still occasionally nodding along. Getting better at both.

In React, Redux is often used to set the global state and the flow of changes. Likewise with Vue, which uses Vuex. Now, the use of Redux/Vuex is critical and cannot be separated because this global state is a common thing in today’s web apps.

When Vue introduced its latest version, one of the highlights of the feature was the Vue Composition API which was discussed in my previous article.

(Partially) Different Way to Build Component using Vue Composition API

We found that the composition API gives developers more freedom in creating components, including using reactive properties outside of the components. This article shares how we use the composition API as an alternative to Vuex in creating global state management.

Note: In this article, we use Vue 2 by using the vue-composition-api library. If you’re using Vue 3, this feature should be included.

For the implementation, we created a composable directory for the folder structure to hold all state files — can also name them with compositions. We use the use- prefix as a marker for naming the file that is the file used for state management.

Take, for example, the file useUser. The naming itself is unrestrained, but we try to use the prefix to signify that it is a composable file. In this file, we create a structure that is almost similar to Vuex. State for reactive properties, a method for changing state value, and a dispatch method.

That’s it! Now we can use userData in any component we need. We can also call the fetchUserData method of the component that requires it. Like Vuex, we want the state value to be changed only by this setUserData. To prevent the value of this state from changing outside the composable, we can add read-only to toRefs so that the value in this state cannot be changed outside this composable.

We will then use this file in one of the components we have created. In this example, we are trying to fetch user data from Github, then display it on the page.

Sharing Across Modules

Let say, your web apps is consist of several UI modules, as illustrated in the following simple diagram:

Suppose you find a condition where some of your modules require data from the same state. In that case, module A and module D need userData. We can create a composable in the UI container and then make the composable file a global property in your Vue application. Then, we can access it through a property statement using Vue.prototype.

Any module component that needs that data can access it via Context root.$useUser

Every time there is a change in the state data in the UI container, all module components that use that data will also be updated.

Conclusion

The Composition API provides flexibility in creating global states. We can also be creative and make custom functions with these composable files according to the needs of our application without sticking to the rules provided by Vuex. In fact, we can also make this composable as a substitute for mixins.

However, by using this method, it is still possible to mix and match with Vuex if needed. This is just an example of how we can create a global state and share it across multiple components — even modules without using Vuex.

In September 2020, Vue.js released their latest version, Vue 3, which gave us quite a lot of changes. Yet in this article, I will focus on one of the significant changes, namely the Vue Composition API. But before that, here’s a summary of some of the updates to Vue 3 and why we should give it a try.

Why Vue 3?

• Smaller + faster

• Improved Typescript support
• Composition API
• Multiple root nodes on template (we can only have one root on Vue 2)
• Multiple v-model on components
• Suspense
  component that renders fallback content instead of your component until a condition is met such as a loaded backend API
• Portal
  allows you to display blocks of code anywhere in the app (modals, notifications, etc)
• Provide/Inject

Vue Composition API

In Vue 2, we know about the Option API model that we have used frequently in creating Vue components. Then what is the Composition API? In short, all the reactive data, computed, watch, methods we use in the Option API are now wrapped inside a setup() function..

The Composition API is an alternative way of writing the logic behind our components. And it was introduced because we might face two main limitations or issues when building bigger Vue apps. In smaller and medium-sized apps, we will very likely never face those issues, but in bigger apps, we might face them. One of the issue is that the code that belongs together logically is actually split up across multiple options, data, methods, computed. Second issue is that re-using logic across components could be tricky and cumbersome.

ref

import { ref } from 'vue'

ref is used to create reactive properties such as to keep track of user input, or to create reactive variables or objects. ref is a wrapper object where the value of our property is stored in another property called .value. So, if we want to call our properties we should access it by typing propertyName.value

ref vs reactive

Apart from ref, we can also use reactive() to create a reactive property. We can use ref when the variables we create are in the form of strings, numbers, Boolean, etc. When dealing with objects, I recommend using reactive(). If we use ref, it will wrap our value inside the object .value. reactive() doesn’t wrap our object with values so we can immediately access it.

watchers

In Vue 2 we can only define one dependency if we use optional API, now we can define multiple watchers which return array. Here is the differences in how we define watchers in Vue 2 and Vue 3

Props with composition API

In Vue Option API, we could access props by typing this.propsName . But in Vue Composition API, we use props as a parameter inside the setup() method.

Emitting Custom Events using Context

There are cases when we need to emit data from child to parent. In Vue 2 we are familiar with using this.$emit(‘emitName’, data). But we can’t do this method in Vue 3, since we don’t have access to this in setup(). Thus, to emit events, we need to use a context object.
Context is the second parameter of setup(). When we try to see the contents of the context by doing console.log() there are 3 properties, namely attrs, emit, and slots. attrs are any fall through attributes you might have. slots gives you access top any slot data you might have in your component. emit is a function you can call to emit a custom event

Provide/Inject

We can use props when passing data from parent to child. Of course, it will be very easy if we pass data to a child that is only one level below the parent. But what if the component structure is like this?

We could either make child 1 receive props from the parent then pass the props data to child 2 or use state management. The first option seems to be inefficient since we add props in child 1 just to pass the data to the next children component — child 1 has nothing to do with the data. But there is another approach offered by Vue, namely by using Provide / Inject.

Provide / Inject is a capability where parent components can serve as dependency provider for all its children, regardless how deep the component hierarchy is.

It actually possible if you want to update the ref value in the child component but it is not recommended. You should always change injected values in the place where you provide them

To add reactivity between provided and injected values, we can use a ref or reactive when providing a value.

To ensure the data passed through cannot be mutated by the injected component, we can use readonly() when passing the data.

provide ('name', readonly(name))

Lifecycle Hooks

In Vue 2, we have, beforeCreate and created in the options API, and we could simply add those methods to our config object. How does this look like with the composition API? With the composition API, we don’t add those lifecycle hooks to our component config object anymore, instead we have functions which we can import from vue, which you can call inside of the setup() method. But for beforeCreate and created there actually is no equivalent, because these hooks are not needed here, because the setup() method basically runs at the same time beforeCreate and created ran in the past. So setup() replaces these hooks. Whatever you would have done in created or beforeCreate should be done in the setup() method itself. Now for beforeMount and mounted, it’s different. There we have the onBeforeMount and onMounted functions which can be imported from vue. For beforeUpdate and updated it’s similar and the same for beforeUnmount and unmounted.

Vuex 4.0

Vue 3 also changed the way we access the store since we don’t have access to this.$store in setup hook. To access the store within the setup hook, you can call the useStore function. This is the equivalent of retrieving this.$store within a component using the Option API.

To access the state and getters, we have to create computed references to retain reactivity, and to access mutation and action we could just simply use the commit() and dispatch() like we used to do in Vue 2.

We usually use mapGetters and mapActions in our components with the Options API. In Composition API we could use vuex-composition-helper by installing this package

First we import the useGetters and useActions, and then we create a constant which the name is the getter/action name — using object destructuring, and the last we expose the constant into our template. This way is easier to use when we are dealing with modules. So for example, if the incrementCounter is inside the counter modules, we could write it like this

const { incrementCounter } = 
useActions('counter',['incrementCounter'])

Summary

Here are the brief differences between Option API and Composition API

We no longer use data(), instead we use ref() and reactive() to create reactive properties. We don’t define methods but create and regular javascript function inside the setup() hook and then expose it to the template. We could have multiple watchers that return an array, and a lot more. You can find the complete documentation about Vue 3 and Vue Composition API here.