Zayee

On My Way

Fri, 06 Nov 2026 00:00:00 GMT

Test: Try to write a short poem

I'm on my way

Testify my ability.

Show my parents that I have been out of their expect.

Prove myself worth it.

Find my upper realm.

I also used to be young. Full of ambition.

Imagine myself mantled the golden light. Illuminating everyone nearby me.

I'm on my way to run away

I have been too tired.

Drag my lag trotting through the dark route.

Moonlight cast behind me. Try to navigate me back, rather running away.

But I have been too tired.

My flesh was teared. My consciousness was destroyed.

So, I run away.

Why I'm back to my way?

Am I a maniac, or a idiot?

I will be teared again, knocked down again.

But I'm back.

Because I'm a maniac, and a idiot?

I don't know.

A maniac can't analyze with logic.

A idiot don't know which is better, back ot forward.

So, yes I am.

After all, I'm crawling on my way.

24-26, Computer Major, and Thoughts on AI Era

Sat, 25 Jul 2026 00:00:00 GMT

This is my first English blog post. Even though I'm Chinese, I am planning to write in English from now on. Here are the reasons:

To practice my English
To prepare for studying abroad (so that I can share it with my future foreign friends)
Because it's cool

Introduction

Usually, people don't share their plans with others on their blogs, I guess... Anyway, it's such a private thing. But I'm an open-minded guy who doesn't care too much.

Nowadays, I find that a lot of my juniors are confused and anxious about their future plans, overwhelmed by employment pressure (mostly driven by the rise of AI tech). For the purpose of helping latecomers and getting some advice from wiser people on my own plans, I wrote this post. You might know that I am someone who always dares to dream big. So my schedule is just like a daydream. Please, experts, give me suggestions about my plan if you have any constructive ideas.

Choosing college preferences —— decide to learn Computer Major —— 24.7 - 24.9

At the start of choosing my major and college after the Chinese National College Entrance Examination (Gaokao), I spent some time deciding what major I wanted to study and work in (and also earn a lot of money from). It turned out to be Computer Science.

After that, I began to search for information about colleges I was capable of applying to. After more than ten days of deep research, I decided to apply to Zhejiang University of Technology (ZJUT, where I currently study), even though my Gaokao score was barely enough to get me into an unpopular degree program (which certainly excluded Computer Science). So, it was highly unlikely for me to get into it directly.

If you are familiar with me, you should know that I successfully went through a Change of Major. Yes, in fact, back when I was submitting my college preferences, I had already researched the feasibility of it by reading posts on Baidu Tieba, talking with seniors in ZJUT freshmen group chats, and reading relevant official documents. I'm totally a daydreamer (lol).

So, days after submitting the college preference form, just as I had "hoped," I got an offer for the chemistry program, and eventually successfully changed my major at the end of the first academic year (I also wrote a blog post about it).

By the way, during that vacation, I spent two months learning C++ and some algorithms. One reason was certainly for my future Major Change Exam; the other was that I was considering preparing for the ACM Contest at the time.

Adapting to college life, and laying foundations for future choices —— 24.9 - 25.2

September 2024 (24.9) marked the end of the summer vacation before formally stepping into college. At that point, I encountered zjutjh, a club at ZJUT consisting of many high-tech computer lovers. There, I was introduced to the job of a website/software developer, met lots of ambitious and distinctive people, and stumbled upon my possible future —— being a front-end developer.

I haven't mentioned yet that I'm not a local in Hangzhou, where ZJUT is located. So coming here felt like a tour to me. I experienced a colorful life here, but that's not today's topic.

Oh, don't forget, I was still a chemistry student at that time. So while taking chemistry courses, I was also learning front-end development. But I wasn't too busy because most engineering programs share a similar course schedule at my school, usually consisting of Advanced Mathematics, a programming language (mostly C++ or Python), College English, and so on.

At that time, I learned how to develop the front-end of a website in just two weeks and produced my first website (as a sort of entrance exam), although it was really ugly and hard to use. I had my first teamwork development project with others (who are my friends right now). I built my blog (yeah, the one you're surfing right now). I also took part in the development of an official online project (named WeJH).

As we all know, in China, college students usually have four post-graduation pathways:

Taking the National Postgraduate Entrance Examination (requires you to study hard in the last two years of college)
Postgraduate recommendation (a standard policy in Chinese colleges, requiring you to work hard your entire college life to compete with others for limited spots)
Studying abroad (usually costs a large amount of money)
Direct employment

At that period, I thought there was a 60% chance for me to directly get employed, 30% to take the postgraduate entrance exam, and 10% for the remaining two.

OK, remember this percentage distribution, my readers. After a period, it will change a lot. This reveals how my considerations for my future plans shifted during different periods.

Make a rough decision to work as a developer —— 25.2 - 25.9

As my experience and skills in front-end development grew, working as a front-end developer became a clear, viable pathway for me. I figured I would probably choose this path. It was a stable route back then, after all (when the IT industry hadn't been heavily disrupted by AI yet).

Repeat again, I am totally a daydreamer. I wish I could earn more money than my parents. And please don't laugh at me for this "stupid" wish. It's not easy for me to achieve that. And I deliberately aimed for it when choosing my school and major. It's well-known that being a coder in a large-scale company usually earns a lot, although, in my view, that "a lot" doesn't always seem to be enough.

The paragraphs above were written on 2026-05-20, and the paragraphs below are written on 2026-07-25. Well, maybe just because I'm a little busy, also lazy...

Well, I have totally forgotten the context of this post... Let me just casually write down whatever comes to my mind.

After all, I went through a lazy term from 25.2 to 25.6. Nothing specific happened. Just normally working on some projects, committing some code, and preparing for my Major Change Exam. The result of that exam? A success, certainly.

From 25.6 to 25.9 was the summer holiday. At that time, I spent most of my time in the club —— zjutjh, as management-level staff (In fact, most work was still about website and software projects, not management).

At that period, 70% for directly getting employed, 20% to take the postgraduate entrance exam, and 10% for the others.

AI technology was already quite strong at that time. But I wasn't too worried about future unemployment because the seniors seemed to "succeed" with such jobs. This is how the environment influences an individual—gradually and unconsciously. You probably won't even notice that your way of thinking has changed, becoming quite different from how you used to be.

Crush? Break down? Wake up? - 25.9 - 26.2

You might notice that I mostly divide sections by school terms. Yes, you're right. It's for my own convenience to write such an article in English. SO HARD! There might be better ways to structure it, but I just want to finish this post, which has dragged on for 2 months.

Bet on Embodied Intelligence

Back to context.

It's usually hard for an individual to suddenly change their future plans unless something big happens.

There were two events that contributed to my reconsideration about my future, I guess:

I started to truly feel the impact of AI coding tools myself.
In October 2025, my family hosted a banquet to celebrate achieving a small financial goal.

For the first one, I experienced how strong AI was on my own. Also, I searched for and watched serious AI-related videos, including talks from various "professors" across different fields (some are just internet keyboard warriors, so I add quotation marks), and some interviews with Elon Musk.

I started to re-evaluate my understanding of AI technology's development, and even the world's.

Here was my basic idea of AI:

This is the Fourth Industrial Revolution. The world will be fundamentally changed over the next few decades, just as it was after the invention of the Steam Engine and humanity's mastery of Electricity.

I don't want to over-explain this. I just believe the entire industrial structure of society will be completely transformed in the coming years.

So, this led to a question —— will programmers become unemployed?

Hah, I'm not sure. But I just believe that traditional path won't be the one I want to take.

At first, I just considered becoming a postgraduate student in AI. But finally, my eyes were caught by a new phrase —— embodied intelligence.

If you are totally unfamiliar with that term, you can just think of it as "Robots."

Here is my opinion (translated by AI. In fact, my original intention for this passage was to show exactly this):

From a macro perspective: software-level applications like agent development are ultimately restricted by two carriers —— network and computer. AI, as the highly possible core tech of the forth Industrial Revolution, is the core of productivity reform in our new era. This technology will bring contemporary people a shock and a huge leap in productivity, which totally surpasses what steam engine did to the manual era, electrical devices to the steam era, and Internet to the electrical era. And obviously, such a leap couldn't just be achieved inside a tiny computer or behind a single screen. Technology needs to be landed into the real physical world, and AI needs a pair of hands to work. Just like steam engine needs a locomotive to run thousands of miles, electricity needs various electric devices to bring us the electrical era and needs light bulbs to light up the earth, and the Internet needs to enter thousands of households' computers and cellphones to truly change people's lives. Embodied Intelligence —— is exactly the way how AI, this infinite energy source, changes the world.

Consider studying abroad

The banquet hosted by my family made me aware of our real financial situation. Also, at that time, two coincidences happened.

First, my father asked me to contact a relative who had earned a considerable amount of money in Denmark.

Second, one of my seniors was considering studying abroad.

I started to formally consider studying abroad.

After contacting relevant organizations both online and offline, and spending dozens of hours searching and organizing information on the Internet, I found a reasonably feasible path.

I knew that studying abroad (without a massive budget prepared) could be a challenge. But deep down, I wanted to experience new cultures and a new lifestyle. Rationally thinking, such a challenge would make me grow a lot.

Now 50% for studying abroad, 30% for getting employed directly, and 20% for taking the postgraduate entrance exam.

However, this doesn't mean I will give up on finding internships or other ways to earn money and hone my skills during the last two and a half years of my college life.

On the contrary, I must prove myself by showing my ability to earn money, so that I can get my family's support to study abroad. Plus, it's a great way to challenge myself.

END

It is July 2026 (26.7) right now. But I am a bit reluctant to write another paragraph about my experience during the recent term.

That's all.

From a 2.3 to a 3.6 GPA: What I Did

Thu, 05 Feb 2026 00:00:00 GMT

This article was translated by AI from the Chinese version.

This post has not been polished by AI. If there are typos or awkward sentences, I may fix them when I feel like it.

Some Random Thoughts

The title is clickbait, as the subtitle says, but it is true. My 2.3 was the GPA from the second semester of my first year. I had just transferred majors, got a little carried away, and thought I would never need my GPA, so I did not take several classes or finals seriously. My 3.6 is from this semester, the first semester of my second year. ~~It still missed my target by a lot.~~

I wanted to prove that, if I really wanted something, I could achieve it—even earn a postgraduate recommendation if I chose that path. I hoped for extremely high scores this term, but two or three courses I studied seriously for let me down.

Still, this was the hardest I have worked academically in more than a year of university. I want to record this small moment of glory, and share a few study methods.

There are plenty of university students with GPAs above 4.0, so there is little here to show off. But few people who score well actively share their methods; fewer write those methods into a post, and they may not even be in your major. Besides, although I did poorly in some subjects, I also did well in others. If we ignore the bad ones, every course went great!

I will not explain how to improve participation grades, nor how to make a physically present body sit in class while the real person is elsewhere.

General Study Method

I do not think I have special talent for studying. If people spend as much time as I did and use it well, they can probably score well too. I had ten finals because transferring majors added three make-up courses: C Programming Fundamentals, Discrete Mathematics, and Linear Algebra. Students taking fewer courses naturally have more review time per subject.

I cannot learn everything instantly, so I started preparing in week 14, even for material that had not finished being taught. I printed two collections of past papers and eventually completed about half of them.

You can find papers in several places:

Teachers' DingTalk, QQ, or WeChat groups.
Course materials on the school learning platform.
ZJUT Course Strategy Sharing Project.
Senior students.

For every subject except some ideological-and-political courses, try to get several papers. Senior students are normally happy to help: they were helped by their seniors too.

Unless a review outline genuinely limits the scope of an exam, I do not think it matters much. Online review materials can do the same job. Ideally, finish learning all subjects and reserve a whole week for papers. I only had half a week left because I underestimated how long the Data Structures and Computer Networks course projects would take. Several subjects became one- or two-day cramming sessions, so I did badly in them.

For some science and engineering courses, I self-studied with Gemini, textbooks, and Bilibili videos. My overall review process, apart from two political courses, was:

Do papers, find what I cannot do -> ask Gemini or search Bilibili to learn it -> do related questions again.

Courses Scoring 85 or Above

I will go from highest score to lowest. I personally do not think anything below 90 is truly good, so treat these mainly as study ideas.

C Programming

I will skip this one. I only took it as a make-up course after changing majors. For a second-year student, this result was normal—mainly because I barely studied it.

Data Structures — 91

I was surprised by this score, not because I studied badly, but because the exam was genuinely difficult. The teacher's mock paper was rather easy; the real paper had roughly twice as many questions. I wrote from the moment I received it until the end, mostly drawing diagrams and handwriting code. I nearly forgot to transfer the multiple-choice answers to the answer sheet, then used all my Gaokao-trained emergency speed to scribble them down. I left with shaking legs and no energy to cycle back to my dorm.

Anyway, here is how I studied it.

Weeks 1–5: Labs Only

I only followed the labs and did not study separately. Writing data-structure labs yourself is useful because it is real code practice. I spent about 9h, usually one or two hours per lab.

Weeks 6–8: Midterm Preparation

I studied seriously and got 86 in the midterm. A good midterm is the foundation for a good final: a bad one loses marks, hurts confidence, and creates more review work. I self-studied with the textbook, asked Gemini questions, and practised from Wangdao's Data Structures book. This took about 9h.

Weeks 9–13

I barely studied except for labs, and did not even write one or two labs myself. Less than 7h.

Weeks 14–16: Final Review

Finishing the remaining textbook material took around 9h. I used the textbook plus Gemini for questions, and Bilibili videos.

This series is useful because you can learn one knowledge point at a time rather than watching from start to finish, and the animations make data structures easy to understand.

Look at classic examples for each data structure. You do not need to solve every one, but you need to have seen them: problems use technical terms and may ask for something you cannot understand without context. Once you know the required structures and algorithms and have seen examples, the result largely depends on coding ability. Many diagram and code questions can be derived in the exam room. Papers plus review took around 5h.

You can use Wangdao's postgraduate Data Structures book for the whole review.

University Physics II B — 89

This was the only course where consistently listening in class and working hard paid off exactly as expected. Data Structures above was a self-study result. I also listened seriously in Discrete Mathematics and Linear Algebra B, but got only 82 and 79, which made me furious at first.

After calming down, the reason was clear: listening in class completed the first step, learning knowledge; it did not complete the second, learning how to solve problems. I had little homework in those subjects, did only one paper for each final, and never reviewed systematically. Knowing something is not the same as being able to score well on it.

Physics had enough regular workbook questions, which made review easy. I had completed one pass by around week 15 and another before the exam. A good plan is to put 80% of your practice into the required workbook, then review it thoroughly. If you cannot solve a question during the term, Gemini 2.5 Pro-level AI can explain it clearly. If you never did the workbook during the term, do papers directly in finals: many workbook questions are difficult or not tested.

Physics is not particularly convenient to self-study. If you must do it, read the book, ask AI, then find matching question types in past papers. At my school, the papers are public and my teacher posted enough on the learning platform. Also, some difficult material from class is not included in the final. In many chapters, only a few core formulas matter; for de Broglie waves, for instance, $\lambda = \frac{h}{p}$ may be enough.

Java Programming — 88

This was a real last-minute breakthrough. ZJUT's Java exam permits one open-book page. You do not need extremely deep Java knowledge: go through the syllabus or slides, copy what you do not know onto the sheet, then do two papers.

The night before the exam, I studied and made the sheet from 20:00 to 1:30, then read two papers. Final review took 6h, and I had spent about 10h studying during the term.

Handwritten programming questions, especially threads and GUI, are troublesome. Record code patterns for the major question types. My second open-book page covered threads, GUI, and streams/files. Please do not share these pages around if you use them as reference; it is embarrassing when people quote my blog in a live senior presentation.

This year's programming questions happened to be all handwritten types, with no GUI, so some preparation was unused. That does not mean those topics will not appear next year; past papers show that GUI and threads appear often.

Computer Networks and Data Structures Course Projects

Computer Networks project: 88. Data Structures project: Excellent (95).

These two projects were hell.

My biggest scheduling failure was not realizing how much time they would consume. Each took nearly two days, enough time to review Java twice. If you read this before finals, allocate time for projects carefully.

For Computer Networks, I built a simulated school campus network in Packet Tracer.

The difficult parts were external/internal connectivity and port mapping. I used NAT, a web browser, port forwarding, DNS, and OSPF, which I thought might earn bonus points. During assessment I explained the design for seven or eight minutes and passed easily. I asked for an Excellent grade, but got 88, probably because my report was weak. If you want a high report score, find a senior's past report with 95 or above.

For Data Structures, I wrote an AVL-tree library-management system, like more than 90% of the class. The important part is having a distinctive idea that your teacher notices. Mine was multi-level tree comparison—category, then author, then title. Books in the same category and by the same author become naturally adjacent in the data structure without manual sorting. The teacher seemed to like that small innovation.

Mao Zedong Thought and the Theoretical System of Socialism with Chinese Characteristics — 87

The key here is not doing papers. If you can recite the material, you can earn points. Memorize the focus points the teacher gives; they are usually what will appear. You may find many materials from older cohorts, but one or two supplementary sets are enough. All teachers for my cohort marked ten textbook focus points and three extended points, and they covered around 95% of the exam. For this kind of course, listening in class does not feel very useful for raising scores; the material has to be memorized.

Courses Below 85

Marxist Theory — 84

The exam score was probably fine, but my participation score was terrible. One more absence and I would have been barred from the final. I even taught an unprepared roommate to a score in the seventies on the night before the exam, so I think I understood it reasonably well.

Unlike the previous political course, this one is hard to cram. My teacher did not give focus points, and the content forms a connected system rather than isolated facts. You need to understand every chapter that can be examined, then remember it. It requires less pure memorization than other political courses; once you understand it, you mostly know it.

If you cannot bear reading the textbook, try this series:

{An Exhaustive Production} Marxist Philosophy in One Go

That link is only the philosophy section; the creator also has videos on the other parts. My cohort's exam was entirely long-answer questions, so do not waste time drilling multiple-choice questions that will not appear.

I will skip PE, Probability Theory, and the courses where I did too badly to discuss them.

Computer Networks — 82

This was probably the hardest course and there was genuinely a lot to learn, so I have little right to complain. There are two common Bilibili choices:

Computer Networks Made Easy

USTC Computer Networking, Top-Down Approach, 7th Edition

Watch the first if you only want a good exam score; watch the second if you want to learn more networking knowledge. I watched the second and spent a lot of time on untested material, but I learned plenty and do not regret it.

Getting Through Final-Exam Weeks

I can only explain how I got through them. For two weeks, I sat at my dorm computer and studied from close to morning until night, though the intensity was moderate. I am a serious homebody and did not even want to leave the dorm to study.

Two things helped me persist:

Chocolate.
Friends' company.

For the first, substitute any light snack you love. I ate over 200g of chocolate in two weeks. I normally avoid buying it because I cannot stop eating it, but I temporarily unlocked chocolate as stress relief and somehow did not gain weight.

For the second, my friends and I used NetEase Cloud Music's Listen Together feature. Thinking of it now still feels warm.

Ending

The strongest feeling I had after finals was:

Young people's brains work so well!

It is great that I am not old yet. My brain still works, and I can learn many things. I learned ten courses in three weeks; even maintaining 80% of that intensity would be incredible.

So during winter break, I restarted Japanese study and began learning food nutrition. The first is for fun and the second is for a healthy life. After the storm of final-exam month, learning these things feels like only a gentle rain. I have more to say about both, but they do not belong in this already long post, and writing a blog is tiring too. I will stop here.

SSR Part 1: From Rendering Patterns to Simple SSR Problems

Sun, 09 Nov 2025 00:00:00 GMT

This article was translated by AI from the Chinese version.

A Little Rambling

In my previous post, from late September, I ran into a problem while using localStorage in Nuxt. At first I thought my code design was wrong, but it turned out to be a hydration problem that needs to be avoided.

I wanted to write about it then. Real life was busy, my knowledge was limited, and SSR is deep water. I needed to do quite a lot of research before I could write even a short post, so it took me until now.

At first, I thought I only needed to explain hydration and list a few situations that trigger hydration issues. But hydration is shared by SSR (Server-Side Rendering) and SSG (Static Site Generation), so I also had to understand SSR and SSG. To understand them, I first had to understand rendering patterns in general. You can see why this got delayed.

Please forgive me for taking so long to finish such a short article.

That said, I realized that I have already worked with three projects involving SSR, including this blog. Astro uses island rendering, and I have modified parts of this blog as well. Maybe that gives me enough confidence to write about it.

Introducing the Ideas

The knowledge builds layer by layer: first rendering patterns, then SSR, then hydration.

It is a long road, so I will begin with a broad explanation of a few key terms: rendering patterns and SSR. Then I will use simple examples to build an intuitive understanding of SSR and hydration, including a few straightforward SSR errors. A deeper discussion can wait for later.

Start with Rendering

Rendering is the process that turns the usual front-end trio of HTML, CSS, and JavaScript into an actual page. I do not completely master the theory, so here is an explanation image from Gemini. The main thing to understand is that rendering takes time and has a cost. That is why different rendering patterns exist.

SSR means Server-Side Rendering. A rendering pattern describes how the browser turns front-end code into a web page. Here are two patterns that you have probably used even if you did not know their names.

Static Rendering

If you write a Hello.html file and serve it directly, that is a static website. Nothing special happens: the browser receives Hello.html and renders it.

If you want multiple pages, you access different files in the URL, such as /page1.html and /page2.html.

Client-Side Rendering

If you create a new Vue project with npm create vue@latest, its default pattern is CSR, or Client-Side Rendering.

In a CSR project, the server initially returns an almost empty HTML shell. JavaScript later generates the content inside that shell. Vue, for example, starts with <div id="app"></div>. Your .vue files use JavaScript to mount content into that app element. In this model, the JavaScript and final HTML are produced together in the browser.

Server-Side Rendering

Now we can get to the main topic: SSR.

People who customize their blogs may already know that blogs often use SSR. Hexo is purely static, for comparison. In SSR, the server renders a page into a complete HTML string before sending it to the browser. JavaScript is then attached to that already-rendered HTML, which effectively takes over the existing DOM nodes.

In a CSR blog, the server sends the user an empty shell, and the browser runs the downloaded JavaScript to fill it. With SSR, the server sends the complete pre-rendered blog homepage as an HTML file with content already inside it. The user does not have to wait for the browser to render the initial content.

That is why first-screen loading can be fast. In a food analogy, SSR gives you a prepared meal, while CSR still has to cook it after delivery.

Before Step One: Rendering on the Server

From the user's perspective this is not really the first step, because the server often prepares the HTML and JavaScript before the user arrives. The client only waits to receive them.

It is important that HTML and JavaScript are separate here. As I said above, JavaScript will be attached later through client hydration.

The server environment and the browser environment are different. Unlike CSR, SSR evaluates some application code on the server. That difference is the reason SSR code can easily produce certain errors, which I will show later.

Step One: Get the Static Files

The client receives the HTML and JavaScript files prepared by the server and uses the HTML to fill the browser page. The user quickly sees a static page, which is one of SSR's core advantages.

The JavaScript file has not done its job yet. It matters in the next step.

Step Two: Client Hydration

This is SSR's most distinctive and difficult-to-understand step. The JavaScript file that was not used in step one needs to be connected to the HTML that is already displaying a static page. Only after they are connected do we have a complete, interactive front-end page.

For example, imagine a login page. The server HTML can show a login button, but without JavaScript it is only an empty shell and cannot log anyone in. We need to attach @click="login()" and the login function itself. Connecting those pieces of JavaScript to the matching HTML elements is called hydration.

In short, hydration reconnects the HTML and JavaScript that should have been one page, but were separated during the server-rendering stage.

Step Three: Normal Client-Side Operation

After hydration, the complete front end runs in the browser normally, just like a CSR application.

Common Problems

Here are a few problems that can happen when using SSR.

`localStorage` Cannot Be Used on the Server

Assume a browser has a localStorage entry named API_KEY:

<script setup lang="ts">
const key = localStorage.getItem("API_KEY");
</script>

Will this work during SSR? No. You will get an error like this:

The problem happens in the pre-rendering step: the server does not have the localStorage API. It is a browser API for browser storage.

Moving the code into an imported helper does not solve it either:

import { getKey } from "~/use-key.ts";

const key = getKey();

export const getKey = () => {
  const key = localStorage.getItem("API_KEY");
  return key;
};

An import is still evaluated during server rendering, so it can still call browser-only APIs.

The basic safe shape is to access it only after mounting in the browser:

function getKey() {
  return localStorage.getItem("API_KEY");
}

onMounted(() => {
  getKey();
});

onMounted runs in step three, after the page has mounted in the client. That is why this version does not try to use localStorage on the server.

Some Requests Should Not Run on the Server

It is common to write logic like "send a request when entering this page." But some requests should not be sent during SSR.

For example, a request may require user-submitted data or authentication information such as a token. When server rendering runs, that user-specific browser state is not available, so sending the request is meaningless.

Nuxt provides <client-only> for this kind of situation:

<client-only>
  <!-- Content -->
</client-only>

You can wrap the part that sends the request in a component and put it inside <client-only>. It only renders during normal client-side operation, so the server does not make that request.

Errors During Client Hydration

The example I wrote about in the previous post is a hydration problem. It is complicated enough that it deserved its own article.

Although that post is dated September, I rewrote its core solution after finishing this SSR Part 1, and revised the rest as well. You can read it here:

Fixing a Hydration Problem I Ran Into

Closing Thoughts

There are still many things I want to write about, including this mysterious pattern from my Astro blog:

---
// This component is called ConfigCarrier.astro. It is mounted in layout.astro,
// which means it exists on every page.
import { siteConfig } from "../config";
---

<div
  id="config-carrier"
  data-hue={siteConfig.themeColor.hue}
  data-lightDarkMode={siteConfig.lightDarkMode.defaultMode}
></div>

The config file contains this blog's settings, and siteConfig is the exported constant that stores them. Other files read this component with DOM operations to obtain the configuration values.

Why not simply import siteConfig wherever it is needed?

My current understanding is that the config file is not sent to the client as part of SSR, so it cannot simply be imported there.

I will research this further. If that guess is wrong, I will not silently edit this article; I will explain it properly in the next SSR post.

For now, time and length make this a good place to stop. I hope you will see SSR Part 2 soon.

References

Video: 10 Rendering Patterns for Web Apps - the categories are broad, but it covers a lot.

Article: Understanding Hydration in React applications (SSR)

Bing search, ChatGPT, my project code, and my own brain.

Fixing a Hydration Problem I Ran Into

Sun, 21 Sep 2025 00:00:00 GMT

This article was translated by AI from the Chinese version.

This article was confused when I first wrote it, and I did not manage to fix it quickly. After publishing SSR Part 1: From Rendering Patterns to Simple SSR Problems on 2025-11-09, I rewrote the second half. You can now read this as a concrete hydration-problem fix.

The Scenario

I was building a login page, though the project did not have a real back-end login endpoint. It had no accounts at all: requests were authorized by putting a key in their headers.

So the login page only needed one field for the key.

Feature Design

I wanted two features:

Save the key locally and automatically fill the input with it. If someone visits the login page again, they can click Log in without typing it again.
Disable the login button when the input is empty.

I used <el-button>, so the disabled state came from its :disabled prop.

The First Design

Since the key needed local persistence, the obvious approach was localStorage. Calling it directly everywhere did not feel elegant, so the project had a use-api-key.ts composable to manage this one piece of storage:

// use-api-key.ts
import { useStorage } from "@vueuse/core";

export const API_KEY_STORAGE_KEY = "xxxxxxxxxxxxxxxxx";

export const useApiKey = () => {
  const apiKey = useStorage(API_KEY_STORAGE_KEY, "");
  return apiKey;
};

useStorage is a VueUse helper that creates a localStorage entry named API_KEY_STORAGE_KEY. The login page could then stay pleasantly small:

<!-- login.vue -->
<template>
  <el-input v-model="apiKey" />
  <el-button :disabled="apiKey.length <= 0" @click="handleConfirmAPIKey">
    Log in
  </el-button>
</template>

<script setup lang="ts">
const apiKey = useApiKey();
</script>

Any page that needed the key could call the same composable and get a tidy apiKey variable.

The Problem

Of course, the first design had a problem. Its advantages were clear: little code and a comfortable API. But the <el-button> :disabled prop did not update as I expected.

When I entered the page with an existing cached apiKey, or refreshed it, the input contained text but the button was still disabled.

The Fix

At first, I used a simple and brute-force solution.

The Brute-Force Solution

<!-- login.vue -->
<template>
  <el-input v-model="apiKey" />
  <el-button :disabled="isDisabled" @click="handleConfirmAPIKey">
    Log in
  </el-button>
</template>

<script setup lang="ts">
const apiKey = useApiKey();
const isDisabled = ref();

onMounted(() => {
  isDisabled.value = apiKey.value.length <= 0;
});

watch(apiKey, () => {
  isDisabled.value = apiKey.value.length <= 0;
});
</script>

I manually repaired the state that was not refreshing. onMounted runs after apiKey initialization, and watch kept isDisabled synchronized with apiKey afterwards.

The Actual Fix, Written on 2025-11-11

After a senior developer pointed it out, I opened the console and saw this error:

It was a hydration problem.

During server-side rendering, the button was rendered as disabled=true, because the server could not read the browser's saved key. When the browser ran the application, it saw the cached key and rendered disabled=false. The server and client results did not match, so Vue reported a hydration error.

I modified the code to verify that theory:

// use-api-key.ts
import { useStorage } from "@vueuse/core";

export const useApiKey = () => {
  const apiKey = useStorage<string>(API_KEY_STORAGE_KEY, "", undefined);
  console.log("Rendering useApiKey", apiKey.value ? "apiKey has a value" : "apiKey is empty");
  return apiKey;
};

<!-- login.vue; template omitted -->
<script setup>
import { useApiKey } from "~/composables/use-api-key";

const apiKey = useApiKey();

onMounted(() => {
  console.log("login onMounted", apiKey.value ? "apiKey has a value" : "apiKey is empty");
});
</script>

This makes the situation clear: the SSR stage cannot read the key from localStorage, while the client can. The order is:

Server render -> client render -> page mounted (onMounted)

VueUse provides the initOnMounted option for this situation. Let us add initOnMounted: true to useStorage:

// use-api-key.ts
import { useStorage } from "@vueuse/core";

export const useApiKey = () => {
  const apiKey = useStorage<string>(API_KEY_STORAGE_KEY, "", undefined, {
    initOnMounted: true,
  });
  console.log("Rendering useApiKey", apiKey.value ? "apiKey has a value" : "apiKey is empty");
  return apiKey;
};

Now the client also does not read apiKey during its initial render. This option delays the storage read until the component is mounted.

As a result, both the server render and the initial client render see an empty string. Both render :disabled as true, so there is no hydration mismatch. After mounting, the code checks whether localStorage has a key and enables the button when it does.

The logic is clear, the code is still tidy, and everything works.

ZJUT Major Transfer (Computer Science) Experience Sharing | A Guide(?

Wed, 04 Jun 2025 00:00:00 GMT

This Passage is translated by AI from zh version

If you are reading this blog right after stepping onto campus, I highly recommend you come back and read it again later.

Because my main purpose for writing this post is to help you build your whole freshman year plan with "transferring majors" as a core theme.

It would be awesome if this helps you out.

My Situation

First of all, I transferred to Computer Science (Software Engineering). If you are transferring to other categories, you can still use the non-coding-exam parts as a solid reference.

My original major was Chemical Engineering. During my first semester, I considered participating in the ACM contest and had been doing some front-end development on the side. Since I had a decent amount of coding experience, I barely passed the coding exam without much specific preparation.

As for the interview, I did have some front-end projects, but I felt the most crucial factor was my Regional 3rd Prize in the China Collegiate Computing Competition (Service Outsourcing).

However, even with my background, passing wasn't a breeze (mainly because I got roasted for only solving 3 out of 5 problems in the coding exam). Even if you are an ACM guy, you still need to pay attention to the coding exam (we actually had an ACMer who failed the exam this year).

So, if you want to transfer majors, don't procrastinate! You have to start planning the moment you enter college. Otherwise, you might easily face a grade demotion (having to repeat a year) or just fail outright.

Timeline / Difficulty Description

You have three chances: Freshman Spring, Sophomore Fall, and Sophomore Spring.
I'll generally assume you, my reader, are doing it in Freshman Spring.

Freshman Fall: Grind your GPA, meet specific course grade requirements → Freshman Spring: Self-add courses (Minor) → Transfer Exam: (Coding Exam → Interview)

I've seen people fail at every single step. Read carefully. The difficulty varies from person to person. If your academic performance is great, your GPA won't be an issue. On the flip side, I've seen guys get kicked out immediately just because their Advanced Math score didn't reach 70.

Let me describe the difficulty of the coding exam and interview using passing rates. The numbers are approximate, maybe off by 1 or 2 people.

(Class of 25) SE takes 20, CS takes 18, Cyber Security takes 6.
Coding Exam: 130 → 34.
First Choice Interview: 34 → SE 12, CS 13 (Total 25), Network Eng 2, Digital Media 5.

Note that the interview numbers are just for the first round, and neither reached their max recruitment quota! So transferring majors is more about meeting the standard than just competing with others. Here is a picture (a list of people who passed their first choice in the Class of 24) (it's public on the official website anyway). As you can see, the grade demotion rate is still quite high.

Materials to Find & Info to Notice

Transfer Standards and Details Look for your year's Major Transfer Standards and something like ZJUT 2024 Undergraduate Major Transfer Implementation Details Summary.
The Curriculum of Your Target Major First, you need this to figure out what courses you need to catch up on and what you don't need to take. Second, interviewers might ask you: "Have you read our curriculum? What classes on it do you like?"
Admission Quota Check how many people CS or SE will recruit in your year. In my year, CS took 18, SE 20, and the others combined took about 13. This helps you fill out your preference form.
Application Timeline Normally, exams start in the 12th week of the semester. So, once the 12th week approaches, keep a close eye on when applications open (don't forget to apply for it, lol).

Preparations on Your Abilities

Taking courses in advance independently

If you don't take CS courses in advance and miss too many core classes, you will get a grade demotion (usually missing 4 means demotion; I missed 3, so I barely stayed in my grade).

It's highly unlikely you can manually adjust your schedule in Freshman Fall. If you have the tricks to get the academic office to add classes for you early, you are a god. The better way is to apply for a Minor Course at the end of Fall when choosing Spring courses (apply early, they get full quickly). I minored in C++.

Then, in Freshman Spring, you can try to drop non-CS professional courses (for example, I dropped Engineering Drawing). Methods:

Secretly don't select the course during course selection (this worked for me). Your academic office probably won't notice, or they might just be too lazy to care.
If it's already selected, try begging the academic office to drop it (very hard to succeed).

GPA / Specific Course Standards

Class of 24 Requirements:

College Physics 70 (if applicable)
Math courses (like Adv. Math) 70 (Needs the hardest studying)
College English 70 (Needs the most praying)
Programming (like Python, C) 70 (The easiest)

Be super careful with Math and College English! Grab all the usual performance points you can get, otherwise, waiting for the final scores to come out will be pure torture (personal experience).

As for GPA, mine was a bit over 3.0. Generally speaking, staying above 3.0 is totally fine. Having a higher GPA just means the interviewers might praise you a bit. You can grind it or not, but it should at least be around 3.0. Too low just looks bad.

Coding Exam

5 problems in total. You must solve 3 to pass.
This is the biggest filter and where the main difficulty lies.

Programming Language: Only C/C++ is allowed! Zhejiang students who took IT in Gaokao, stop yelling about how much you love Python. Just honestly learn C++. Practice using Dev-C++, because it's the only guaranteed IDE on the exam computers. For you VSCode lovers, you are in for a treat —— force yourself to practice hard on Dev-C++.

For the coding exam, I highly recommend using C++ with the <bits/stdc++.h> library. It's so smooth. I won't teach C++ basics here; figure it out yourself. You don't even need to learn pointers or classes, as long as you can solve algorithmic problems.

Practice: The exam OJ (Online Judge): [http://acm.zjut.edu.cn/onlinejudge/] (Campus network required) There are lots of basic clearance test problems here. But the transfer exam is harder than those. Train until you can stably AC (Accept) a clearance test set within 40 minutes. Also, get familiar with this OJ's quirks, like being strict on trailing spaces but lenient on trailing newlines. Know what Presentation Error, WA (Wrong Answer), and Runtime Error mean in the logs.

There are also past exam questions. I recorded the ones I took this time, but I won't post them publicly since the school forbids leaking them (so if you DM me privately, I might tell you roughly how they looked, cough cough).

Competitions / Projects

I mentioned several projects during the interview, but the teachers didn't seem to care much. I guess projects have limited impact.

Competitions are highly recommended, even if it's just for participation. When you mention a contest during the interview, the teachers will acknowledge your interest in CS, which is a huge plus.

Recommended Contests: Only CS-related ones are recommended. Others might not be useful.

Our school's ACM Freshman Contest / ACM School Contest are highly recognized and act as a perfect exam simulation (getting used to the environment; the actual transfer exam is definitely easier).
Other school-level CS contests (like HanRuan), see if you can grab an easy award.
Highly recognized national CS-related contests (like the China Collegiate Computing Competition). These are hard to get, but winning one helps tremendously.

Filling Out Preferences

Normally, you just choose between Computer Science and Technology (CS) and Software Engineering (SE).

I'm not familiar with the others, so I won't discuss them here. Besides CS and SE, the other branches take up a very small percentage.

First Choice / Second Choice Mechanism: The specific mechanism depends on your year's rules (for example, a few years before me, you could take the coding exam twice). But I feel like future rules will at most be as harsh as mine.

In my year, there was only one coding exam. First choice and second choice just meant two separate interviews. This means about a week after passing the coding exam, you take the first choice interview. The day after that interview, the passing list is usually published. If you failed, you then participate in the second choice interview.

Differences Between Branches: CS is definitely the ace major, followed by SE. For the others, if you apply for non-matching jobs later (like a Cyber Security major applying for front-end dev), your resume might look a bit awkward. CS courses are harder; for example, you have to study circuits and stuff. SE is relatively easier.

Also, if you want postgraduate recommendation (Baoyan), choosing SE is definitely easier. The internal competition (like raising Gu bugs) in CS is fierce.

My Coding Exam + Interview Experience

Coding Exam

90 mins, 5 problems, solve 3 or more to pass and enter the interview stage.
They only look at the number of solved problems, no time penalties.

For past data, you can check the contest section on [http://acm.zjut.edu.cn/onlinejudge/]. The leaderboards for past transfer exams are public.

In Freshman Spring for the Class of 24 (my time), 18 people solved 3 problems, and 16 people solved 4~5 problems.

Here is how my exam went:

10 min: Set up the computer (used Dev-C++), passed Q1. 20+ min: Stuck on Q2 (trapped by a detail: the problem asked me to output two numbers per line. I just printed them, but after the exam, I realized I needed to compare them and swap their order). 40 min: Solved Q3, didn't fall into any detail traps. 55 min: Finished coding Q4, but got stuck because I forgot 0 and 1 are not prime numbers. 55~77 min: The most stressful 20 minutes of my life. Kept searching for where I was stuck in Q2 and Q4. 77 min: Found the detail error in Q4 and solved it.

The last 30 minutes were incredibly tense. Honestly, it felt like I only had 60 minutes of effective problem-solving time (my skills weren't enough, sigh). If your C++ is decent, you'll mainly be battling detail issues. The overall difficulty is around Luogu Beginner ~ Normal-, but they will intentionally set traps in the details.

Interview

My rules this time:

Lasts 5 mins, they won't intentionally make things hard for you. Includes self-intro + Q&A.
The interviewee stands on the podium. Teachers sit in the first two rows.
One main interviewer keeps asking you questions, while the others discuss like they are in a wet market.

Questions: Most questions are based on what you said in your Self-intro.

Self-intro

Figure this out yourself. I just talked about my projects and contest experiences.

What have you learned on your own?

Me: Front-end development. (But I felt those teachers didn't understand it; they just listened and stayed quiet).

How many missing courses do you have?

Me: Currently missing three (Discrete Math, C Programming, Linear Algebra). I can easily pass C Programming (self-taught), and I minored in C++. (If they ask this, you basically passed. They are just evaluating whether you need a grade demotion. If you miss 4+ courses here, get ready to be demoted).

Have you read our curriculum? Are there any classes you particularly like?

Me: Web dev, Java, Computer Networks, etc.

Why transfer to SE instead of CS?

Me: CS requires studying circuits and stuff, which is too hard for me. (Actually, I was just too lazy to spend that much time studying).

Afterward, the teachers discussed whether to demote me for a while. But I was super lucky during my interview: The teacher who taught my C++ minor class happened to be one of the interviewers! He spoke up for me down there, saying he didn't want me to get demoted.

So, moral of the story: do NOT offend any CS college teachers during your freshman year. For example, if you sleep in a teacher's class, and they end up interviewing you... you can basically pack your bags (tears).

Is Element UI Really That Good? Notes from Using It

Mon, 28 Apr 2025 00:00:00 GMT

This article was translated by AI from the Chinese version.

Introducing Element UI

This is for newer developers who have never used it. Experienced developers can probably skip it.

First, links for the great Element UI:

Element Plus

Component library

Its latest version is called Element Plus. In the official words, it is a component library based on Vue 3 for designers and developers.

For example, instead of building a login button from scratch, you can use a ready-made component in your front-end project.

<el-button type="primary">Log in</el-button>

Components

Content Components

Components such as Card, Button, Input, and Icon are used as part of a page layout. The best part is how much time they save: open the package and use it.

They are also reasonably extensible. Take Input as an example:

As shown on the left, an email input can include a Send verification code button inside it. The one at the upper right is a larger text area for writing a semester summary.

Layout and Feedback Components

Components such as el-dialog for modal dialogs, el-alert for notices, and el-message for feedback feel even more generally useful than a simple Button.

Anyone can make a button, even if we are lazy. Building a reliable modal dialog from scratch is much more annoying.

When I first used el-dialog, it made me realize how easily a library can create this kind of layout.

I ended up using nearly ten dialogs in my project. Compared with only navigating between pages, the application felt a level more polished.

A Drawback

Because Element UI is used for layout, it brings its own visual style. It is great for personal projects, but in a formal team project the requested UI design may not be compatible with Element's style.

So it is useful, but do not become too dependent on it.

Other Notes

Bugs

Accidentally Reusing an Element Class Name

Element UI has built-in class names and styles. Do not casually create a class name that overlaps with one of them.

For example, I added class="el-upload" to the outer element of an <el-upload /> component. Element's built-in styles then leaked into my wrapper:

Its display: inline-flex turned that area into a flex layout and caused the bug below.

Normal:

With an extra class="el-upload" wrapper:

Adding `scoped` While Overriding Component Styles

You normally do not edit Element's source code. If you just want to adjust a component's color or size, write CSS for it in your own <style> block.

Use DevTools to find the class for the exact layer you want. Element components often have several nested layers, so make sure you have selected the right one.

If you usually add scoped to every Vue style block, create a separate unscoped <style> block for this override, or wrap the selector in :global().

The scoped attribute limits styles to the current component file, while Element's generated DOM belongs elsewhere. Remember not to scope the override.

A Shortcut for Throwaway Projects

Element UI is well-known enough that AI tools understand it. When you are building with Element components, you can ask for something like Generate an ElMessageBox with an account and password field and get a quick starting point.

It is very convenient. But if you keep doing that and never review the result properly, the project will probably become a mess.

Overall Impression

Element UI is obviously not a universal solution, but it is practical and versatile. It also helped me recognize standard UI patterns, such as a switch component.

HTML does not have every one of these components built in, but developers tend to use the same names and roughly the same interaction patterns.

If you have not used Element UI, I recommend trying it in a personal project. It improves both speed and understanding. Read the official documentation linked above, or search for Element Plus directly.

My First Experience on a Proper Team Project

Sun, 29 Dec 2024 00:00:00 GMT

This article was translated by AI from the Chinese version.

Some Random Thoughts

It has been a while since I last updated this blog. I have been learning too many unrelated things recently, so let me write a non-technical post first and get some feelings out of my system. Maybe I will write more technical posts when I have time.

What It Felt Like to Work in a Team

For each feature, our team opens a small group chat. There are back-end developers, a front-end developer (me), and senior members who review our work.

The main struggle is simply that my skills are still limited. From time to time, the seniors give my work a serious review, and I temporarily lose confidence in my technical ability. :(

Before this, I was used to very casual development. In a team, every decision needs a reason. You have to keep thinking about what a feature should actually do. That takes some getting used to.

So if you are about to join your first development team, try to manage both your wording and your mental state. Do not let one review completely break you.

What Coding Felt Like

The Pain

I was assigned to an unfamiliar team project. At the beginning, I could not understand anything because I was not capable enough yet. I kept browsing folders, searching for unfamiliar things, and wondering whether my code was conventional, fast enough, and readable enough.

It was painful, honestly. I hope that one day I will become experienced enough to review beginners myself.

Tips for an Unfamiliar Project

Start with the layout inside the src folder and compare it with front-end project structures you already know. That usually gives you a rough idea of where things live. For a folder you have never seen before, search what it is for, assuming the project uses sensible names.

It also helps to run the project while you explore it. Matching actual pages to the folder structure makes the project feel much more concrete.

If you have investigated and still cannot understand something, ask a senior developer. You might not explain the question perfectly and get corrected a little, but mental resilience is part of the job.

In a standardized project, variables and functions are often wrapped in a module and connected through export and import before they reach the file you are looking at. Use search, such as VS Code's global search, to look up a variable name. You can usually find its types, store, definition, and usages, which tells you where it came from and where it goes. It is also useful for finding leftover console.log() calls.

I Give Up

I surrender. Front-end development has defeated me.

Postscript

This is so embarrassing to reread at the end of 2025.

A Quick Introduction to Front-End Project Folders

Sun, 27 Oct 2024 00:00:00 GMT

This article was translated by AI from the Chinese version.

A Disclaimer

This post is for front-end beginners and is meant to be easy to follow. I will only explain a few folders: beginners do not need to know everything yet, and I do not know everything either. Please point out anything I describe incorrectly.

The Overall Structure

Let us first look at the file structure of a basic Vue project.

The `src` Folder

Now let us look more closely at src. Recognizing its structure makes writing code much more comfortable. Please do not become the person who throws files anywhere.

Here is the structure of my blog project, which is an Astro project.

Different project types have different files in src, but first learn the common ones:

pages (views in Vue): page files such as login.vue and register.vue. Each one maps to a real page in the project.
assets: static resources such as images that are rendered in the front end.
components: reusable UI pieces. For example, the navigation bar at the top of this blog is a component. Every page uses it, but there is only one copy of its code. Components are one of the core ideas in front-end projects, and this folder is often further divided by purpose.

These are the basics that almost every project has. Here is another src structure from a Vue project.

router: where Vue router configuration lives. Search for Vue Router if you want to learn the details.
layout: this leads to the idea of nested layouts. You can write a large reusable template, such as layout.astro or layout.vue, for the general structure of pages. Then individual pages import that template and put their own content inside it.

Finally

There are many folders I have not mentioned. Some may be important, but I do not know enough about them yet. A useful first step is to translate or search the folder name; most of the time, that tells you its purpose.

You may have noticed that many folders correspond to a large area of front-end knowledge. You can learn piece by piece from your own project structure, or from someone else's project.

Zayee

On My Way

Test: Try to write a short poem

I'm on my way

I'm on my way to run away

Why I'm back to my way?

24-26, Computer Major, and Thoughts on AI Era

Introduction

Choosing college preferences —— decide to learn Computer Major —— 24.7 - 24.9

Adapting to college life, and laying foundations for future choices —— 24.9 - 25.2

Make a rough decision to work as a developer —— 25.2 - 25.9

Crush? Break down? Wake up? - 25.9 - 26.2

Bet on Embodied Intelligence

Consider studying abroad

END

From a 2.3 to a 3.6 GPA: What I Did

This article was translated by AI from the Chinese version.

Some Random Thoughts

General Study Method

Courses Scoring 85 or Above

C Programming

Data Structures — 91

Weeks 1–5: Labs Only

Weeks 6–8: Midterm Preparation

Weeks 9–13

Weeks 14–16: Final Review

University Physics II B — 89

Java Programming — 88

Computer Networks and Data Structures Course Projects

Mao Zedong Thought and the Theoretical System of Socialism with Chinese Characteristics — 87

Courses Below 85

Marxist Theory — 84

Computer Networks — 82

Getting Through Final-Exam Weeks

Ending

SSR Part 1: From Rendering Patterns to Simple SSR Problems

This article was translated by AI from the Chinese version.

A Little Rambling

Introducing the Ideas

Start with Rendering

Static Rendering

Client-Side Rendering

Server-Side Rendering

Before Step One: Rendering on the Server

Step One: Get the Static Files

Step Two: Client Hydration

Step Three: Normal Client-Side Operation

Common Problems

localStorage Cannot Be Used on the Server

Some Requests Should Not Run on the Server

Errors During Client Hydration

Closing Thoughts

References

Fixing a Hydration Problem I Ran Into

This article was translated by AI from the Chinese version.

The Scenario

Feature Design

The First Design

The Problem

The Fix

The Brute-Force Solution

The Actual Fix, Written on 2025-11-11

ZJUT Major Transfer (Computer Science) Experience Sharing | A Guide(?

This Passage is translated by AI from zh version

My Situation

Timeline / Difficulty Description

Materials to Find & Info to Notice

Preparations on Your Abilities

Filling Out Preferences

My Coding Exam + Interview Experience

Coding Exam

Interview

Is Element UI Really That Good? Notes from Using It

This article was translated by AI from the Chinese version.

Introducing Element UI

Components

Content Components

Layout and Feedback Components

A Drawback

Other Notes

`localStorage` Cannot Be Used on the Server

Adding `scoped` While Overriding Component Styles

The `src` Folder