By default, Claude Code doesn't know the difference. Everything lives in ~/.claude, and switching accounts means logging out and back in — which means losing whatever session you were in the middle of. That's annoying enough in a terminal. It's worse when you're also using Claude Code through an IDE's agent panel and can't just pop open a second tab.

Here's how I set mine up to run both, fully isolated, so I never have to run /status to check which account I'm on ever again.

The fix: CLAUDE_CONFIG_DIR

Claude Code reads an environment variable called CLAUDE_CONFIG_DIR at startup. Point it at a folder, and that's where Claude Code stores its credentials, session history, and settings — instead of the default ~/.claude.

Give each account its own folder, and you get two fully independent Claude Code identities that never touch each other's data.

This used to be an undocumented trick — for a long time the only reference was a GitHub issue asking Anthropic to document it, with people using it anyway because it clearly worked. It's since graduated to officially documented status, multi-account use case and all.

Terminal setup

1. Create a config folder for each account

mkdir -p ~/.claude-personal
mkdir -p ~/.claude-work

2. Add shell functions

Drop these in your ~/.zshrc (or ~/.bashrc):

claude-personal() {
    CLAUDE_CONFIG_DIR=~/.claude-personal claude "$@"
}

claude-work() {
    CLAUDE_CONFIG_DIR=~/.claude-work claude "$@"
}

Reload your shell:

source ~/.zshrc

3. Log in to each one, once

claude-personal /login
claude-work /login

Each stores its credentials in its own folder. From here on, claude-personal and claude-work are two totally separate Claude Code instances — separate auth, separate conversation history, separate everything. You can even run them at the same time in separate terminals.

4. Don't share history between them

You'll find posts out there suggesting you symlink the two projects folders together so both accounts can --resume each other's sessions. I'd skip that. If your work account is only supposed to touch company repos, merging its session history with your personal one means company code and conversations end up sitting in the same directory tree as your personal projects — which is exactly the kind of thing that ends up in a dotfiles backup or a personal cloud sync without you noticing. Keep them separate.

Automatically summon the correct Claude

Nothing stops you from typing claude (personal) while sitting inside a work repo. It's just two commands; remembering which one to use is on you.

I never want to run my personal Claude in a work directory; I never want to run my work Claude in a personal directory. direnv solves this by setting the variable automatically based on which directory you're in:

# .envrc in the root of a company repo
export CLAUDE_CONFIG_DIR=~/.claude-work

direnv allow

Now cd-ing into that repo sets CLAUDE_CONFIG_DIR for you — plain claude just does the right thing. Keep .envrc out of the repo's history with a local, unshared ignore rule (don't touch the project's actual .gitignore — this is your workflow, not the team's):

echo '.envrc' >> .git/info/exclude

Doing the same thing in Zed's Agent Panel

If you're only using Claude Code from the terminal, you're done. If you're also using it through an IDE's built-in agent panel — I use Zed — there's an extra step, because the panel doesn't necessarily inherit your shell environment or your shell functions.

In Zed, the built-in Claude Agent is installed from the ACP Registry, and registry-installed agents are locked to a single instance — you can't just duplicate the entry under a new name and expect it to behave differently. Instead, add two custom entries that each launch Claude Code's ACP adapter directly, with their own CLAUDE_CONFIG_DIR:

{
  "agent_servers": {
    "Claude Agent (Personal)": {
      "type": "custom",
      "command": "npx",
      "args": ["@agentclientprotocol/claude-agent-acp@latest", "--acp"],
      "env": {
        "CLAUDE_CONFIG_DIR": "/Users/you/.claude-personal"
      }
    },
    "Claude Agent (Work)": {
      "type": "custom",
      "command": "npx",
      "args": ["@agentclientprotocol/claude-agent-acp@latest", "--acp"],
      "env": {
        "CLAUDE_CONFIG_DIR": "/Users/you/.claude-work"
      }
    }
  }
}

Now the Agent Panel's new-thread menu shows two named agents instead of one generic one. Pick the right one when you start a thread, /login each the first time, and you're set. This is honestly a little safer than the terminal aliases — you're explicitly picking an account from a list each time, instead of relying on muscle memory.

Usage cheat sheet

Wrapping up

• CLAUDE_CONFIG_DIR gives you fully isolated Claude Code accounts — separate credentials, separate session history — by pointing each one at its own folder.

• Don't symlink the two accounts' history together, even though it's tempting. It defeats the point of keeping them separate in the first place.

• Shell aliases solve this for the terminal, but they can't enforce anything — direnv can, if you want the switch to happen automatically instead of relying on memory.

• If you're also using an IDE's agent panel, check whether it actually inherits your shell environment. In Zed's case it doesn't, so the account split needs to be configured separately as two named agent_servers entries.

onClick={handleClick}

onClick={() => handleClick()}

Understanding the difference and when to use which pattern is a common point of confusion. Let’s unpack what’s really going on, and what React is doing with the function you give it.

Function Reference vs Function Call

JavaScript has first-class functions, meaning they can be called with () or passed around as variables (without ()). Let’s illustrate this with a simple function:

function sayHi() {
   return "hi";
}

sayHi(); // "hi"

// or we can pass a reference to this function into another function:
function greet(fn, name) {
  console.log(fn() + " " + name);
}

greet(sayHi, "Joe"); // "hi Joe"

In the greet function, we’ve passed a reference (without parentheses) to the sayHi function. This sayHi function is then called (with parentheses) when the greet function is invoked. The key idea is:

• sayHi → “Here’s the function.”

• sayHi() → “Run the function now.”

What React does with onClick

React expects a function reference, not a function call. For example:

<button onClick={sayHi}>Click</button>

React will store the reference to the sayHi function so that later, when the button is clicked, it will run sayHi(event). This is the normal, intended way to tell React to run a function when the button is clicked.

If instead you wrote:

<button onClick={sayHi()}>Click</button>

you would see the sayHi function run immediately when rendered instead of waiting for the click.

Arrow functions

It’s also common to use arrow functions in React event handlers. Let’s illustrate this example using the greet function from earlier:

function greet(name) {
  alert(`Hello, ${name}!`);
}

function GreetingExample() {
  const [name, setName] = useState("");

  return (
    <div>
      <input
        type="text"
        value={name}
        placeholder="Enter your name"
        onChange={(e) => setName(e.target.value)}
      />
      <button onClick={() => greet(name)}>Click</button>
    </div>
  );
}

This function needs to pass an argument, name. But we can’t write it like this:

<button onClick={greet(name)}>Click</button>

because that would call greet(name) immediately during render, not when the user clicks.
The arrow function solves this by giving React a function reference: a small wrapper function that React can call later when the click actually happens. In this pattern, the arrow function creates a new function each render, but that’s perfectly fine for most cases. Here’s how that happens step by step:

1. React renders the button and stores the arrow function as the click handler.

2. When the button is clicked, React runs the arrow function.

3. The arrow function then calls greet(name) with the latest name value.

Pop quiz moment — what would happen if you tried this:

<button onClick={() => sayHi}>Click</button>

If you thought “nothing,” you are correct! Nothing would happen in this example because the arrow function receives a reference to sayHi, but does NOT invoke it!

Analogy

Think of this like giving React your phone number.

• onClick={fn} → You give React your number. React dials it later.

• onClick={fn()} → You dial the phone number right now, and give React the result of the call.

• onClick={() => fn} → You give React a note that says “here’s the number" — but the number is never dialed, and React never makes the call.

When to use which

Wrapping up

React doesn’t magically call functions — it simply calls whatever function reference you hand it when an event occurs. Understanding that difference between a function reference (fn) and a function call (fn()) explains nearly every “why doesn’t my onClick work?” moment.

When in doubt:

• Pass a function reference when you just need to call it later.

• Use an arrow function when you need to pass arguments or do extra work.

• Never call the function directly inside JSX unless you explicitly want it to run during render (rare!).

Objects, Classes, and Class Objects

Let's start with some fundamental truths:

• Instances of a class are objects.

• A class itself is an instance of Class.

• Since classes are objects, they can have their own methods.

Objects are instances of a class

class Dog
end

fido = Dog.new
puts fido.is_a?(Object)  # => true

Every object in Ruby inherits from Object, so even instances of Dog are objects.

Classes are objects too

puts Dog.is_a?(Class)  # => true
puts Dog.is_a?(Object) # => true

Since Dog itself is an instance of Class, it is both a class and an object at the same time.

Instance Methods vs. Class Methods

Instance methods are methods that belong to a specific instance of a class and operate on that instance’s data, whereas class methods belong to the class itself and can be called without creating an instance.

Defining an Instance Method

class Dog
  def wag
    :instance_level_wag
  end
end

fido = Dog.new
puts fido.wag  # => :instance_level_wag

Here, wag is an instance method. Each instance of Dog (e.g., fido) can call this method.

Defining a Class Method

There are multiple ways to define class methods:

Using self.method_name

class Dog
  def self.class_method
    :dogs_class_method
  end
end

puts Dog.class_method  # => :dogs_class_method

By using self. inside the class definition, we define a class method directly on Dog.

Using class << self (Singleton Class Syntax)

class Dog
  class << self
    def another_class_method
      :still_another_way
    end
  end
end

puts Dog.another_class_method  # => :still_another_way

This technique defines class methods using the singleton class, which is a special, hidden class that Ruby creates for each object to hold methods specific to that object. A singleton class (also called a metaclass or eigenclass) is unique to each object and allows defining methods that only that particular object can access. In this case, class << self opens up the singleton class of Dog, allowing us to define methods that belong only to the Dog class itself.

For example:

class Dog
  class << self
    def bark
      'Woof!'
    end
  end
end

puts Dog.bark  # => 'Woof!'

This is equivalent to:

class Dog
  def self.bark
    'Woof!'
  end
end

puts Dog.bark  # => 'Woof!'

Singleton methods can also be applied to individual instances:

fido = Dog.new

def fido.speak
  'Arf!'
end

puts fido.speak  # => 'Arf!'

However, this method is only available to fido, not other instances of Dog.

Singleton Methods on Objects

Since everything in Ruby is an object, we can define methods on individual instances:

fido = Dog.new

def fido.wag
  :fidos_wag
end

puts fido.wag  # => :fidos_wag

However, this method only applies to fido, not other Dog instances:

rover = Dog.new
puts rover.wag  # => NoMethodError

Class Instance Variables vs. Instance Variables

Instance variables inside a class belong to instances of that class, whereas instance variables inside the class definition itself belong to the class object.

class Dog
  attr_accessor :name
end

def Dog.name
  @name
end

fido = Dog.new
fido.name = "Fido"

puts fido.name  # => "Fido"
puts Dog.name   # => nil

The instance variable @name on fido does not affect Dog because Dog.name refers to an instance variable on the class object, not on an instance.

The Value of self in a Class Definition

Inside a class definition, self refers to the class itself:

class Dog
  puts self  # => Dog
end

Since self refers to the class, we can define class methods like this:

class Dog
  def self.class_method2
    :another_way_to_write_class_methods
  end
end

puts Dog.class_method2  # => :another_way_to_write_class_methods

Returning Values from Class Definitions

In Ruby, the last expression inside a class definition determines its return value:

LastExpression = class Dog
                   21
                 end

puts LastExpression  # => 21

For example, this behavior can be used in metaprogramming to dynamically define constants or class-level settings based on computations performed within the class definition:

DefaultLimit = class Configuration
                 100 * 2
               end

puts DefaultLimit  # => 200

Here, the last evaluated expression (100 * 2) is returned and assigned to DefaultLimit.

Calling Class Methods from Instances

Although class methods belong to the class, instances can still access them indirectly:

fido = Dog.new
puts fido.class.another_class_method  # => :still_another_way

This works because fido.class evaluates to Dog, and Dog.another_class_method is a valid class method.

Which Class Method Syntax Should You Use?

Both of the following approaches work for defining class methods:

class Demo
  def self.method_one
  end

  class << self
    def method_two
    end
  end
end

Which one should you prefer?

• self.method_name is more common and easier to read. This is usually what you should do.

• class << self is useful when defining multiple class methods at once.

Hopefully this post has clarified some key concepts in this chapter of the Koans. As you continue your Ruby journey, may you keep in mind (my personal favorite axiom from the test output): mountains are merely mountains.

Prerequisites

• Basic knowledge of Vue.js

• Node.js and npm installed

• Vue 3 with Composition API

Step 1: Set Up a New Vue Project

First, let's create a new Vue project using Vite:

npm create vite@latest timezone-clock -- --template vue
cd timezone-clock
npm install

Step 2: Install Required Dependencies

We'll use dayjs for timezone handling:

npm install dayjs

Understanding Timezone Handling

Before we dive into the code, let's break down why we need additional libraries for timezone management:

• JavaScript's native Date object doesn't provide robust timezone conversion

• dayjs with its UTC and timezone plugins allows easy, accurate timezone transformations

• The plugins extend dayjs's capabilities to parse, manipulate, and display times across different timezones

Step 3: Create the Timezone Clock Component

Create a new file TimezoneClock.vue in your src/components directory:

<script setup>
import { computed, ref, onBeforeUnmount } from 'vue';
import dayjs from 'dayjs';
import utc from 'dayjs/plugin/utc';
import dayjsTimezone from 'dayjs/plugin/timezone';

// Define component props
const props = defineProps({
  timezone: {
    type: String,
    required: true,
  },
});

// Extend dayjs with UTC and timezone plugins
dayjs.extend(utc);
dayjs.extend(dayjsTimezone);

// Reactive reference to current time
const currentTime = ref(new Date());

// Function to update current time
const updateCurrentTime = () => {
  currentTime.value = new Date();
};

// Computed property to format time in specified timezone
const formattedTime = computed(() =>
  dayjs(currentTime.value).tz(props.timezone).format('h:mm a z')
);

// Set up interval to update time every second
const updateTimeInterval = setInterval(updateCurrentTime, 1000);

// Clean up interval when component is unmounted
onBeforeUnmount(() => {
  clearInterval(updateTimeInterval);
});
</script>

<template>{{ formattedTime }}</template>

Key Concepts Explained

1. Props and Component Configuration

• defineProps() creates a prop called timezone

• required: true ensures a timezone must be provided when using the component

• Prop is typed as a String to accept timezone names like "America/New_York"

2. Reactive Time Management

• ref(new Date()) creates a reactive reference to the current time

• updateCurrentTime() updates this reference

• setInterval() calls this function every second, creating a "live" clock

3. Time Formatting with dayjs

• dayjs().tz() converts the current time to the specified timezone

• .format('h:mm a z') displays time as:

  • h: Hour in 12-hour format

  • mm: Minutes

  • a: AM/PM indicator

  • z: Timezone abbreviation

4. Cleanup with onBeforeUnmount

• clearInterval() stops the timer when the component is removed

• Prevents memory leaks and unnecessary background processes

Step 4: Using the Component

In your App.vue, demonstrate the component:

<script setup>
import TimezoneClock from '@/components/TimezoneClock.vue';
</script>

<template>
  <div>
    <div>
        <h1>World Clocks</h1>
        New York: <TimezoneClock timezone="America/New_York" />
        <br />
        <br />
        London: <TimezoneClock timezone="Europe/London" />
        <br />
        <br />
        Tokyo: <TimezoneClock timezone="Asia/Tokyo" />
  </div> 
 </div>
</template>

Advanced Tips

• Always use IANA timezone names (like "America/New_York")

• Handle potential timezone name errors with a default fallback

• Consider adding props for custom date formatting

Conclusion

You've now created a flexible, reactive timezone clock component in Vue.js. By leveraging dayjs and Vue's Composition API, we've built a powerful time display solution that's both performant and easy to use.

Learning Challenges

1. Add a prop to customize the time format

2. Implement error handling for invalid timezones

3. Create a timezone selector feature

Happy coding! 🕒✨

1. On your hotfix branch, run git rebase develop .

2. You may see merge conflicts. These may need to be resolved. You will need to use your best judgement here, as it is always specific to the codebase and the branch. In my experience, I see this really commonly with database schema updates.

3. After you resolve conflicts, DO NOT push/pull.

4. Check out main and git pull to make sure you have the most up-to-date changes there.

5. Back on hotfix branch, run git rebase --onto main develop. This is saying: git rebase --onto <new-branch> <old-branch>.

6. You'll probably see some diff in the push/pull section. Don't pull.

7. Instead, force push: git push origin hotfix --force.

8. If you already have a PR open for this branch, you may see a bunch of commits that don't belong to you. In GitHub (or wherever your code lives), you will need to point the merge branch toward main. The commits that don't belong to you should disappear, and only your commits should be left.

9. If you don't have a PR open already, open one to main.

To rebase a hotfix branch from develop to main, first rebase onto develop and resolve any conflicts. Then, update main and rebase the hotfix branch onto main. Finally, force push the changes and adjust any open PRs to point to main.

Here's what to expect if you're getting started on your Ruby on Rails journey.

There is a learning curve

Ruby looks and behaves differently from any other programming language I've dealt with. At first, it can be very difficult to look at a bit of Ruby code and understand what is going on. You will see symbols all over the place, which can be a big concept to wrap your head around. (:symbols look :like_this.) Hashes are sort of like objects in JavaScript, but not really. ({ :key => 'value' })

One of the biggest reasons for the learning curve is that...

There are many ways to do things

You can push things into an array like this:

array = Array.new
array.push(1)
# OR
array << 1

You can call a method with or without parentheses:

def my_global_method(a,b)
  a + b
end

...

def test_calling_global_methods
  assert_equal 5, my_global_method(2,3)
end

def test_calling_global_methods_without_parentheses
  result = my_global_method 2, 3
  assert_equal 5, result
end

You can even iterate through an array with a completely different syntax:

  def test_iterating_with_each
    array = [1, 2, 3]
    sum = 0
    array.each do |item|
      sum += item
    end
    assert_equal 6, sum
  end

  def test_each_can_use_curly_brace_blocks_too
    array = [1, 2, 3]
    sum = 0
    array.each { |item| sum += item }
    assert_equal 6, sum
  end

The examples above were taken from the Ruby Koans. These exercises are hands down the best way to get familiar with the way Ruby works. If you are an aspiring Ruby developer, start here.

Community is key

Finding good documentation or tutorials for Ruby or Ruby on Rails can feel like hunting through an ancient library for esoteric forbidden knowledge. There is a lot of garbage out there, a lot of outdated information, and a lot of different viewpoints. More than any other language I've worked in, it is important to find resources and people who you trust. Your best resource will most likely be the development team you are working with.

Here are some resources I suggest:

• RailsGuides

• RubyGuides

• SuperHi Ruby on Rails course

Everything is an object

Another example from the Koans...

  def test_everything_is_an_object
    assert_equal true, 1.is_a?(Object)
    assert_equal true, 1.5.is_a?(Object)
    assert_equal true, "string".is_a?(Object)
    assert_equal true, nil.is_a?(Object)
    assert_equal true, Object.is_a?(Object)
  end

In Ruby, everything is an object. This is part of the magic.

In Practical Object-Oriented Design, author Sandi Metz describes the world as object-oriented:

The objects with which you interact might include a spouse and a cat, or an old car and a pile of bike parts in the garage, or your ticking heart and the exercise plan you use to keep it healthy. Each of these objects comes equipped with its own behavior, and while some of the interactions between them might be predictable, it is entirely possible for your spouse to unexpectedly step on the cat, causing a reaction that rapidly raises everyone's heart rate and gives you new appreciation for your exercise regimen.

...

Failures of OOD [object-oriented design] might look like failures of coding technique, but they are actually failures of perspective.

Coding in Ruby and working with Rails will give you a whole new perspective. It's been quite the journey, and I still feel like I'm at the very beginning of a whole new world.

In your sass file, provide an :export object:

:export {
  Red: $red;
  Orange: $orange;
  Deepyellow: $deepyellow;
  Canary: $canary;
  Black: $black;
}

Then, in your Vue component, you can import these styles:

import styles from '@src/styles.scss';

You can then access these styles throughout the Vue component. In my case, I needed to set colors in data() like this:

data() {
   return {
      eventDataTransform: eventData => {
          return {
              title: eventData.title,
              start: eventData.start,
              end: eventData.end,
              borderColor: styles.Black,
              textColor: styles.Black,
              color: styles.Canary,
          }
     }
},

If you have a ton of variables in your styles.css file, you might not want to import all of them. You can import just the ones you need like this:

import { Black, Red } from '@src/styles.scss';

text.replace(/\p{P}/gu, "").split(" "))

To break this down:

• text: the string to parse
• .replace: a JavaScript function
• /\p{P}/gu, "": regex that informs replace to remove all punctuation and replace it with nothing
• .split(" "): a JavaScript function that breaks a string into an array based on the character passed into the function. In this case, it will split the string whenever there is a space.

1. :sync to a metronome

Keep your live loops in sync by creating a metronome:

live_loop :click do
  sleep 1
end

Use :sync to keep all your loops together with the :click:

live_loop :kick, sync: :click do stop
  sample :bd_808
  sleep 1
end

2. move things along with .tick

Increment the default tick by 1 and return value. Successive calls to tick will continue to increment the default tick.

.tick is a handy shorthand for playing melodies. Essentially, it can be used to "tick" through an array of values, moving to the next item in the array on the next repeat.

Let's say you have a simple melody consisting of four notes: [:c3, :a2, :c3, :e3]

You can play these notes in order using tick:

play [:c3, :a2, :c3, :e3].tick

I also like to use this to set sleep values for varied but predictable rhythms:

sleep [0.5, 0.75, 0.25, 0.25, 0.5].tick

3. make the computer .choose for you

IMO, randomization is probably the most important aspects of creating algorithmically generated music. .choose is a simple way to get the computer to "choose" something for you. It will randomly pick a value from the provided array. Here is an example of a bassline I created with this method:

live_loop :earth, sync: :met do
  with_fx :echo do
    use_synth :beep
    play [:c3, :a2].choose, attack: 2, decay: 3, release: 2
    sleep 6
  end
end

You'll never know if this is going to play a C or an A until it actually happens -- it really helps add a mysterious, unpredictable, and constantly evolving vibe.

4. dice things up

Throws a dice with the specified num_sides (defaults to 6) and returns the score as a number between 1 and num_sides.

More randomization! Instead of choosing from a set of pre-specified values, this function literally acts like a throw of a die.

I like to use this to trigger random percussion samples to add some ear candy or variation to the beat.

live_loop :perc do
  if dice == 1
    with_fx :ping_pong do
      sample :perc_snap, amp: 0.5
    end
  end
  sleep 1
end

5. Get Euclidian with spread

Creates a new ring of boolean values which space a given number of accents as evenly as possible throughout a bar.

Ok this one is sick AF. This will create Euclidian rhythms based on the parameters provided. Essentially, this is a fancy way of saying that x number of notes will be spread as evenly as possible across y number of beats. This concept is named after the ancient homie Euclid, who described the mathematical relationship performed here.

This is a super easy way to generate interesting polyrhythms:

live_loop :bd do
  sample :bd_808 if (spread 2, 5).tick
  sleep 0.25
end

This will perform two kicks across the space of 5 sixteenth notes. There are so many cool possibilities to find here by rearranging these numbers. Just go play around with this one and make some IDM. Have fun!

Vue Reactivity

Data is passed into a Vue component as a JavaScript object. Vue adds getter and setter functions to this object. Whenever this data changes, Vue will trigger either the getter function to collect this change as a dependency, or a setter function to notify the component that something has changed.

"Every component instance has a corresponding watcher instance, which records any properties “touched” during the component’s render as dependencies. Later on when a dependency’s setter is triggered, it notifies the watcher, which in turn causes the component to re-render." - https://vuejs.org/v2/guide/reactivity.html

You can learn more about this with this free lesson on Vue Mastery.

Where does $nextTick() fit in all this?

Here is the definition of nextTick straight from the proverbial horse's mouth:

Vue.nextTick( [callback, context] ) Arguments: {Function} [callback] {Object} [context] Usage: Defer the callback to be executed after the next DOM update cycle. Use it immediately after you’ve changed some data to wait for the DOM update. -- https://vuejs.org/v2/api/#Vue-nextTick

Say what? Let's break this down.

Vue.nextTick: This indicates that nextTick is a property on the Vue instance.

( [callback, context] ): The callback is the name of the function to execute on the next tick. The context is the detail inside the function's curly brackets that define what the function should do.

Defer the callback: Wait to perform this function

to be executed after the next DOM update cycle: Until the next DOM update cycle. (The DOM update cycle is the loop displayed in the image above.)

Use it immediately after you've changed some data to wait for the DOM update.: This is the most important part of the concept of nextTick. Its usefulness lies in the fact that it can delay something until the DOM has re-rendered, ensuring that this callback function will run with the latest data.

Vue's reactivity system does a great job of keeping data updated, but nextTick is like a surgical scalpel that allows you to cut into the DOM update cycle and execute very granular control over it. It's not a tool you'll need every day, but it is a good thing to have on the table. If you ever get an error like Uncaught (in promise) DOMException, nextTick might be what you use to resolve it. Essentially, what nextTick says is:

"Wait until this current thing is done before executing this other thing."

Check out the resources below for code examples of how nextTick works.

Resources

• https://vuejsdevelopers.com/2019/01/22/vue-what-is-next-tick/
• https://vuejs.org/v2/guide/reactivity.html
• https://vuejs.org/v2/api/#Vue-nextTick
• https://blog.logrocket.com/understanding-nexttick-in-vue-js/