Forem: code plato

[Enterprise Git Workflow Best Practice] Use a Sub-Project Branch When Developing Large Features

code plato — Sat, 22 Mar 2025 20:15:47 +0000

In a large project team, when developing major features, we may assign a few people to form a sub-project team. From the perspective of the overall project, this temporary group is working on a single, independent feature as a whole. However, within the temporary project, each member has their own sub-feature development tasks.

In this case, individual developers should not commit their code directly to the main development branch, such as develop . Instead, a sub-project branch should be created. Each team member commits their code to the sub-project branch first, and at a designated point in time, the sub-project branch is merged into the main development branch.

Terminology Definitions

feature branch: A Git branch created when developing a new feature. Normally, only one person commits to this branch. You can also think of it as a personal branch. It is often named feature/<feature-name> or feature-<feature-name>

sub-project branch: When developing a large feature, a sub-project team consisting of several developers is formed. In this case, a larger development branch can be created for this sub-project. This branch can span multiple sprints. The sub-project developers first commit their changes to the project branch, and at a certain point in time, the project branch is merged into the main branch. The project branch can be named feature/<sub-project-name>-<creation-date>.

Mistakes We Made with Sub-Project Branch

Before writing on this topic, I assumed the use of sub-project branch was self-evident. However, after our team encountered several issues while using sub-project branches, we considered abandoning them. This led to even more problems, making me truly understand the importance of sub-project branch. As expected, the most profound realizations often come through mistakes.

Below are the reasons we abandoned project branches. However, these reasons actually stemmed from incorrect usage rather than inherent flaws in project branches. Therefore, I will list the problems we encountered, along with the real causes.

Project branches made the code messy: We had different versions of components across different project branches.
- Real Cause: Excessive development branches led to code management chaos, especially when many branches remained unsynchronized for long periods, making the overall code structure complex.
Frequent conflicts during merges: Every time we merged a project branch, we encountered numerous conflicts that were difficult to resolve. Sometimes, new bugs were introduced while resolving conflicts, such as accidentally deleting correct code.
- Real Cause: Long periods without synchronization caused excessive conflicts during merging, increasing the effort required to resolve them. The correct approach is to synchronize from the develop branch to the sub-project branch regularly.

In reality, these issues were not intrinsic to project branches themselves.

Necessity of Sub-Project Branch

Below are the key reasons for using project branches and best practices for managing them properly.

Check for conflicts before merging: Fix the conflicts on the PR before merging.

Evaluate the testing process: Notify the testing team before merging and ensure they have enough time to conduct tests.

Significantly reduce the difficulty of reverts: If a branch contains only a single change, it minimizes coupling issues with other functionalities.

Run automated tests on the project branch: Write sanity tests specifically for the branch to ensure feature reliability before merging.

The develop branch is used more widely than you think: The develop branch is not just for some engineers—others, including different engineering teams, may also rely on it.

Even testers and product managers might use the develop branch.

Conclusion
Using project branches can maximize release stability, improve code traceability, enhance testing efficiency, and facilitate better team collaboration.

Best Practices for Using Sub-Project Branch

Daily synchronization: Keep merging the develop branch changes to Sub-project branch to avoid excessive conflicts.
Keep sub-project branches short-lived: Sub-project branches should not exist for too long (no more than 3 sprints).
Squash merges: Use squash & merge when merging code to make all commits in 1 commit. Cause from the perspective of the develop branch, this feature should have only one or a few commits.

Keep it clean: Delete the sub-project branch after merging to prevent unnecessary future commits.

The Bicycle-shed effect

code plato — Wed, 05 Mar 2025 19:50:05 +0000

The Definition

The Law of triviality as known as the bicycle-shed effect. Quote from wiki page:

The law of triviality is C. Northcote Parkinson's 1957 argument that people within an organization commonly give disproportionate weight to trivial issues.[1] Parkinson provides the example of a fictional committee whose job was to approve the plans for a nuclear power plant spending the majority of its time on discussions about relatively minor but easy-to-grasp issues, such as what materials to use for the staff bicycle shed, while neglecting the proposed design of the plant itself, which is far more important and a far more difficult and complex task.

The law has been applied to software development and other activities.[2] The terms bicycle-shed effect, bike-shed effect, and bike-shedding were coined based on Parkinson's example; it was popularized in the Berkeley Software Distribution community by the Danish software developer Poul-Henning Kamp in 1999[3] and, due to that, has since become popular within the field of software development generally.

What do we use it?

Here are some examples:

☎️ Don’t get too hung up on details during a meeting. For example, don’t argue over the details of the prompts that should be displayed for this feature. Don’t even waste time on technical details. Meeting time is for everyone, not just a few people.
🖱️ When searching for information on the Internet, don't be distracted by interesting little bits of knowledge, or even Google them. Try to be patient with your curiosity.
📦 When developing a feature or product, don’t waste too much time polishing it before the first release. Fine-tune it after the release.
🗄️ When using the four-quadrant work method, try not to waste time on urgent but unimportant tasks. Once you have solved a problem, move on to the next one and do not extend the time for that problem.

[Copilot Extreme Practice Journal] DAY 1: Using Copilot to Generate Unit Tests Without Writing a Single Line of Code

code plato — Tue, 04 Mar 2025 05:13:52 +0000

This series is called "Extreme Practice" because I don't know if this is the best practice. I am currently trying to push ChatGPT to the extreme, meaning almost all actual coding and writing tasks are delegated to ChatGPT to see how much efficiency can be improved—or decreased.

Terminology Introduction

`Copilot`

Copilot is a chatbot developed by Microsoft that utilizes ChatGPT. You can consider it a wrapper around ChatGPT. It allows you to switch between different models, including Gemini, Claude, and ChatGPT.

`GitHub Copilot`

GitHub Copilot is an AI coding assistant that integrates Copilot into GitHub.

`GitHub Copilot VSCode Plugin`

GitHub has developed a Copilot plugin for GitHub. This plugin enables programmers to use Copilot within the IDE by connecting it to GitHub Copilot. It currently supports VSCode and IntelliJ.

Task Requirements

Generating unit tests for UI components is always a painful task. Testing pure logic functions is straightforward—you just pass in parameters and verify the output. However, testing components requires setting up many variables needed for component loading and passing them to the component in different ways.

Today is the first day of practice. I attempted to use Copilot to generate a unit test for the Vue component BenefitsAccordion. The requirements are as follows:

⏳ Must be completed within 30 minutes.
✅ The generated unit test must pass.
🏆 The unit test must follow good coding practices.
🙅‍♂️ I should not write any code; the task should be completed through conversation only.

Execution Process

I will use ✅ and ❌ and 🤔 to show how it is doing.

If it work as my expect. I will give it a ✅
If it doesn't work as expect. I will give it a ❌
If I don't know whether it works well or not, I will give it a 🤔

Step 1: Initial Generation of Test Cases ✅

I opened the Copilot Edits panel:

I selected the file and told it:

/tests generate unit test for this file

It generated a test file, but it did not recognize that my codebase is a monorepo (Monorepo vs Multi-repo vs Monolith). The generated test file should be placed in the corresponding sub-repository.

Step 2: Moving the Test Case ❌

I instructed it to move the unit test to apps/<sub-repo>/tests/unit. So I said:

@workspace app/xxx has its own tests folder. Move the unit test you just generated to that folder instead of tests/unit.

It agreed and moved the file, but placed it in the root directory /tests/unit, which is incorrect.

Step 3: Moving the Test Case Again ✅

Since test cases should be placed according to the structure of the System Under Test (SUT), I said:

Don't put it in the root of apps/ms/tests/unit. Place it according to the source code file structure.

This time, it got it right:

Move the unit test file for the BenefitsAccordion.vue component to the apps/ms/tests/unit/components/xxx/xxx folder to match the source code file structure.
But there were many errors

Step 4: Attempting to Fix the Test Case ❌

I asked it to fix the errors in the unit test file:

Fix the errors in the unit test file BenefitsAccordion.spec.ts.

It responded:

Fix the errors in the unit test file for the BenefitsAccordion.vue component.

However, the errors remained unchanged.

Step 5: Directly Telling It How to Fix the Errors ✅

The errors were basic—missing imports for Vitest functions like describe and beforeEach. I explicitly pointed this out:

The errors in BenefitsAccordion are because you didn't import describe, beforeEach, etc., from Vitest.

This time, it understood:

Fix the errors by importing describe, beforeEach, it, and expect from Vitest.

Step 6: Specifying Which Methods to Test ✅

It generated some unhelpful test cases, such as it should render ..., which I consider meaningless. So, I told it explicitly:

/tests in BenefitsAccordion.spec.ts, only generate unit tests for methods xxx, xxx, xxx, xxx, xxx, xxx. Remove other tests.

It responded correctly:

Generate unit tests only for the methods xxx, xxx, xxx, xxx, xxx, and xxx. Remove other unit tests.

Step 7: Categorizing Test Methods ✅

A good practice is to group test cases using describe(). I instructed:

Use describe to categorize unit tests by the methods being tested.

It got me

Organize the unit tests using describe blocks.

Step 8: Testing More Logical Paths ✅

It only tested one path per method, but each method had at least two logical paths. I told it:

You only test one path. Test more paths. For example, for xxx, test when xxx is true.

It got me

Add more test cases to cover different paths of the methods being tested.

Step 9: Manually Specifying a Missing Path 🤔

One test path was still missing, so I explicitly pointed it out:

For planId, you didn’t test when planId is null.

It responded:

Add a test case for planId when planId is null.

Step 10: Running the Test Cases ❌

I asked it to run the tests, but it said:

❌ Sorry, I can't assist with that.

I ran them manually and found one failed test:

Step 11: Fixing the Test Case ❌

I asked it to fix the failing test:

The unit test "returns empty string when planId is null" failed, correct it.

It responded:

✅ Correct the unit test "returns empty string when planId is null".

However, the error persisted.

Step 12: Attempting to Fix the Test Again ❌

After multiple attempts, it still couldn't fix the test. I had to fix it manually, which violated my goal of not touching the code. Additionally, fixing one test caused five others to fail.

Step 13: Ensuring Test Isolation ❌

To prevent tests from affecting each other, I instructed:

Ensure each test runs with a clean component instance.

It responded:

Ensure each test runs with a new component instance.

However, it did not work, and the errors remained.

Conclusion

The experiment ultimately failed. The tests did not pass, and the situation worsened. I even had to intervene manually. In the end, I deleted the test file. Tomorrow, I will attempt a different approach.

Use watch as the last resort

code plato — Sat, 01 Mar 2025 04:28:13 +0000

We should avoid using watch in Vue. I'm not saying it's bad; we should just treat watch (and watchEffect) as a last resort. watch is a very reliable tool. It is the simplest and laziest way to achieve a function. It can almost guarantee 100% triggering, thus covering your needs. But the problem is that sometimes it covers too much. watch has the following disadvantages:

Disadvantages

1. Implicit Dependency

watch creates an implicit dependency.

An implicit dependency is a hidden relationship between components in a system where one component relies on another without being explicitly stated.

An explicit dependency occurs when component A directly calls component D, making the relationship clear and easy to trace.

Implicit dependency means that component A eventually calls component D in an unobvious way, creating a connection between them.

Although explicit dependencies seem easier to maintain, a system full of them would lack flexibility. For example, vue-router is an implicit dependency, and implicit dependencies are essential for building frameworks. However, using them in business code increases maintenance difficulty.

Here is a great article that explains the disadvantages of implicit dependencies:

Side Effects in Code: Why They Matter and How to Avoid Them

Although this article does not explicitly mention implicit dependencies, side effects are essentially how watch operates in Vue.

Side effects create implicit dependencies between components, increasing the chance of bugs. For instance, in our discussion, I noted: "If a method assumes that a specific member variable will be updated beforehand, you’ve built a trap for the next developer — or even for yourself six months later."

2. Difficult to Trace the Source of Changes

When an error occurs, it is difficult to determine which piece of code initially triggered the change. If you are debugging in a local environment, it's easy to check the stack trace. But if you are troubleshooting on QA, CM, or PROD and are unaware of a watch, debugging can become a nightmare.

A real-world example: while working on one of the page of our project, we encountered a defect that seemed to originate from the data initialization. However, we didn't realize that the data were initialized twice—once via a watch. If both initializations worked correctly, the duplicate execution would go unnoticed. But when bugs inevitably appear, identifying the source of the error becomes critical in measuring code quality.

3. Creates Tight Coupling, Making Refactoring Difficult

Using watch can tightly couple different parts of the code. Initially, we knew that code A triggered code B through watch. Over time, additional code was introduced—code C also triggered code B through watch. Then, a third engineer, seeing the existing pattern, added code D, further expanding the web of dependencies. This results in increased coupling, making the code harder to maintain.

This article discusses the dangers of tight coupling:

Code Coupling: Reducing Dependency in Your Code

You’ve no doubt encountered this effect: you make a change in one corner of the system and it breaks code in a far, far distant corner. You might not even spot such a defect, particularly if you don’t do extensive regression testing with each release. That, of course, means your unfortunate customer will likely be the one who spots the defect.

A watch is like a spider web—it captures any logic that falls into its scope. If you watch a global variable, such as savedSession, its impact could extend across the entire project.

A project with excessive watch usage resembles the image above.

4. May Cause Infinite Loops

If watch A triggers watch B, and watch B triggers watch A, you create an infinite loop.

A real example: while developing QuotesPage.vue, I was a big fan of watch and added five or six of them on a single page. This led to an infinite loop when the page attempted a "relaxation" operation. At the time, there was no good way to suspend a watcher. See this answer from Evan You, the creator of Vue.js:

The only way to suspend a watch is to include a conditional check. I had to add some variables like watcherEnabled disable the watch when necessary. After I stopped using watch, I was able to say goodbye to this ugly workaround.

5. Hard to Read and Understand

When reviewing the logic behind a watch, you often need to navigate between multiple files or distant parts of the same file.

You might need to jump across different areas of the project to understand the full logic flow.

Better Solutions

There are better alternatives to watch. Consider the following before using a watcher:

Directly call the method if they are in the same component.
Use computed properties if you only need to display something.
Use custom events to trigger methods in a parent component.
Use lifecycle hooks like app:rendered, page:start, definePageMeta in Nuxt, or onMounted in Vue.

When to Use `watch`

Despite its drawbacks, watch is still useful in some cases:

When you need to update something, but custom events cannot achieve the desired behavior.

By using watch cautiously and considering alternatives first, you can write more maintainable and predictable Vue applications.

How to write elegant code 1: Keep the chain of event calls short

code plato — Sat, 21 Dec 2024 18:21:12 +0000

The chain of event calls

There are some scenarios we keep throw up the event to the parent component. Then it handle the event in the component far way from the component which raise the event

This has the following disadvantages

Switching between different component source code increase the difficulty of developing
We coupling deeply these components. The architecture is fragile. If there is a component updated might break the event chain

If we calculate the distance of event calls chain in this way:

when the event is handled in the same component which fire it, the distance is 0
if the event if handled in the parent component we plus 1 to the distance. For example, the event is handled by the parent component, the distance is 1

In the example above, the distance is 3

The code is hard to read if the distance is larger than 1. If it’s 3, you will need to switch 4 files to read the event call chain completely.

How to fix it

Put the even handler beside the event listener

Questions

Q: Will this cause a lot of duplicate code? A: No. we can extract common code to composable or component to reuse the same code.
Q: Will this create a lot of duplicate components like modals? A: No, make sure the component only be created when it's needed. For example if you are using Vue.js use v-if instead of v-show for modal component to make sure it won’t be rendered when no needed. Also, use private variable instead of global variable to control if the modal is shown to make sure the toggle method will only trigger 1 modal to be open or close.

3 Things You Should Try to Avoid in Vue.js

code plato — Sun, 03 Apr 2022 18:07:44 +0000

1. Try not to write the inline script in the template if there are more than 2 lines of code

VSCode cannot check any syntax error of the inline script in the template. So try not to write the inline script in the template. If you write the inline script in the template, it's no different than writing code in Notepad. There are 2 drawbacks:

VS Code cannot check the syntax error

If you are using Typescript, VS Code can identify the syntax error for you. You might think I'd be able to spot those syntax errors, but actually, we don't. For example, in this code, the inline script only has 2 lines of code.

<div @click="alert('hello world'); doSomething();" />

The even handler is

doSomething(event: Event) {
   // do something ...
}

There is no errors in VS Code. But when you run this code, you will find that the event parameter is undefined.

If you extract the line move console.log('do something'); doSomething(); into a method sayHelloAndDoSomething()

sayHelloAndDoSomething() {
    console.log('do something');
    this.doSomething();
}

Then you will see there is an error

It turns out that doSomething has a required parameter event. The worse thing is this inline script seems to be working fine. But the parameter event of doSomething arguments is undefined. We create a defect in this way. This example looks dumb. But there similar cases I've met at work.

Hard to debug the code in production

The inline script will be compiled in 1 line js code in production. It's not able to debug this code. If you put the code in a method/computed of the component. You can still be able to debug it even it's already minified.

If there is an error, we can still debug this code. It's not difficult to know what is the e or n variable based on the source code.

Imagine how convenient it will be if you can debug the code in production. That really help me for several times. So try to extract inline script code into component method/computed, it will help you eventually.

2. Try not to use watcher

Vue.js documentation already suggest us not to use watcher.

Why? Because watcher is an implicit dependency. Implicit dependency brings the following problems:

Logic becomes more scattered, and there is no explicit correlation between them. It makes it difficult to understand the code. This is especially difficult when troubleshooting.
When you update the feature, you won't be able to notice that somewhere a logic has been broken. Just because this logic is triggered by a watcher.

In addition to the problems brought by implicit dependencies, watcher has other problems of his own:

The watcher won't be triggered when Vue.js rendering the component as watch is lazy by default unless you use immediate: true. So if you expect some logic in a watcher will be called when v-if turn to true , you may be disappointed. We did meet a defect caused by this.
The watcher cannot be paused. Sometimes we don't want to disable the watcher, we just want to pause it. Unfortunately, watcher doesn't provide the pause feature. this comment mentioned that the only way to pause the watcher is doing a conditional check. When I have a similar problem at work, I usually add a flag like watcherEnabled to pause the watchers in some scenarios. But this flag also brought me some defects.

There are 5 better approaches than watcher

From child to parent

Use custom events

If you need to trigger the method of the parent component. You can use custom event

From parent to child

Move method from child to parent

If the metod you want to trigger is in child method. Instead of using $refs, it will be better to move the method to the parent component. Then you can directly call it or use custom event

Use ref attribute

If the method you want to trigger cannot be moved to the parent. Or you don't want to take the risk to refactor the task. You can use ref attribute

But remember that using $refs is not a good practice. $refs has its own problem as well. The component $refs is undefined when the component is rendering. So if you use $refs it in the template, it might be undefined. If you are using $refs in the computed. The computed might be broken. For example, there is a computed to get the child component scrollLeft attribute.

get childScollLeft() {
    return this.$refs.child.scrollLeft;
}

This computed won't work as you expect. Because when the variable you want to watch in the computed is undefined at the beginning, then this computed will not be reactive. Not even after the $refs loaded.

Use props

If you want to update the child component UI. You can use props

From anywhere

Use Vuex

If you want to update the parent/child/sibling component UI. You can use Vuex. The only downside is that this may increase code complexity.

3. Try not to pass functions as props

Passing functions as props an anti-pattern in Vue.js. There is a sentence in the article that is really good.

As the application grows larger in size and other developers come on board, they will look at the child component code and have to figure out which callback function prop it is and where it is from.

That's the issue that I meet in my project. Sometimes I need to figure out where are those methods come from.

I agree with it. But this is not the main reason I don't recommend passing functions as props. The main reason is when I read the code it takes some effort to get familiar with the context of this component. If there is a function was passed as a prop, then I need to be familiar with the context of another component. If that were all it was, it wouldn't be so bad. The worse is I need to switch between different components contexts when reading the method.

I recommend using custom event instead of passing functions as props.

Jest Best Practice 1: Use eslint-plugin-jest

code plato — Wed, 28 Apr 2021 03:22:47 +0000

Wasteland in the project

We used to focus on the quality of business code only and ignore the unit test code quality. That makes the unit tests code becomes the wild west of our project. So I gonna share some practice I've used in my project.

Start with the code style

First, let's begin with the style of your unit test code. We used to use eslint on our business code. But have you try to use eslint on the jest code? Try eslint-plugin-jest. Here is the introduction of this package: https://www.npmjs.com/package/eslint-plugin-jest

Here are the rule set I've used in my project

'jest/expect-expect': 'error',
'jest/lowercase-name': [
    'error',
    {
        ignore: ['describe'],
    },
],
'jest/no-disabled-tests': 'error'
'jest/no-done-callback': 'error',
'jest/no-duplicate-hooks': 'error',
'jest/no-conditional-expect': 'error',
'jest/no-export': 'error',
'jest/no-focused-tests': 'error',
'jest/no-identical-title': 'error',
'jest/no-interpolation-in-snapshots': 'error',
'jest/no-jasmine-globals': 'error',
'jest/no-jest-import': 'error',
'jest/no-large-snapshots': 'error',
'jest/no-mocks-import': 'error',
'jest/no-standalone-expect': 'error',
'jest/no-test-prefixes': 'error',
'jest/valid-describe': 'error',
'jest/valid-expect-in-promise': 'error',
'jest/prefer-to-have-length': 'warn',
'jest/valid-expect': 'error',

Most of them are easy to understand. But I want to introduce some of them.

jest/no-done-callback

We might need to change our habits. Don't use done anymore. Because if the code is not able to reach done it will easily get an error. Also using callback can be very prone, as it requires careful understanding of how assertions work in tests, or otherwise tests won't behave as expected.

There are 2 scenarios we need to change our way to write the test

for async operation

For async operation. Turn to use async...await instead of done. Or you can return the Promise like

return doSomething().then(data => {...})

for setTimeout

For setTimeout. Use jest.useFakeTimers() at the beginning of the test file. Then use jest.runAllTimers() to fast-forward until all timers have been executed

For more information about timer mocker, please refer to https://jestjs.io/docs/timer-mocks.

jest/no-conditional-expect

Use the expect in conditional call could lead to the expect silently being skipped. Put the expect in catch is also easy to be skipped.

The following patterns are warnings:

it ('foo', () => {
    const result = doSomething();
    if (result === 1) {
        expect(1).toBe(1)
    }
})

it ('bar', () => {
    try {
        await foo();
    } catch (err) {
        expect(err).toMatchObject({ code: 'MODULE_NOT_FOUND' });
    }
})

It will be better to write these tests in this way

it ('foo', () => {
    const result = doSomething();
    expect(result).toBe(1);
    expect(1).toBe(1);
})

it ('throws an error', () => {
    await expect(foo).rejects.toThrow(Error);
})

jest/no-identical-title

There is an important rule no-identical-title. It's for preventing us to name 2 test cases with the same name.

The following patterns are considered warnings:

it('should do bar', () => {});
it('should do bar', () => {}); // Has the same title as the previous test

It's simple but very useful. I have the experience that I tried to fix the failed unit test. But it was still failed after 30mins troubleshooting. Then I found that I'm not fixing the one that failed. It's especially tricky when there are 2 failed unit tests with the same name.

Forem: code plato

[Enterprise Git Workflow Best Practice] Use a Sub-Project Branch When Developing Large Features

Terminology Definitions

Mistakes We Made with Sub-Project Branch

Necessity of Sub-Project Branch

Best Practices for Using Sub-Project Branch

The Bicycle-shed effect

The Definition

What do we use it?

[Copilot Extreme Practice Journal] DAY 1: Using Copilot to Generate Unit Tests Without Writing a Single Line of Code

Terminology Introduction

Copilot

GitHub Copilot

GitHub Copilot VSCode Plugin

Task Requirements

Execution Process

Step 1: Initial Generation of Test Cases ✅

Step 2: Moving the Test Case ❌

Step 3: Moving the Test Case Again ✅

Step 4: Attempting to Fix the Test Case ❌

Step 5: Directly Telling It How to Fix the Errors ✅

Step 6: Specifying Which Methods to Test ✅

Step 7: Categorizing Test Methods ✅

Step 8: Testing More Logical Paths ✅

Step 9: Manually Specifying a Missing Path 🤔

Step 10: Running the Test Cases ❌

Step 11: Fixing the Test Case ❌

Step 12: Attempting to Fix the Test Again ❌

Step 13: Ensuring Test Isolation ❌

Conclusion

Use watch as the last resort

Disadvantages

1. Implicit Dependency

2. Difficult to Trace the Source of Changes

3. Creates Tight Coupling, Making Refactoring Difficult

4. May Cause Infinite Loops

5. Hard to Read and Understand

Better Solutions

When to Use watch

How to write elegant code 1: Keep the chain of event calls short

The chain of event calls

How to fix it

Questions

3 Things You Should Try to Avoid in Vue.js

1. Try not to write the inline script in the template if there are more than 2 lines of code

VS Code cannot check the syntax error

Hard to debug the code in production

2. Try not to use watcher

From child to parent

Use custom events

From parent to child

Move method from child to parent

Use ref attribute

Use props

From anywhere

Use Vuex

3. Try not to pass functions as props

Jest Best Practice 1: Use eslint-plugin-jest

Wasteland in the project

Start with the code style

jest/no-done-callback

for async operation

for setTimeout

jest/no-conditional-expect

jest/no-identical-title

`Copilot`

`GitHub Copilot`

`GitHub Copilot VSCode Plugin`

When to Use `watch`