Forem: TuanNQ

How I optimize my React Flow application

TuanNQ — Mon, 03 Nov 2025 09:44:24 +0000

I recently built an application to help visualize the structure of each API defined in an OpenAPI file. It renders a nice graph to show how all the reference objects in an API connects to each other, making it easier to understand complex APIs at a glance.

You can try out the application here.

While I built this application as a side project to support my work at my company, I ran into a few interesting performance challenges. To solve those challenges, I went from grabbing the tool which all React developer would think about first like memo to the more advanced yieldToMainThread to learning how browser render a frame and then went back to React with useDeferredValue.

I want to share with you three of my optimizations and one of my still unsolved challenge:

Memoizing the React Flow node
Prevents unnecessary component re-renders, especially when dealing with a lot of complex nodes.
Yielding to the main thread
I initially tried using a worker thread, but it... actually make the performance worse. Instead, I yield control back to the main thread to avoid blocking the UI.
Using useDeferredValue
This React hook helped break up complex updates and delay rendering less urgent updates.
Unsolved problem: defer an already deferred component
I can't find a way to make React not rendering all the left over heavy components all at once.

The problem

When running my application on my low-spec machine, I noticed something odd: the CSS transitions weren’t consistently smooth. Sometimes the item on the left sidebar transition quite smoothly, but sometimes it would cut in suddenly with no animation. The FPS drops and the transition feel abrupt.

Notice the item I click on the left sidebar

I don't know if you can see it but the item on the left sidebar feel very unresponsive. There's a noticeable delay of about half a second when I click on it before the background turns blue to indicate selection. The ripple effect is choppy and sometimes does not even run at all!

Here's how it should be:

When I click on an item, it responds almost instantly. The CSS transition is smooth, and the ripple effect runs seamlessly.

Memoize the React Flow node component

I turned on react-scan and it gave me the first clue: the PropertyItem component was re-rendering way too much - around 3 times more than it should be.

The PropertyItem component somehow renders a total of 380x times!

The PropertyItem component is responsible for each property of an object as you can see below.

Though this particular API is quite complex and has a lot of reference objects, it's definitely didn't have a total of 380 properties!

It turns out that PropertyItem component was re-rendered about 3 times more than necessary because its parent, the ComponentViewer component, was re-rendered 3 times.

As the ComponentViewer component is one of my React Flow node component, it led me to the idea of memoize it. Turns out, it's mentioned right there in the React Flow performance docs that you should memoize the React Flow node component to avoid unnecessary renders. I hadn’t done that!

I memoized my React Flow node component - the frame rate improved, and switching between APIs felt somewhat smoother.

First rule of optimization: do less.

After the change, react-scan no longer complained about excessive component re-renders. But now, it complained about the Javascript/React hooks execution time took too long.

What does that means?

The hint is that while when switching between API's that have small graph, the CSS transitions is quite smooth. But with more complex graph APIs, the CSS transition was still noticeably sudden and the frame rate drop. So the warning means that my calculation to rendering a complex graph took too long.

This is one hell of a complex graph

This time, I can't find a way to shorten the long Javascript execution. To rendering a graph for a complex API, there are calculating-heavy steps needs to be taken.

But why does the heavy calculation to rendering a graph affect a totally non-related item on the left sidebar?

Yield to the main thread

It turns out that the CSS transition share the same thread with my Javascript. That means the browser can only do one thing at a time - either the CSS transition or my Javascript, but not both simultaneously.

So when my JavaScript blocks the main thread for too long (like rendering a huge graph of complex API structure), the browser has no time left to render the CSS transition - and it ends up looking janky or skipped entirely.

The long Javascript execution in the middle make the CSS transitions at the end feel sudden

While I can't do less, I can tell the browser to pause my Javascript in the middle for a few times, run a little bit of that CSS transition, and then come back.

This will make the CSS transitions feel much more responsive and smoothly.

There're a few different ways to break up long task in Javascript, one of them is yieldToMainThread. I use it in the heavy for loop and in recursion function like this:

for (const node of nodes) {
  ...
  await yieldToMainThread();
}

  const addNodeAndEdge = async (component: ComponentNode | PathNode) => {
    await yieldToMainThread();
    ...
    addNodeAndEdge(children)
    ...
  }

Each time that long for loop or the heavy recursion function runs, the browser can pause the JavaScript execution briefly at my yieldToMainThread to run the CSS animation, then resume processing.

Now the CSS animation now feel just as smooth as if the browser don't have to do gargantuan amount of calculation to render that huge complex graph anymore.

If you can't do less, try smarter scheduling.

What about worker thread?

If my Javascript took too long to run, should I run it in a separate thread? That way, the CSS transition can still smoothly run in the main thread while the worker thread do the heavy lifting.

I tried that and surprisingly, the result is... worse. But why is that?

It's because I can't offload the whole process to the main thread - I can only offload a small part of it. Here's the detailed explanation.

To render a graph of an API, there are 4 steps:

Based on the API schema, create nodes and edges in React Flow
Render those nodes to measure their width and height.
Use DagreJS to calculate the position of each node based on its width and height
Render those nodes again in correct position.

Because I need to render all the nodes first to measure their width and height, I can’t offload the entire calculation process into a worker thread. DOM rendering need to stay in the main thread.

Instead, only offloading the layout calculation (step 3), where DagreJS computes each node’s position, made sense.

Ironically, most of the heavy-calculating steps need to stay in the main thread

But create a new thread, sending and receiving messages between threads do have a cost. You need to serialize the message (convert from Javascript object to string) to send to another thread, and to receive a message, you need to deserialize it (convert from string to Javascript object).

With only 20-30 nodes, the node's positioning calculation is so fast that it’s actually better to do it on the main thread than to pay the overhead of messaging between threads.

But this is not the only reason to not use worker thread.

The glorious flashing second

If I use worker thread, you'll see a flash second where the nodes are rendered in wrong position like so:

In fact, I can't even make the calculate node's position step asynchronous (else you'll see that flash second) - let alone offload it into another thread!

Before diving into why, first let’s understand how the browser renders a frame.

To render a frame, the browser goes through four main steps:

Style - Apply CSS rules to each element.
Layout - Calculate the size and position of each element in the DOM.
Paint - Convert elements into actual pixels on the screen.
Compositing - (if needed) Layer elements correctly, especially for things like animations, z-index, and transforms.

Here's the official documentation

Earlier where I said React Flow render all nodes to calculate each of its width and height, I... simplified it a bit. React Flow does not actually render all the nodes to the screen to measure their size.

If the browser complete the paint and compositing step before React Flow measuring those nodes, users will see a flash second where all the nodes are in wrong position.

Instead, React Flow lets the browser complete up until the layout step - calculate size of each nodes. Then, just before the paint step, React Flow intercepts the process and gives me access to each node’s dimensions.

Now I can compute the correct position for every node.

Once that's done, I then make the browser render again with correct position of each nodes. That way, the users will not see a flash second where all the nodes in wrong position.

When I make the calculating each node's position step asynchronous or offload to another thread, now suddenly the main thread is free again. The browser will use that free time to render all the nodes their wrong position - and that's why you see that flash second.

Sometimes you came up with an "optimization" that performs even worse.

Bonus: if you want React to pause the browser right before the paint process, you can use useLayoutEffect - which has an excellent article about it here

Conclusion

That's it for part 1, in part 2 I'll talk about how the laggy CSS transition in the left sidebar come back and how I use useDeferredValue to deal with that.

Have a nice day!

Credits

If you like the cute fish that I'm using, check out: https://thenounproject.com/browse/collection-icon/stripe-emotions-106667/.

Oh boy I love those fishes!

How I help a huge enterprise React project run dev 5x times faster

TuanNQ — Sun, 07 Sep 2025 07:31:39 +0000

TLDR: Please don't use CRA (Create React App). For small project, use Vite, for a huge enterprise project, use Rsbuild.

After 3 months stay at home chilling after finally graduate college, I passed the interview and was admitted into a huge corporation that primarily do the outsourcing job. (I was kidding, that 3 months waiting was mentally miserable!)

Then after a week of "learning" "corporation culture" and "study coding guidelines", I received the first serious assignment: coding the screen according to the documentation I was given.

The first step is clone and run the project. It was a huge enterprise 'monorepo' React project. After a config a tons of proxy networks because of security reasons, I spent 3 hours just to clone that project from a remote repo.

It basically consists of at least 7 small React applications (that I know of):

main_app_1 and main_app_2: this is 2 big parts of the application
This 2 big parts use the lib and common
lib and common in turns use components and ui_elements
components consists of more "advanced" elements and features that based on ui_elements
All 6 of this is then feed into container which is a Create React App project

Here's how you run the project, a more senior developer explained to me. Imagine 6 projects main_app_1, main_app_2, lib, common, components, ui_elements is like a "library". You first have to "build" this "library" into a dist folder, then the container will import and use from that to run the application.

The whole project was written in Typescript, so in order for the container to use it has to be compiled down to Vanilla JS using tsc (Typescript compiler) that bundle along with Typescript.

After spending another 3-5 hours to wire it all together with PNPM Workspace, and then waiting for an eternity to compile all of those gigantic project to Vanilla JS, I was finally able to run the whole project and start to get productive. Type pnpm dev in the console and start coding!

But there was just a small problem. Each time I wrote something I have to wait 30 minutes for it to appear on screen. If I was lucky. If I'm not lucky my computer will tell me "Out of memory" and I have to start all over again.

Even waiting for the dev server to start took about 5 minutes. And the bundle.js file it produces was so large that the browser spend another 2 minutes to load and process over it.

I requested more RAM and CPU for my poor computer. I was denied because technically I was "On Job Training".

This was crazy, I thought. There's no way anybody can develop in such an environment like this! Those more senior developers must all have a much more powerful machine than me. So I asked the more senior developer who helped me run the project how long he had to wait.
"Oh about 5 minutes", he said.
"So each time you write console.log() you have to wait 5 minutes for it to run, right?"
"Yeah, but obviously we'll write a bunch of code before save and wait again", he giggled.

That's fine for him, but what about me? In a gigantic insane React codebase with no documentation, how can I complete my assignments that forces me to use some obscure components if each time I console.log I have to wait 30 minutes? I calculated that each day I'll have a maximum of 16 tries to run my code. Finishing my assignment was impossible.

After seriously considering all my options, I decide to put the assignment aside and try to make the build dev process faster. I probably gonna lose my job anyway, so why not take a risk?

The compiling and Create React App bottleneck

Looking at the build process, I saw 2 major bottlenecks: tsc (Typescript compiler) and CRA (Create React App).

Each time I run the watch or build command, which uses tsc, I have to wait about 10 minutes for it to complete running. In fact, due to insufficient RAM, my watch command does not run at all! Despite I only watch 1 project (out of 6).

Why was it so slow? Turns out tsc was slow not because it was slow. It was slow because it has to meticulously check all types in project in order to generate the .d.ts file.

Next is the Create React App development server. It re-bundling 10.000 - 20.000 files again each time I add a new console.log().

Change tsc with swc

First, I dealt with the tsc bottleneck. Those .d.ts files are only necessary for one project to understand what types of another project.

But since the majority of time we developers just need to work on one project, re-generate all the .d.ts files of that project is unnecessary. When working in just 1 project, the Typescript Language Server (built-in in VSCode) will do all the type checking in the opened file for us.

Is there a way to just generate Javascript straight out of Typescript fast without worrying about types? After a bit of searching I found swc came to the rescue.

SWC is really fast. It's fast because it only compiles Typescript to Javascript without doing any of the type checking.

Compare to tsc took about 5 - 10 minutes just to compile, swc took about... 10 seconds to compile the whole project. While tsc watch does not work at all swc watch took only few hundreds miliseconds to compile the changed file!

Type checking is good and necessary but in this case speed is everything. When I focus on coding and trying your idea out, the feedback cycle more important than the "type correctness". But when I finish my implementation and ready to submit / push your code, that's the time to focus the "type correctness". So each time I create a PR I just need remember to run tsc again to check type and everything should be good.

The tsc replacement was relatively easy compare to next major bottleneck: replace the CRA (Create React App).

Replace CRA (Create React App) with Vite

When thinking about CRA (Create React App) alternative, the first option come to your mind is probably Vite. So am I. So I tried to replace CRA with Vite.

First, I build a simple CRA app in my computer and tried to replace it with Vite. To my amazement, it was quite simple to replace CRA with Vite. I don't have to change any code. It has only basically 3 steps:

Install Vite as a dependency
Create a vite.config.ts with the React plugin
Create an index.html file with the #root div in the root project instead of in public folder

With my small CRA project changed to Vite ran smoothly, I begin to work on the behemoth enterprise React app. First, I have to find and read and understand all of its config file.

After have a vague understanding of what config is needed to run that behemoth monster, I replicated it and found and install the equivalent Vite plugins. Next, I typed npm run dev in the console, hit Enter, and prayed.

The dev server did not even run. I was hit with this error:

Error: COMMITHASH is undefined

Why is that? The behemoth CRA app use git-revision-webpack-plugin so I install the equivalent of Vite which is vite-plugin-git-revision. But this 2 plugins does not work the same. In git-revision-webpack-plugin you only need to use the global COMMITHASH, but in vite-plugin-git-revision that global is GITCOMMITHASH.

I don't want to change any source code but only the configs, so I searched for configs of vite-plugin-git-revision in their documentation. But after quite a while I finally decided to write my own little custom config based on the source code.

Here's the diagram of my little custom config:

Here's the demo config:

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react-swc'
import { exec } from "child_process";

const getCommitHash = new Promise<string>((resolve, reject) => {
  exec("git rev-parse HEAD", (err, stdout) => {
    if (err) {
      reject(err);
    } else {
      resolve(stdout);
    }
  });
});

const getVersion = new Promise<string>((resolve, reject) => {
  exec("git describe --always", (err, stdout) => {
    if (err) {
      reject(err);
    } else {
      resolve(stdout);
    }
  });
});

const getBranch = new Promise<string>((resolve, reject) => {
  exec("git rev-parse --abbrev-ref HEAD", (err, stdout) => {
    if (err) {
      reject(err);
    } else {
      resolve(stdout);
    }
  });
});

const getLastCommitDateTime = new Promise<string>((resolve, reject) => {
  exec("git log -1 --format=%cI", (err, stdout) => {
    if (err) {
      reject(err);
    } else {
      resolve(stdout);
    }
  });
});

export default defineConfig(async () => {
  const [commitHash, version, branch, lastCommitDateTime] = await Promise.all([
    getCommitHash,
    getVersion,
    getBranch,
    getLastCommitDateTime,
  ]);

  return {
    plugins: [react()],
    source: {
      define: {
        VERSION: JSON.stringify(version),
        LASTCOMMITDATETIME: JSON.stringify(lastCommitDateTime),
        BRANCH: JSON.stringify(branch),
        COMMITHASH: JSON.stringify(commitHash),
      },
    },
  };
});

I ran the development server again and prayed.

But I was hit with another error:

Error: process.env is undefined

Why is that? Turns out according to Vite, all environment variables must start with VITE_, otherwise Vite will not recognize it.

So, for example, in CRA environment variable is DEFAULT_LANGUAGE, in Vite it should be VITE_DEFAULT_LANGUAGE. Worse still, while CRA use process.env, Vite use import.meta. So I have to replace all process.env in the codebase with import.meta.

There's no way I'm gonna find and replace all process.env with import.meta in the whole codebase! If I do so each time I commit and push anything I'll have to be super careful and change it back to process.env all over again! That's unacceptable.

So after a quick search, I found a solution:

import { defineConfig, loadEnv } from 'vite';

export default defineConfig(({ command, mode }) => {
    const env = loadEnv(mode, process.cwd(), '');
    return {
        define: {
            'process.env.YOUR_STRING_VARIABLE': JSON.stringify(env.YOUR_STRING_VARIABLE),
            'process.env.YOUR_BOOLEAN_VARIABLE': env.YOUR_BOOLEAN_VARIABLE,
            // If you want to exposes all env variables, which is not recommended
            // 'process.env': env
        },
    };
});

Instead of using process.env which is unavailable, Vite find and replace all the string process.env.YOUR_STRING_VARIABLE in the codebase with the provided value. For example, if my code has process.env.DEFAULT_LANGUAGE, Vite will replace all of that string instance with the provided value (like "en").

So after meticulously find all the environment variables in that behemoth monster and put in to the config, my dev server finally run!

Contrary to CRA development server took about 10 minutes to start, the Vite development server start almost instantly. Though each time I enter a new URL into the browser, I had to wait 5 minutes for the page to load. That was quite long, I thought, but it is expected from running that behemoth monster.

But when I change a file, Vite HMR did not work! I had to stop and restart the development server again for the change to appear in the browser!

I tried to replicate the same config, environment, dependencies into the small test app in my computer but Vite works just fine. It seems that Vite HMR only died when dealing with such a behemoth monster of this scale.

Trimming 30 minutes waiting down the 5 minutes was a major improvement, but that's not good enough for me. Is there another alternative which is even faster that Vite?

After a quick search "Vite alternative", Reddit pointed me to Rsbuild.

Replace Vite with Rsbuild

Right from the get go Rsbuild promise you can consider it like a easy-to-replace, similar with Webpack based development tools like CRA,... Indeed, a lot of Webpack plugin works seamlessly with Rsbuild. The whole git-revision-webpack-plugin that I took hours to read, understand, debug and re-create can now just be used directly in rsbuild.config.ts.

Unlike CRA, Rsbuild use import.meta instead of process.env. But having to deal with that problem with Vite once, this is a piece of cake.

After copy all the environment variable config from Vite into Rsbuild, I started the dev server and prayed.

It works! After about 30 seconds, the development server started up.

I added a console.log('hi there') to a file. I held my breath. Is the HMR going to work?

4 seconds later, hi there appeared in the console. I added a <div>Hi there</div>, 5 seconds later, it appeared on the screen.

It felt like a miracle! Compare to CRA's start up time 30 minutes and constantly died because of insufficient RAM, Vite 5 minutes but HMR still not working, Rsbuild start up with only 20 - 30 seconds and HMR only 5 seconds feels like voodoo black magic forbidden quantum science come from the future.

According to the benchmark on the homepage, Rsbuild promise 3x faster than Vite + SWC. At first I was quite skeptical of that (how many "blazingly fast" claim did you hear?).

But in this real-world project from a real developer standpoint, it's not just 3x faster than Vite, it's 10 - 20x faster than Vite! I've never seen any project so amazing but so modesty in its claim.

I wish I could benchmark Vite and Rsbuild on this project and send to Rsbuild team as a testament of how good Rsbuild actually is... but I can't. As my company is a majorly outsourcing corporation, this project is confidential and belong to the customer.

I tried to search Google to find out why Rsbuild is so fast but can't find any result. If you know how Rsbuild works, why it's that so fast, please leave a comment, I'd love to know!

The irony aftermath

After about 3 - 4 days researched how to convert from CRA to Rsbuild, I finally can just complete the inane assignment in just 3 - 4 hours. Then I had to be "audited" by a Solution Architect who actually design the whole architecture of this behemoth monster. The purpose of the "audit" is for me to be judged whether I'm "ready to work" or not.

After answering all the inane questions that a Fresher / Junior developer like me suppose to answer, I surprised him by showing the 4 seconds wait time and all the diagrams above explaining how I do that. It took a while but finally he understand all the .d.ts, tsc, swc, CRA, Rsbuild, build processes, development processes ideas stuffs. He said he would "welcome any contributions".

1 - 2 weeks later, based on my solution, the somewhat more advanced by the Solution Architect with more colorful and flowery command line was put in for the whole huge FE team to use.

So what about my pay raise? Oh I'll continue to be a Dev I and have to wait until the end of the year to get a "performance review". Saving 5 minutes for each development cycle for each developers multiply by 20 ~ 30 devs must be a great financial saving for the corporation, I guess. Just wait until the end of the year and they'll consider give me a pay raise. I'm waiting each day everyday in the whole year for that.

But put all of the compensation and corporate's politics aside, here came the obvious question. Why nobody came up with a solution like mine? After all, if a random guy like me with a bit of tinkering can do this, why didn't all those "more senior developer" come up with any solution?

The answer has 2 parts.

Part 1 is that not a lot of people understand the build process and keep up-to-date with the current state of React tools. In fact, out of all "more senior" developers I asked, only 2 - 3 understand what they're doing. The others, despite already working for 1 - 2 years in this project, don't have a slightest idea of how all the setup work. This is expected.

But part 2 of the answer is totally unexpected. Turns out the waiting 5 minutes for build dev is totally not a bottleneck. It's fast. It's blazingly fast compare to all the time to just reading and understanding the Requirement document and following the corporation's procedures. For 7 - 8 hours of actual coding, you have to spend 1 - 2 weeks to understand what you supposed to code. The Requirement document is not written for human to understand, it's like law book written in Latin supposed to blame anybody-but-me when things go wrong. And it's often wrong and contradict with itself so you have to ask those write those Requirement document to "revise" it. And all the questions you ask him to "revise" it? Oh it has to be documented too.

From a standpoint of a guy who try to spend every minutes of waking moment to do something productive, this kind of inefficiency is wild. All for blame game.

But at least my client has a lot of money to spend though.

If you have any good job, please contact me. I'd love to know.

Credits

If you like the cute fish that I'm using, check out: https://thenounproject.com/browse/collection-icon/stripe-emotions-106667/.

Oh I love those fishes!

Git for grad students (part 3)

TuanNQ — Sat, 23 Aug 2025 04:29:43 +0000

In part 1 and part 2 we've learned about how work locally with git, in part 3 we'll learn about the final piece: how to work with remote repository (aka Google Drive for developer).

Just like Google Drive and Dropbox probably are two of the most popular file storing services, in the developer world Github and Gitlab are two of the most popular services to upload your project to.

In this article I'll use Github. But since all of the "remote repository" services are very similar, you can apply what you learned in this article to any specific services you encounter.

Create a new repository on Github

First, if you don't have a Github account, create one. It's free! You only need an email and / or a phone number for it.

If you not yet in the right mood to signup for a new service, you can continue to read on, I'll draw a bunch of diagrams for you to understand what I'm doing!

After having a Github account, let's create a new repository.

You can click the green "New" button on the left or click on the + in the menu and then click on the "New repository" button like this:

After doing that, you'll enter the Create a new repository screen like this:

I'll name my repository simple-git-tutorial, just use the default settings and click the green "Create repository" button at the bottom.

After that, you'll be greeting with this screen:

This means that your repository has been created successfully and Github now asks you to push your project into it. It's like you create a new folder in Google Drive and then Google Drive asks you to upload your files into that folder.

The first instruction part you see on the screen "...or create a new repository on the command line" is for when you create a new remote repository on Github before you create a new project on your computer.

The second instruction part you see on the screen "...or push an existing repository from the command line" is for when you already have a project on your computer and you want to upload this to this remote repository. It's like you already have a folder in your computer and you want to upload all of its content to a folder in Google Drive.

Since we already have a project in our computer, let's go with second part. But what are those strange commands:

git remote add origin https://github.com/**************
git branch -M main
git push -u origin main

...mean?

Let's explain the first command:

git remote add origin https://github.com/**************

git remote add origin

This command inform git about the remote repository that we want to push / pull (think upload / download) from it. We call it "origin" and provide the url to that remote repository.

Say if you want to name the remote repository "asdf" you'll run a command like this:

git remote add asdf https://github.com/**************

But by convention we'd call the remote repository "origin" so I'll stick to that:

git remote add origin https://github.com/**************

I mean copy and run this command that Github kindly provide us.

Just like you can upload one folder on your computer to multiple file storing service like Google Drive, Dropbox, OneDrive,..., you can also have many remote repositories.

If you run 3 commands like so:

git remote add origin https://github.com/**************
git remote add asdf https://gitlab.com/***************
git remote add qwer https://bitbucket.com/***************

...you'll now have 3 remote repositories: origin, asdf and qwer.

To view all remote repositories in your project, run:

git remote -v

Here's an example of mine:

origin  https://github.com/************** (fetch)
origin  https://github.com/************** (push)

This means that git knows that I have a remote repository called "origin" at url https://github.com/************** and I can fetch (imagine download) and push (imagine upload) to it.

git branch -M

This command is for renaming current branch. For example if you accidentally create a branch with a typo like this:

git checkout -b feature/printtt_1

...and now you want to rename it to feature/print_1, you can use the git branch -M command like so:

git branch -M feature/print_1

But that leaves us with the question, why do Github want us to rename our branch to main?

Back to the analogy about group project. Nobody is allowed to change the original file. Instead one must create a copy of that file and then the leader review and merge back to it.

By default, the "original file" is equivalent to the master branch on Git. But several years ago, Github want us to have the main branch is the "official branch" instead of master.

You can rename your master branch into main if you like but I'll ignore this command. After all master and main only different in name.

git push -u origin

This command is to create a new branch in the remote repository called "origin" with the same content and name as your local branch.

So the command in the instruction on Github:

git push origin main

means that Github want us to push the main branch on our local computer into remote repository called "origin" on Github.

For example, if you want to push a branch called feature/print_1 into your remote repository on Github (that you named "origin"), you can use this command:

git push -u origin feature/print_1

The command git push -u origin [branch-name] also equivalent to git push --set-upstream origin [branch-name].

But in my case since I want to push all branches into our new remote repository I'll use the following command:

git push origin --all

Now if you refresh your Github repository page, you'll see this:

So that's how you create a remote repository in Github and then push your branch (think upload) to it!

Finally on the topic of setup a repository is git clone.

git clone

Imagine you're a new member join a team and you have to download the team's project to your computer. You can use git clone and then provide the url to the remote repository like this:

git clone https://github.com/***********

On Github, you can find the url of a repository by click on the green button "<> Code" and then copy the url below.

The full workflow

Finally let's get to the meat of this series: the full workflow of what you would do if you're receive a new task.

Here are the steps:

Switch to the main branch (imagine this branch is like the copy of the original file on your computer)
Get the latest update
Create a new branch from it
Do the task
Add and commit
Push your newly created branch to the remote repository
Create a Pull Request (or a Merge Request if you're using Gitlab)

Imagine you have a new task: add console.log(3) to main.js.

Here are the steps you'd do:

Switch to the main branch (git checkout master)
Get the latest update
Create a new branch from it (git checkout -b feature/print_3)
Do the task
Add and commit (git add main.js and git commit -m "add console log 3")
Push your newly created branch to remote repository (git push -u origin feature/print_3 or git push --set-upstream origin feature/print_3)
Create a Pull Request

Let's go through this step by step.

First, let switch to the master branch:

git checkout master

To get the latest update of the master branch on remote repository, use the command git pull origin [branch-name] like this:

git pull origin master

Remember to always pull the latest update to avoid conflict!

Next, let's create a new branch called feature/print_3:

git checkout -b feature/print_3

Now, on main.js, add the following:

console.log(3);

Let's add and commit this change:

git add main.js

then

git commit -m "[feature] add console log 3"

Next, let's push this branch to our remote repository on Github:

git push --set-upstream origin feature/print_3

If you head back to your repository on Github and refresh, you'll see this:

This means that you've push your branch into your remote repository on Github successfully! The next step is to create a Pull Request.

You can use the short way click on the green button "Compare & pull request" or use the long way I'll show below.

First, click on the Pull Request tab on the topbar. After that you'll see this screen:

Next, click on the green "New pull request" button. After that you'll see this screen:

Make sure to choose the base branch to master and the compare branch to feature/print_3 as we want to create a pull request to merge branch feature/print_3 into master.

Now click on the green "Create pull request" button. You'll see this screen:

After adding title and description, click on the green "Create pull request" at the bottom. Now you'll see this screen:

You've created a new Pull Request successfully! Congratulations! This is the final step to complete an assigned task as a member!

Optional: the `develop` branch

In the "real world", one project has many "official" branches for many purposes, like master or main is for actual production deployment, staging for deploy to staging server, and develop as a "main" branch for developers to merge all their works into it. Usually you'll merge into the develop branch instead of directly to master.

Review and merge a Pull Request (or Merge Request)

Since we're the leader of ourselves, let's review and merge our own Pull Request.

To review a Pull Request, you can click on the Files changed tab to review what has changed.

You can see in line 3 of main.js I add a new line console.log(3). This is exactly the task I was assigned and I completed it successfully. So I'll merge my own Pull Request!

To merge a Pull Request on Github, click back on the Conservation tab and click on the green "Merge pull request" button below.

After doing that, you'll see this screen:

This means that you've merge the Pull Request into the master branch successfully! If you go to the "Code" tab, choose the master branch, then click on the main.js to view its content, you'll see the console.log(3) at the line 3:

This means that you merged a Pull Request successfully!

Now you know the workflow of a member and understand what a leader do, here's a diagram explains how all things connected together:

Tasks that depends on each other

Another thing I think it's worth highlighting when you work at a real project is when you have tasks that are depends on each other (i.e you have to complete one before the next).

If all tasks you have are independent with each other, that's simple enough. Just follow the workflow above again and again. Switch to the master (or develop) branch, get the latest update, create a new branch from it, do the work, push to Github, create a Pull Request, wait for leader to merge, switch to master,...

But what about tasks that depends on each other? What if you have to complete task #1 before task #2?

If you complete task #1, but your leader not yet review and merge that pull request, and switch to master and pull from remote repository, the master branch will not have the code needed to do task #2.

"Incorrect" ways

At first, you might tempt to do task #2 on the task #1 branch.

But if you do task #1 and task #2 on the same branch and then push, your Pull Request originally for task #1 now contains both code from task #1 and task #2. A Pull Request just care about the base branch and target branch, it does not care about a single task or a commit.

To explain why a Pull Request consists of 2 tasks is not good, let's imagine a situation that a little bit more extreme.

You create a Pull Request for a combination of 5 tasks. Now imagine you're the leader who review the code. Do you want to read one huge Pull Request consists of 1000+ changes across 5 tasks or 5 separate Pull Requests each one 200+ changes for an individual task?

Sometimes your task is so complicated that one Pull Request has thousands upon thousands of changes span across multiple files, but if possible try to make one Pull Request as small and simple (like one for each assigned task or bug at a time).

Back to our problem, you might also temped to wait for your leader to merge your Pull Request before continue to the next one like this:

But of course this is quite... inefficient. A leader might have to review multiple Pull Requests before yours.

Solution

So the "correct" way of solving this problem is quite simple: merge the task #1 branch into task #2 branch.

This way, when you push your task #2 branch to the remote repository and create a Pull Request from it, it'll be 2 Pull Requests, each for one task only.

But wait, you said. If I do so isn't that Pull Request #2 also contains code from both task #1 and task #2?

Correct. But your leader will review and merge your Pull Request #1 before Pull Request #2. After he merge Pull Request #1, when he open the "File changes" on Pull Request #2, he'd only see the difference between the task #2 branch and the master branch, which is just the necessary code to complete task #2.

Conclusion

Congratulation for reading until the end of the series! I hope you find this series helpful.

Despite everyone using git and git was created for a decade now, I was quite surprise that there were not a lot of tutorials for absolute beginner teaching how everybody use git to work together.

When I was in university, each time we had a group project we'd sent zip file to each other because nobody knows how to use git. More correctly is nobody knows how to use git to work together. Somehow the workflow you see above is a secret that you can only know about if you work at a company. But if I worked at a company I'd not be there study at college. And my college despite loves to assign us group homework never taught about how to do that. They'd rather teach about stuffs like Math, theory of OOP, Linked List, Tree,... instead of teaching about how people do in their everyday life. And while they make a ton of money, a lot of us graduate feel like a burden for a team / company because we don't know the absolute basic of thing (if we lucky enough to have a job at all).

Despite the situation is hard out there (in fact, the US had more developers in 2018 than now, source), I hope this article is helpful for you to become a better at your job or finding a job. I also hope that this article will help good small businesses out there who don't have money or time to train a young, enthusiastic graduate but have no experience, can now find a graduate who'd more quickly get the hang of thing.

Credits

If you like the cute fish that I'm using, check out: https://thenounproject.com/browse/collection-icon/stripe-emotions-106667/.

Git for grad students (part 2)

TuanNQ — Sun, 10 Aug 2025 03:51:11 +0000

In the first article I talk about the basic of Git versioning.

In this article we'll talk about a revolutionary feature of Git: branch.

What problem does Git branch solves?

Back to our Google Slides example.

To solve the accidentally changed problem, anyone want to the edit group's slide would have to do this:

Create a copy of the group's Google Slides file
Work on that copied file
Ask the leader to review
Only when the leader agree that changes are merged into the group's file

In order to preserve the original file, anyone wants to work on that file must create a copy of it. In the Git world, it's everyone must create a new branch.

Wait, you said. If 1 people create a copy, working on it, and then the leader upload that into Google Drive is fine, but what if 3 people do it at the same time?

Does the leader have to meticulously copy and paste all changes of each file into a new file and then upload?

In the development world, don't worry, Git will handle that for us!

Call git merge and Git will automatically merge all changes for us!

If 2 people accidentally make change in the same line of the same file, Git will notify you about that "conflict".

To recap:

Create a copy = create a new branch
Merge into one file = merge branch
2 people change the same place = conflict (and then have to resolve conflict)

Let's learn how to do all of that with Git in this article.

Basic workflow

In this section, let's talk about what would you do when leader assign you a new task (aka basic workflow).

By default, you're on branch master. For now let's imagine the master branch is like the original file that shares to the whole group.

If you have a new task, here's what you need to do:

Create a new branch (= copy to a new file)
Do the task then git add and git commit -m (= create a new version)
Merge back into the master branch (= merge back into the original file)

Let's apply that workflow with the previous project in part 1.

View, create, merge branch

In part 1, we created a small project to learn about Git. Here's the current state of that project.

To see what branch that we're on, use the following command:

git branch

Here's the result of mine:

  * master

This meant that I'm in branch master.

Imagine you have a new task: add to index.js a console.log("bye there").

Following the workflow, here are steps to take:

Create a new branch (= copy to a new file)
Add to index.js a console.log("bye there") (do the job)
git add and git commit -m (= create a new version)
Merge back into the master branch (= merge back into the original file)

Step 1, let's create a new branch. To create a new branch, use git checkout -b and then name of the branch.

I'll call this branch feature/bye_there.

git checkout -b feature/bye_there

It's easy to get lost on which branch are we on so let's create a good habit to check what branch are we currently on:

git branch

Here's mine:

* feature/bye_there
  master

This meant that currently I have 2 branch master and feature/bye_there and I'm in branch feature/bye_there.

In index.js, add a console.log("bye there"):

console.log("hello there");
console.log("bye there");

Now let's commit it:

git add index.js

then

git commit -m "[feature] add bye there"

Here's a diagram explain what we did so far:

Great! We complete this feature and then commit it. Next, let's merge it into the master branch. In order to do that, we have to take 2 steps:

Switch to master branch: git checkout master
Merge feature/bye_there into master: git merge feature/bye_there

So first, let's switch back to the master branch:

git checkout master

Next, let's merge the feature/bye_there branch into master:

git merge feature/bye_there

If you open index.js you'll see:

console.log("hello there");
console.log("bye there");

We're successfully merge feature/bye_there into master. Here's a little more explanation about git merge.

When you tell git to merge feature/bye_there into master, git will apply all the changes you made in feature/bye_there into master.

What changes are we made in feature/bye_there? It's:

In index.js add line 2 writing console.log("bye there")

So here's what git does:

Apply change: in index.js add line 2 writing console.log("bye there")
Add and commit on master branch

To recap, here's 5 git commands step-by-step to complete a new task:

git checkout -b [new branch]
git add [file name]
git commit -m [message]
git checkout master
git merge [new branch]

Conflict and resolve conflict

Now you get the basic idea of what to do when having a new task, let's talk about conflict. When do conflict happen and how to resolve conflict? In this section we'll create a situation when conflict occurs and then resolve it.

Imagine you have 2 people that receive 2 new tasks at the same time:

Task #1: Add console.log(1) in main.js file
Task #2: Add console.log(2) in main.js file

This 2 people will create new branch at the same time and do their work at the same time instead of one after another. Here's a diagram explains the different between doing multiple tasks at the same time versus to do it sequentially:

To simulate this, we'll create new branch feature/print_1, do the task and then git add and git commit -m, but not immediately merge into master, instead from master create feature/print_2, do the task and commit on that branch, and only then merge feature/print_1 and feature/print_2 into master.

If that's a little bit... hard to understand, below it's a diagram explain what we're going to do:

Let's tackle task #1 first. Here are the steps we need to take:

Create a new branch
Add file main.js with console.log(1)
git add and git commit -m

First, let's create a good habit of checking which branch we're on:

git branch

Here's my result:

  feature/bye_there
* master

This means that I'm on the master branch. Make sure you're on the master branch before continue.

Next, let's create a new branch called feature/print_1.

git checkout -b feature/print_1

Let's check what branch are we on:

git branch

Here's my result:

  feature/bye_there
* feature/print_1
  master

This means that we have 3 branches and I'm on branch feature/print_1.

Now, complete task #1 by create main.js file with the following content:

console.log(1)

Now, let's commit this file:

git add main.js

then

git commit -m "[feature] add console log 1"

Normally the last step is to merge feature/print_1 into the master branch but as we're not going to do it right now. We're simulating 2 people create new branch at the same time and working at the same time, remember?

We've already complete task #1. Let's tackle the task #2.

Here are the steps we need to take:

Switch to master branch
Create a new branch
Add file main.js with console.log(2)

First, let's switch to the master branch:

git checkout master

Now you'll see the main.js file disappear because in master branch that file does not exist yet.

Let's create a new branch called feature/print_2:

git checkout -b feature/print_2

Let's create a good habit of checking what branch are we on:

git branch

Here's my result:

  feature/bye_there
  feature/print_1
* feature/print_2
  master

This means that we have 4 branches and I'm on branch feature/print_2.

Now, let's do the task #2 by create main.js file with the following content:

console.log(2)

Next, let's commit this file:

git add main.js

then

git commit -m "[feature] add console log 2"

That's great! We've complete task #2.

Now let's head back to the master branch and merge feature/print_1 and feature/print_2 into it.

git checkout master

Let's merge feature/print_1 into master:

git merge feature/print_1

Next, let's merge feature/print_2 into master:

git merge feature/print_2

This is when conflict occurs. You'll see the following in the command line:

Auto-merging main.js
CONFLICT (add/add): Merge conflict in main.js
Automatic merge failed; fix conflicts and then commit the result.

We have a conflict in main.js. If you open main.js, you'll see this:

<<<<<<< HEAD
console.log(1);
=======
console.log(2);
>>>>>>> feature/print_2

If you using VSCode, here's what you see:

Git marks which place have conflict for us by <<<< HEAD, ======, >>>>> feature/print_2. Our job is to make the file correct according to what we're assigned.

But first let's explain why do we have conflict in main.js, what is "HEAD (current change)" and "incoming change" means.

In short, conflict happened because both feature/print_1 and feature/print_2 in the same main.js file in the same line have different content (more exactly is changed differently). In feature/print_1 is console.log(1). In feature/print_2 is console.log(2).

The HEAD refer to which branch we're now: master branch, while "Incoming change" refer to the branch we want to merge into master: feature/print_2.

Here's a more detailed explanation:

First, when we merge feature/print_1 into master, git will apply the changes in feature/print_1 into master. So here's what git does:

Create a new main.js file
On that file main.js on line 1 write console.log(1)
Add and commit (in master branch)

Next, when we merge feature/print_2 into master, git will also apply the changes in feature/print_2 into master. So here's what git tried to do:

Create a new file main.js (already done!)
On main.js on line 1 write console.log(2)
Add and commit (in master branch)

But on main.js line 1 already have console.log(1). This is why conflict happened.

So how do we resolve this conflict? In this situation, we have to do both tasks so we should keep both console.logs.

In main.js remove the <<<<< HEAD, =====, >>>>> feature/print_2 added by git:

console.log(1);
console.log(2);

Now the main.js file have both console.log, which is correct for we have to do both task #1 and task #2. Now that we resolve conflict, let's add and commit the main.js file:

git add main.js

then

git commit -m "Merge branch 'feature/print_2'"

That's it! That's how we resolve conflict!

Explain strange commands from part 1

In part 1, I told you about 2 strange command git checkout master and git switch -c. Now I'll explain it.

By now you probably know that first command git checkout master is to switch to master branch. But not only you can use it to switch from one branch to another but also to escape preview mode too. If you're on feature/print_1 branch and using git checkout [version hash] to preview previous, you can use git checkout feature/print_1 to escape it!

The command git switch -c is to create a new branch from that commit and switch to that branch. That way, you don't have to use git reset --hard which lose all commits after that.

A fun thought experiment

So that's it for part 2. You've done a great job learning all the basic workflow and commands of git! You can reward yourself a good cup of coffee now!

But I have a bonus thought exercise to get you more familiar with the concept of branch and basic commands of git.

Have you ever seen this meme?

Have you ever heard your designer friend complains about he spend hours to change his design for his customer just to be told: "Hey, I changed my mind, I think the original design is better"? Worse, he had to edit it back into the original design because the amount Ctrl + Z 's are limited.

Now you're a developer and you know Git, what would you hypothetically do if you're in this situation:

The customer asks you to edit her photo
Then she asks you to add more dramatic lighting
Then she asks you to use Liquidfy to make her look thinner
Then she kind of regret it and asks you to revert it (oh no it looks so fake!)
Then she asks you to make her hair pink
Then she asks you to make her hair blue to see which one is better
Then she says she like pink hair
Then she asks you to make her eyes look bigger
She satisfies now, pays you and thanks for your service

If you don't know what Liquidfy does, I have this image which will explain for you:

So with that little bit of Liquidfy technical detail out of the way, hypothetically how can we solve this using git?

Here's a diagram explains what we're going to do:

Assume we have a Photoshop file called cute-photo.psd:

The customer asks you to edit her photo
- git init
- git add cute-photo.psd
- git commit -m "initial commit"
Then she asks you to add more dramatic lighting
- git checkout -b feature/dramatic_lighting
- git add cute-photo.psd
- git commit -m "[feature] add dramatic lighting"
- git checkout master
- git merge feature/dramatic_lighting
Then she asks you to use Liquidfy to make her look thinner
- git checkout -b feature/liquidfy
- git add cute-photo.psd
- git commit -m "[feature] liquidfy thinner"
- git checkout master
- git merge feature/liquidfy
Then she kind of regret it and asks you to revert it (oh no it looks so fake!)
- git reset --hard [commit-hash]
Then she asks you to make her hair pink
- git checkout -b feature/hair_pink
- git add cute-photo.psd
- git commit -m "[feature] change hair to pink"
Then she asks you to make her hair blue to see which one is better
- git checkout master
- git checkout -b feature/hair_blue
- git add cute-photo.psd
- git commit -m "[feature] change hair to blue
Then she says she like pink hair
- git checkout master
- git merge feature/hair_pink
Then she asks you to make her eyes look bigger
- git checkout -b feature/eyes_bigger
- git add cute-photo.psd
- git commit -m "[feature] make eyes bigger"
- git checkout master
- git merge feature/eyes_bigger
She satisfy now, pays you and thanks for your service

You might ask why don't people use Git in design space like Photoshop, Illustrator, Blender, Maya,... Is git only works for text files or something?

No it's not. You can definitely version control a .psd or an .ai,... file. If you git add, git commit -m,... it works! The reason people don't do it is that if conflict happen, you can't fix it. Photoshop file is a binary file, which is a bunch of 0's and 1's, you can't read and understand it, let alone resolve conflict.

Conclusion

Let's recap what we've learned so far:

git branch: view current branch we're in
git checkout [branch name]: switch to that branch
git checkout -b [new branch]: create new branch
git merge [branch name]: merge that branch into current branch we're in
Conflict and how to resolve conflict

In part 3 we'll learn about how to work with remote repository like Github, Gitlab: git push, git pull, git clone,...

Credits

If you like the cute fish that I'm using, check out: https://thenounproject.com/browse/collection-icon/stripe-emotions-106667/.

Git for grad students (part 1)

TuanNQ — Sun, 20 Jul 2025 08:13:49 +0000

In this series, I'll show you the basic workflow of how a team of developers use Git and Github / Gitlab to work and colab together.

If you aspire to be a developer but don't understand how all the Git, Github / Gitlab, development workflow stuff fit together and solving what problem, achieving what purpose, then this article is for you. I write this for the past me as a student years ago and for you to not have to go through all the struggle with Git I've been through.

More background on why I wrote this article

When I was in university, my professors / teachers taught me all kind of fancy theories and algorithm stuffs. From Assembly, C to OOP Java, to Database, to Network Theory,... they covered all and more. Memorize all of that? That's great, that's what a future software engineer should know.

But there was a rumor. Only when you start working at a company as an intern, that's when the real learning begin. People will pretend you know nothing, expect nothing from you and teach you every silly little stuffs.

One of that stuff is how to use Git.

If you search Google to try understanding what Git is and how to use Git, you're probably gonna be hit with a bunch of jargon and technical details that you not hope to understand. Hell one of my senior even send me an 8 hours course on Udemy on how to use Git. Damn how can you even begin to code if just understanding what tools you supposed to use would take a PhD?

Luckily that's not the case. Using a tool does not requires to know all technical details about it. It's more about knowing what problem does it solves.

So first, let's try to understand what problem we're facing. You don't want to use the wrong tool for the wrong situation.

What problem are we trying to solve?

Imagine you work on a group project to create a presentation. You create a new Google Slides in your Google Drive and share it to each other. To a team of developers, the Google Slides file is equivalent to the project, and the Google Drive is equivalent to Github / Gitlab. You can imagine Github / Gitlab is the Google Drive / Dropbox for developers.

But here come the next challenge. How to prevent someone in your group accidentally change your slides?

In the Google Slides world we have no way, but luckily in the development world we can achieve that with the combination Git and Pull Request (or in Gitlab is Merge Request).

Let me explain.

To solve the accidentally changed problem, imagine each time anyone want to the edit group's slide would have to do this:

Create a copy of the group's Google Slides file
Work on that copied file
Ask the leader to review
Only when the leader agree that the changes are merged into the group's file

This is wayyy complicated and messy in the Google Slides world, but luckily it's quite simple in the development world with the help of Git. You just need to know a few basic Git command.

But first, let's understand what Git is, what does it do and what problem does it solve. For now I can foreshadow a little bit:

Download from Google Drive = git clone
Make a copy of the file = create a new branch
Upload to Google Drive = git push
Ask the leader to review the changes = create new Pull Request (Merge Request)
Download again to see the updated version = git pull
2 people change the same slide = conflict

What is Git?

Git is a software that you can install on your computer (like Chrome, VSCode, Team Viewer,...). You can go to https://git-scm.com/ to download and click a bunch of "Yes" to install it.

So what does Git do? From a simple viewpoint of me an ordinary developer, Git does 2 things:

Versioning
Branch

What is versioning?

Do you know that you can change back to an older version of a Google Docs file? Like if someone accidentally delete something important in a Google Docs, the whole team would frantically roll back to the last Friday version hoping to see that important thing is still there?

Git offers the same thing for developers. You can create a new version of your project or rollback to old version anytime you want!

Here's a simple diagram about Git versioning:

Create a new version

In the Git world, if you want to make a new version of your project, it called "commit". Each version has a message. Here's the command to tell git to create a new version:

git commit -m "Your message"

But before telling Git to create a new version, let's imagine you have to tell it which files has changed.

For example, let's say your project has one file index.js. You change to content from console.log("hi there") to console.log("hello there"). First, you will have to tell Git the file index.js has changed:

git add index.js

Then you create a new version with the message "change from hi to hello there":

git commit -m "change from hi to hello there"

To summary, there are 2 steps in order to create a new version of project:

git add
git commit -m

Why do we need to do the git add? Can't Git automatically figure what files has changed to create new version with those files for us? Imagine this situation.

Let's say you have 2 files index.js and main.js. But you don't want to create a new version that include main.js just yet. In that case you'd tell Git to just commit index.js but ignore main.js.

git add index.js

then

git commit -m "change to hello there"

The 2 steps git add and then git commit -m is for that flexibility.

This happens a lot in the "real world": you often have to change some config files in order to run the project on your local machine. You'd tell Git to only cares about the file that you actually coding on and ignore those config files.

Let's explains a little more about all the cool terminology people are saying: "staging" and "untracked files".

There are 3 kinds of files:

The files you changed but not tell Git
The files you changed and tell Git
The files you already commit

When people talking about:

Staging area: imagine that is "Files that Git knows is changed"
Staging that file: git add that file
Untracked files: imagine that is "Files you don't tell Git that changed"

To show the all files are in the staging area and all untracked files, you can use git status:

git status

Here's an example of mine:

On branch master
Your branch is up to date with 'origin/master'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   packages/solid-project/src/App.tsx

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)   
        modified:   packages/solid-project/src/hooks/createWindowHeight.ts

This means that I have a createWindowHeight.ts file that I've not yet tell Git about and an App.tsx file that I already tell Git (git add) but not commit yet.

From now, instead of saying "tell Git about what files has changed", I'll say "staging that file". What I said about git add equals to "tell Git about what files has changed" is vastly simplify and definitely not technically correct. git add is more like "I want you, Git, to care about the changes of this file". I told you that above because I think for "beginner", "imagine" it's equal is good enough. Now equip with basic idea and terminology you can read the Pro Git book at https://git-scm.com/book/en/v2 to really understand how Git works.

View all your project's versions

After understanding how to create a new version, next, let's talk about how to view all versions of your project. To see all versions your project has, use the command:

git log

Here's an example of my project:

commit 3f345bfcbbcbaf56f2b7a90a72fb6558a255d3df (HEAD -> master)
Author: Your Name <you@example.com>
Date:   Thu Jan 30 00:53:33 2025

    add examples

commit 67851c04de24214b25099cd5e3a128c06bd4551a
Author: Your Name <you@example.com>
Date:   Mon Dec 9 13:44:31 2024

    initial commit

Here's a diagram to explain it:

My project currently has 2 versions:

Version 67851c04de24214b25099cd5e3a128c06bd4551a
Version 3f345bfcbbcbaf56f2b7a90a72fb6558a255d3df

Currently I'm at the latest version 67851c04de24214b25099cd5e3a128c06bd4551a. That's what the HEAD means.

In previous diagrams, for the sake of easy-to-understand, I tell you "version 1", "version 2", "version 3", but Git uses unique string to label each version. Instead of saying "version 1", Git says "version 67851c04de24214b25099cd5e3a128c06bd4551a".

In fact, the string Git use to label each version is so unique that you can just take 5 - 10 characters of it for Git to know which version. For example, "version 67851c", "version 3f345bfc",...

From now I'll call those unique string "version hash".

Practice a little bit

Let's practice a little bit before going to the next section. We'll use the result of this section for the next section. If you don't want to type anything yet, it's fine. I'll draw a bunch of diagrams so that you can still understand this section without having to type anything.

First, let's create a new directory. I'll call mine simple-git-tutorial.

Next, open a terminal in that directory and type:

git init

This command is to tell Git to start versioning all files inside this directory.

A little bit of extra information: when you git init in a directory, git will create a folder named ".git" inside it to store all information needed to manage that directory.

Here's an example of mine:

If you're not seeing it on Windows, you might need to go to View and then turn on Hidden items to see it!

Next, let's add a file called index.js with the following content:

console.log("hi there");

Now, let's create a new version of this project:

git add index.js

then:

git commit -m "add hi there"

To view all versions, type:

git log

Here's an example of mine:

commit e1c439a92efef55036a54250a8fa58d8db2e7981
Author: Your Name <you@example.com>
Date:   Thu Jan 30 13:28:32 2025

    add hi there

Let's practice again by changing the console.log in index.js file from "hi there" to "hello there":

console.log("hello there")

Now, let's create a new version of this project:

git add index.js

then:

git commit -m "change to hello there"

To view all versions, type:

git log

Here's an example of mine:

commit 56908bb558478bc61d7319b870beb459d9853ae1
Author: Your Name <you@example.com>
Date:   Thu Jan 30 13:29:56 2025

    change to hello there

commit e1c439a92efef55036a54250a8fa58d8db2e7981
Author: Your Name <you@example.com>
Date:   Thu Jan 30 13:28:32 2025

    add hi there

Here's a diagram showing what versions we have in our small project:

See a previous version

Now we can create a new version and view all version, let's talk about how we can see a previous version like in Google Docs.

In order to switch to any version, use git checkout and then the version hash.

For example, if I want to see the version e1c439a92efef55036a54250a8fa58d8db2e7981, I'd use:

git checkout e1c439a92efef55036a54250a8fa58d8db2e7981

Since Git only need 5 - 10 characters of the version hash to recognize, I could have just use this:

git checkout e1c439a

If you open index.js, you'll see the content change from:

console.log("hello there")

back into:

console.log("hi there")

That's great, if I want to return to the latest version, I can just plug in the latest version's hash with git checkout like so:

git checkout 56908bb5

"But wait!", you said horrifyingly. In order to find the latest version hash, I have to use git log. But my git log does not print out the latest version anymore:

commit e1c439a92efef55036a54250a8fa58d8db2e7981 (HEAD -> master)
Author: Your Name <you@example.com>
Date:   Thu Jan 30 13:28:32 2025

    add hi there

Don't worry, just use git log --all. Here's an example of mine:

commit 56908bb558478bc61d7319b870beb459d9853ae1 (master)
Author: Your Name <you@example.com>
Date:   Thu Jan 30 13:29:56 2025

    change to hello there

commit e1c439a92efef55036a54250a8fa58d8db2e7981 (HEAD)
Author: Your Name <you@example.com>
Date:   Thu Jan 30 13:28:32 2025

    add hi there

Tip: if git log not showing all the results you needed, try to add --all!

Now you can find the latest commit and switch back to latest version:

git checkout 56908bb5

Next, let's talk about a concept called "detached HEAD".

When you're using git checkout to change to a version, the HEAD is point to that version. This is called "detached HEAD". You can imagine it's like the Git let us "preview" what the project looks like in that version.

Generally, you don't want to have a "detached HEAD" unless you really understand what you're doing. For now, to escape the "detached HEAD" mode, use:

git checkout master

master here is the current branch we're in. I'll explain more in part 2 when we learn about branch.

Rollback to a previous version

If you want to rollback to a specific version, you can use git reset --hard and then the version hash like so:

git reset --hard e1c439a9

But be really careful because this command will also delete all versions after that! git log --all won't bring the newer versions back!

In fact, you should use git switch -c and then the new branch name like so:

git switch -c new-branch-name

but again I'll explain in part 2 when we learn about branch.

.gitignore file

Next, let's talk about the famous git file: .gitignore.

Have you ever seen this file?

What is the .gitignore file and what does it do?

There are files and folders that you never want to include in any version of your project.

For example think about the node_modules folder. As long as you have the package.json and package-lock.json file you can recreate the node_modules folder exactly as needed anytime you want. Furthermore, let's imagine you use a Window machine and share your project with another guy using a Mac. Because he has a different OS, to run the project he'd have to delete the node_modules and reinstall it again. But now if he git status he'll see a bunch of changes in the node_modules folder despite the fact that in reality he don't change a thing.

You'd only want to include things that absolutely necessary in your version.

To avoid accidentally git add and git commit -m that node_modules folder, you can create a .gitignore file with the following content to ignore the node_modules folder:

/node_modules

Here are some of the usual .gitignore stuffs in the wild:

.DS_Store
*.local
*.log*

node_modules
dist/

.vscode/*
!.vscode/extensions.json
.idea

Conclusion

Let's recap what we've learned so far:

git init: tell git to versioning a folder
git add: stage file
git commit -m: create new version
git status: show all staged files and untracked files
git log, git log --all: show all versions
git checkout [version hash]: see a previous version
git reset --hard [version hash]: roll back to previous version (careful when use this!)

That's the list of basic Git versioning commands that I use everyday.

In part 2 I'll talk about the next revolutionary feature of Git: branch, and in part 3 I'll talk about the full workflow.

Credits

If you like the cute fish that I'm using, check out: https://thenounproject.com/browse/collection-icon/stripe-emotions-106667/.

Integrate React component into Solid JS (with Typescript) (part 3)

TuanNQ — Wed, 09 Jul 2025 13:22:36 +0000

In part 1 and part 2 we built a minimal application to explain how to render a React component inside Solid JS and how to communicate with each other. In this article we'll learn about configuration and create our own library through a "more real-world application".

You can view it here and check the source code here on Github.

It's an application that render a 3D shirt with a configurations below to control lighting and camera,... You can also change the color of the shirt and upload logo. It's like the project from this video by Javascript Mastery but adding the configuration panel below the shirt.

Compare to previous simple application, this application is wayyy too big for me to walk line by line of code. Instead, I'll just focus on important part like configuration, mount function,... If you want to know more about React Three Fiber, you can check out this video on YouTube by JavaScript Master and this course by Anderson Mancini. To learn more about how to create beautiful settings in type of a graph that I did, check out https://reactflow.dev/.

Through this application, I'll explain some basic considerations and configurations you probably encounter when you create your own package in a monorepo project like:

entry file and bundling
.d.ts file
mount function improvements
...and more

Why not use the tsc way?

You might think the tsc way I show you in part 1 is kind of... hacky. It's way too simple! There should be some standard or popular tool or workflow out there to help create a library.

Personally I think the tsc way it's fine. It really depends on the project. The simpler and few tools you use, the easier to understand and maintain. The more complex tools and workflows you use, the harder and more frustrated to config, understand and maintain.

But with that said, the simple tsc way has a few limitations:

What about CSS, Module CSS, TailwindCSS?
tsc only the know the React way of compiling JSX, so what if my library use Vue or Solid or Preact?
...and more

To solve those limitations, there is a popular tool called tsup that specifically designed for building a library with a wide range articles and tutorials cover on how to use it.

But in this article I'll focus on how to do that using another powerful tool yet much less popular called Rslib.

Why Rslib?

First, because it's quite good! It's fast, relatively easy to config, and supports quite a lot of things out of the box. For example, since Rslib uses LightningCSS behind the scene, it has support for CSS, CSS Module and PostCSS without any further configuration. This means that to use TailwindCSS all you need to do is to install some Tailwind dependencies and create postcss.config.ts file with:

export default { plugins: { "@tailwindcss/postcss": {} } };

Plus Rslib is really fast and scalable for large project since it uses Rspack under the hood.

The second reason I choose to write about Rslib is that it was released recently (about August 2024 or so), so currently there are not a lot of tutorials out there about it yet.

Setup our application

Our application consists of 3 small applications:

react-shirt: render the 3D shirt
react-flow: render the camera, lighting,... configuration below the shirt
solid-project: main application, render the sidebar, react-shirt and react-flow

User can change the intensity of ambient and randomize light, frames of accumulate shadow, and the Z axis of camera in the settings in react-flow subproject. When the settings is changed, the configuration data will flow from react-flow to solid-project to react-shirt.

The main app solid-project will hold any state that necessary for the whole application.

Here's the basic file structure of the project:

Let's talk a little more about how I did the setup part.

First, I created a new folder called threejs-shirt-solid-in-react.

Next, to create package.json file at the root project, I ran:

pnpm init

Next I created pnpm-workspace.yaml file with the following content:

packages:
  - "packages/solid-project"
  - "packages/react-shirt"
  - "packages/react-flow"

Next, I created a new folder called packages to hold 3 applications: solid-project, react-shirt, and react-flow.

Now let's talk little more about react-flow.

It receives initial data configuration like ambientLightIntensity, randomizeLightIntensity,... from solid-project and communicate changes back to solid-project through callbacks like onAmbientLightingIntensityChange, onRandomizeLightIntensityChange,...

Let's create this library react-flow using Rslib. In the packages folder, run:

pnpm create rslib@latest

◆  Create Rslib Project
│
◇  Project name or path
│  react-flow
│
◇  Select template
│  React
│
◇  Select language
│  TypeScript
│
◇  Select development tools (Use <space> to select, <enter> to continue)
│  none
│
◇  Select additional tools (Use <space> to select, <enter> to continue)
│  none

The configuration above will generate a src folder with index.tsx, Button.tsx and button.css as an example, a .gitignore file for git, a package.json file, a README.md file, a tsconfig.json for Typescript configuration, and a rslib.config.ts as a configuration on how to build a library.

Understand Rslib configuration

The default rslib.config.ts for creating a React component library look like this:

import { pluginReact } from '@rsbuild/plugin-react';
import { defineConfig } from '@rslib/core';

export default defineConfig({
  source: {
    entry: {
      index: ['./src/**'],
    },
  },
  lib: [
    {
      bundle: false,
      dts: true,
      format: 'esm',
    },
  ],
  output: {
    target: 'web',
  },
  plugins: [pluginReact()],
});

Let's break down what this config file do for us.

Bundle and entry settings

First let's talk about what source.entry.index = ['./src/**'] means.

source: {
  entry: {
    index: ['./src/**'],
  },
},

source.entry.index = ['./src/**'] means that Rslib treat every files in the /src folder as an entry file to compile. If you config like this:

source: {
  entry: {
    index: ['./src/index.tsx'],
  },
},

...Rslib will only treat index.tsx as an entry file and ignore everything else.

Next is the lib.bundle part:

lib: [
    {
      bundle: false,
      ...
    },
  ],

This piece of configuration means Rslib won't bundle entry file and all of its dependencies into one file for us.

For example, let's say you have an index.tsx file that import Label.tsx and Button.tsx file. If you set bundle: false, the output (what you see in the dist folder) will be 3 files: index.js, label.js and button.js. If you set bundle: true, everything will be bundle up into one file index.js.

Now let's combine these 2 settings together:

source: {
  entry: {
      index: ['./src/**'],
    },
},
lib: [
  {
    bundle: false,
    ...
  },
]

This means that Rslib will treat every files in the src folder as an entry file, compile all of it, and not bundle all of them together. Now if you change the source.entry.index = ['./src/index.tsx'] but keep the lib.bundle = false like this:

source: {
  entry: {
      index: ['./src/index.tsx'],
    },
},
lib: [
  {
    bundle: false,
    ...
  },
]

...the result would be fatal. This setting means that Rslib will only compile index.tsx but none of the files that its import.

So when do we want to bundle everything into one file and when do we want the bundle-less option?

For example let's say you build a React library component. You have all kinds of components Button, Label, Input, Card,... but the user only use the Button component. If you bundle everything together the user will have not choice but to include everything despite he only use the Button component. If you use the bundle-less option the user might be able to just include the Button.tsx file with all its dependency instead of having to import everything. This is called "tree-shaking".

dts settings

Next is the lib.dts = true settings. One project knows which type of another project's components, which props does it takes, which output does it returns through the .d.ts file.

For example, if I have a Card component like this:

interface Props {
  header?: React.ReactNode;
  body?: React.ReactNode;
}

export const Card: React.FC<Props> = (props) => {
    ...
};

Here's the corresponding .d.ts file:

interface Props {
    header?: React.ReactNode;
    body?: React.ReactNode;
}

export declare const Card: React.FC<Props>;

Now if another project use my Card component, it'll know my Card take 2 optional props header and body that is a ReactNode.

So the setting lib.dts = true:

  lib: [
    {
      ...
      dts: true,
    },
  ],

...means that Rslib will generate corresponding .d.ts files for each of the .tsx, .ts files for us.

Format esm setting

Do you remember there's 2 ways to import another Javascript file? One is require and the other is import.

require is the old CommonJS way that NodeJS uses. import is the newer ESM way that modern browsers use. ESM provide numerous benefit, one of them is to allow tree shaking I talk about earlier. Because of that, we'll use the ESM way:

lib: [
  {
    ...
    format: 'esm',
  },
],

Output target web setting

Next is the output.target = web setting.

output: {
  target: 'web',
}

To build an application for the browser to use, we need to solve a lot of problems. One example is the CSS problem. A library built for NodeJS does not need to deal with CSS, SCSS, CSS Module, PostCSS, minimize and transform CSS,... but a library built for web does.

output.target = web means that Rslib will solve many problems related to build for web for us.

Plugin React setting

Finally is the plugin setting:

{
  ...
  plugins: [pluginReact()],
}

One of the primary job of a library builder tool like Rslib is to compile framework-specific language (like JSX) into the good old Vanilla Javascript. The pluginReact() plugin will help Rslib to do that.

For example if you use another framework like SolidJS, here's the configuration:

plugins: [
  pluginBabel({
    include: /\.(?:jsx|tsx)$/,
  }),
  pluginSolid(),
],

Optional reading here: why the Solid configuration need the pluginBabel?

Babel and SWC essentially do the same job: compile ts, tsx, jsx,... and many framework specific things into Vanilla Javascript. Say if you want to create your own language or framework and then compile to Vanilla Javascript, you can teach Babel and SWC to do so by writing your own plugin.

Behind the scene Rslib use SWC by default since it's the fastest. But currently since the Solid framework author only create plugin for Babel but not for SWC, we need to tell Rslib explicitly to install and use Babel and then use the Solid plugin for Babel to compile.

Use Tailwind CSS with Rslib

Tailwind CSS uses PostCSS to look at what classes do you use and add those classes into css file. Since behind the scene Rslib uses LightningCSS which supports PostCSS by default (like Vite also supports PostCSS by default), we only need to install a few TailwindCSS dependencies and add necessary postcss configuration to use it.

First, let's install necessary TailwindCSS dependencies:

pnpm install @tailwindcss/postcss tailwindcss

Next, create postcss.config.ts file with the following content:

export default { plugins: { "@tailwindcss/postcss": {} } };

In the main css file add the following according to the Tailwind documentation:

@import "tailwindcss";

That's it! Now we're ready to use Tailwind in our project.

Optional: dts settings abort on error

The default setting lib.dts = true means that Rslib will generate .d.ts files for us. But it also means that if any type error happens, Rslib will also stop compiling.

For example if I tell Rslib to compile the following code:

interface Options {
    fullscreen?: boolean;
}

const options: Options = {
    fullScreen: true,
    hiThere: false // <-- type error here: 'hithere' does not exist in type 'Options'
}

Despite the this code can be compiled to Javascript and can be execute without any error, the type error will stop Rslib from compiling.

I think this behavior is quite annoying when coding. When I'm coding, I want to experiment with things and see changes fast instead of doing everything right on the start.

So I change the dts config from lib.dts = true to:

  lib: [
    {
      ...
      dts: {
        abortOnError: false,
      },
    },
  ],

This means that if type errors occur, Rslib will still compile everything for us.

Serves both as a library and running independently

In part 1 we use tsc to compile our library into Vanilla Javascript and Vite to run the React component independently. We create 2 entry files index.tsx for tsc and main.tsx for Vite.

In this part we'll use Rslib to compile and its cousin Rsbuild to run it independently. (Rslib and Rsbuild come from the same author, Rslib actually uses Rsbuild and both of them are extremely fast for large project!)

Add Rsbuild

First, let's install Rsbuild. In the react-flow folder, run:

pnpm install @rsbuild/core

Next, let's tell Rsbuild to use main.tsx as an entry file by create rsbuild.config.ts with the following content:

import { defineConfig } from "@rsbuild/core";
import { pluginReact } from "@rsbuild/plugin-react";

export default defineConfig({
  plugins: [pluginReact()],
  source: {
    entry: {
      index: "./src/main.tsx",
    },
  }
});

Optional, let's tell Rsbuild to use dist-dev as a folder to output the build result to instead of the default dist:

import { defineConfig } from "@rsbuild/core";
import { pluginReact } from "@rsbuild/plugin-react";

export default defineConfig({
  plugins: [pluginReact()],
  source: {
    entry: {
      index: "./src/main.tsx",
    },
  },
  output: {
    distPath: {
      root: "dist-dev",
    },
  },
});

I like to add this configuration because each time Rsbuild run, it'll clear all the dist folder by default. In our situation, since both Rslib and Rsbuild use the same dist folder, it's quite annoying: if you run Rslib and Rsbuild at the same time, Rsbuild will clear all the output of Rslib.

Config Rslib to ignore the main.tsx file

Next, let's tell Rslib to ignore the main.tsx file:

import { pluginReact } from "@rsbuild/plugin-react";
import { defineConfig } from "@rslib/core";

export default defineConfig({
    source: {
        entry: {
            index: ["./src/**"],
        },
        exclude: ["./src/main.tsx"],
    },
    ...
})

The main.tsx file is only needed for Rsbuild to render independently. We don't want to include it to the compiled result.

Mount function improvements

Render many times

The mount function can be called many times due to the main application re-rendering. So let's unmount all the previous root and re-mount to the newly provided root div:

let root: ReactDOM.Root | undefined = undefined;

export const mount = (rootEl?: Element) => {
    // If not provided with a component to render, return
    if (!rootEl) {
        return;
    }

    // If already render before, unmount it
    if (root) {
        root.unmount();
    }

    // Render on root element
    root = ReactDOM.createRoot(rootEl);
    root.render(
        <React.StrictMode>
            <App />
        </React.StrictMode>,
    );
};

Render on full screen option

In the mount function of react-flow component, we use react-flow to render on the provided div. It is up to main Solid application to specify the width and height of that div. But when we render it independently, the outer div is the #root div with no width and height.

If you try to run it independently, you'll see a blank screen with the following error in the console: [React Flow]: The React Flow parent container needs a width and a height to render the graph. like this.

So let's add an option to the mount function to render on full screen if needed. In the index.tsx change to the following:

// Options (fullscreen: for running this app independently)
interface Options {
  fullscreen?: boolean;
}

// Mount
let root: ReactDOM.Root | undefined = undefined;

export const mount = (
  rootEl: Element | null | undefined,
  props?: Callbacks & InitialValue,
  options?: Options,
) => {
  // If not provided with a component to render, return
  if (!rootEl) {
    return;
  }

  // If already render before, unmount it
  if (root) {
    root.unmount();
  }

  // Options
  let AppWrapper: React.FC = App;

  if (options?.fullscreen) {
    AppWrapper = () => (
      <div className="w-screen h-screen">
        <App />
      </div>
    );
  }

  // Render on root element
  root = ReactDOM.createRoot(rootEl);

  root.render(
    <React.StrictMode>
      <AppWrapper />
    </React.StrictMode>,
  );
};

Then, in the main.tsx we can add the full screen option:

import { mount } from ".";

mount(document.querySelector("#root"), undefined, {
    fullscreen: true,
});

Conclusion

So that's all important details and configurations I think it'll be helpful to you when building your own library.

I hope with this 3 parts tutorial and my sample project in Github, you can leverage the blazingly fast and ease-of-use of Solid with the of wide ecosystem of React in your project.

I hope this article is helpful to you. If you have any improvements or other approaches to the integrate React into Solid problem, please let me know below.

Integrate React component into Solid JS (with Typescript) (part 2)

TuanNQ — Sat, 14 Jun 2025 08:23:56 +0000

In part 1, we can now render React component inside a Solid application. In part 2 we'll tackle the communication problem: how to pass data between 2 applications.

The communication problem consists of 2 smaller problems:

Communicate from React component to the main Solid application
Communicate from the Solid main application to React component

In a normal "pure" React or Solid application, we use props to pass data between components. But we can't use that normal way to communicate between 2 applications. Instead, we use the good old callback.

You can check the source code here on Github for this article.

Let's tackle the first problem: communicate from the React component up to the main Solid application.

Communicate from React component to the main Solid application

First, let's build the classic counter application: the React component will render a button that each time it get clicked the counter in the Solid main application will increment by 1.

In order to do that, the React component need to tell the Solid main application each time the button get clicked. The Solid main application will hand the React component a function onIncrement. Each time the React component want to increment, it'll call that function.

Here's the detail implementation:

The mount now accepts a new argument: a function called onIncrement
The main Solid app pass a function onIncrement to the mount function
The mount receive that function add pass it to the App component
Each time the App component need to increment, it'll call that function

Let's dive into the coding part! In the App.tsx of the React component add the following:

// App.tsx (React app)
interface Props {
  onIncrement: (amount: number) => any;
}

export const App: React.FC<Props> = ({ onIncrement }) => {
  return <button onClick={() => onIncrement(1)}>Increment from React</button>;
};

The App component receive the onIncrement function. Each the the button get click it'll call the onIncrement with the value 1.

In the index.tsx file (of the React component) change to the following:

// index.tsx (React app)
import { StrictMode } from "react";
import { createRoot } from "react-dom/client";
import { App } from "./App";

interface Callbacks {
  onIncrement: (amount: number) => any;
}

export const mount = (root: HTMLElement, { onIncrement }: Callbacks) => {
  createRoot(root).render(
    <StrictMode>
      <App onIncrement={onIncrement} />
    </StrictMode>
  );
};

The mount function receive the onIncrement function and pass it to the App component.

Now, let's run the build script again in the react-component folder:

pnpm run build

Next, in the App.tsx in the Solid application add the following:

// App.tsx (Solid app)
import { mount } from "react-component";
import { createSignal, onMount } from "solid-js";

export const App = () => {
  let container!: HTMLDivElement;

  const [value, setValue] = createSignal<number>(0);

  onMount(() => {
    mount(container, {
      onIncrement: (amount) => {
        setValue((value) => value + amount);
      },
    });
  });

  return (
    <>
      <div ref={container} />
      <div>
        <div>Count from Solid: {value()}</div>
      </div>
    </>
  );
};

The main Solid application create a function called onIncrement with the amount parameter. Each time it get called Solid will increment the value in the state with that amount.

Now, if you click the "Increment from React" button, the counter in the Solid application will increment by 1!

Communicate from the main Solid application to the React component

Next, let's extends the application to have an input in the Solid application which tell the React component the amount it should increment.

Similar to the way React component communicate with the Solid application above, the React component will hand the main Solid application a function setAmount. Each time the value in the input change the main Solid application will call that function.

Here's the detail implementation:

The mount function returns a setAmount function
The Solid main application receive that setAmount function
Each time the input change, Solid main application will call that setAmount function

In the App.tsx in the Solid main application, change to the following:

// App.tsx (Solid app)
import { mount, type ReturnedCallbacks } from "react-component";
import { createSignal, onMount } from "solid-js";

export const App = () => {
  let container!: HTMLDivElement;

  let setAmount: ReturnedCallbacks["setAmount"] | undefined;

  const [value, setValue] = createSignal<number>(0);

  onMount(() => {
    const callbacks = mount(container, {
      onIncrement: (amount) => {
        setValue((value) => value + amount);
      },
    });

    setAmount = callbacks.setAmount;
  });

  return (
    <>
      <div ref={container} />
      
      <div>
        <input onInput={(e) => {
            const value = parseFloat(e.currentTarget.value);

            if (!isNaN(value)) {
              setAmount && setAmount(value);
            }
          }}
        />

        <div>Count from Solid: {value()}</div>
      </div>
    </>
  );

};

First, we get a new function called setAmount from the mount function. Then we set it to the setAmount function defined at the top of the component. Now we can call setAmount anywhere in our component.

Above the counter from solid div, we add an input that each time user change, it'll get the value from the input and call setAmount function.

*Note: on Solid JS, we don't use the onChange event listener but instead use onInput

In the index.tsx of the React component, change to the following:

// src/index.tsx (React component)
import { StrictMode } from "react";
import { createRoot } from "react-dom/client";
import { App } from "./App";

export interface Callbacks {
  onIncrement: (amount: number) => any;
}

export interface ReturnedCallbacks {
  setAmount: (amount: number) => any;
}

export const mount = (
  root: HTMLElement,
  { onIncrement }: Callbacks
): ReturnedCallbacks => {
  createRoot(root).render(
    <StrictMode>
        <App onIncrement={onIncrement} />
    </StrictMode>
  );

  return {
    setAmount: (amount: number) => {
      // TODO: pass the amount to the App component
    },
  };
};

The mount function now return a setAmount function for the main Solid application to call when needed.

But how can we pass the amount into the App component? In order to do that, we'll need to use a store management solution (like Redux). Because in essence, we need to pass a value into the whole React application.

There are many store management solution out there like Redux, MobX, Nano Stores, Valtio,... If you want a minimal solution, you might want to choose a simple solution like Nano Stores,.. but in this article, for the sake of familiarity, I'll use Redux.

Here's a full diagram with Redux:

First, let's install Redux. Remember to run this command in the React component project.

pnpm install @reduxjs/toolkit react-redux

In the src folder of the React component, create amount-slice.ts with the following content:

// src/amount-slice.ts (React component)
import { createSlice } from "@reduxjs/toolkit";
import type { PayloadAction } from "@reduxjs/toolkit";
import { RootState } from "./store";

// Define a type for the slice state
export interface AmountState {
  value: number;
}

// Define the initial state using that type
const initialState: AmountState = {
  value: 0,
};

const amountSlice = createSlice({
  name: "amount",
  // `createSlice` will infer the state type from the `initialState` argument
  initialState,
  reducers: {
    setAmount: (state, action: PayloadAction<number>) => {
      state.value = action.payload;
    },
  },
});

export const { setAmount } = amountSlice.actions;

// Other code such as selectors can use the imported `RootState` type
export const selectAmount = (state: RootState) => state.amount.value;

export default amountSlice.reducer;

Next, in the src folder of the React component, create store.ts file with the following content:

// src/store.ts (React component)
import {
  configureStore,
  EnhancedStore,
  StoreEnhancer,
  ThunkDispatch,
  Tuple,
  UnknownAction,
} from "@reduxjs/toolkit";
import amountSlice, { AmountState } from "./amount-slice";

export const store: Store = configureStore({
  reducer: {
    amount: amountSlice,
  },
});

// Infer the `RootState` and `AppDispatch` types from the store itself
export type RootState = ReturnType<typeof store.getState>;

export type Store = EnhancedStore<
  {
    amount: AmountState;
  },
  UnknownAction,
  Tuple<
    [
      StoreEnhancer<{
        dispatch: ThunkDispatch<
          {
            amount: AmountState;
          },
          undefined,
          UnknownAction
        >;
      }>,
      StoreEnhancer
    ]
  >
>;

Now, we can wire it together in the index.tsx:

// src/index.tsx (React component)
import { StrictMode } from "react";
import { createRoot } from "react-dom/client";
import { App } from "./App";
import { Provider } from "react-redux";
import { store } from "./store";
import { setAmount } from "./amount-slice";

export interface Callbacks {
  onIncrement: (amount: number) => any;
}

export interface ReturnedCallbacks {
  setAmount: (amount: number) => any;
}

export const mount = (
  root: HTMLElement,
  { onIncrement }: Callbacks
): ReturnedCallbacks => {
  createRoot(root).render(
    <StrictMode>
      <Provider store={store}>
        <App onIncrement={onIncrement} />
      </Provider>
    </StrictMode>
  );

  return {
    setAmount: (amount: number) => {
      store.dispatch(setAmount(amount));
    },
  };
};

In order to make changes to the store outside of a React component, you can use store.dispatch().

Next, in the App.tsx file of the React component we will get the amount that stored in Redux:

// src/App.tsx (React component)
import { useSelector } from "react-redux";
import { RootState } from "./store";

interface Props {
  onIncrement: (amount: number) => any;
}

export const App: React.FC<Props> = ({ onIncrement }) => {
  const amount = useSelector((state: RootState) => state.amount.value);

  return (
    <button onClick={() => onIncrement(amount)}>
      Increment {amount} from React
    </button>
  );
};

Let's build the React component library:

pnpm run build

Now, if you run the server, you'll see the following in the screen:

The application is complete!

Conclusion

Now you know about all the nitty gritty technical details how to integrate a React component into a Solid JS application.

But I think there's still a lot of work ahead to actually create your own custom solution for your application. So in the next part I'll talk more about the building the React component part: explaining basic settings and configurations you might want to know.

Integrate React component into Solid JS (with Typescript) (part 1)

TuanNQ — Sat, 07 Jun 2025 06:56:30 +0000

I really like Solid JS, but...

...I can't live without libraries like react-three-fiber and react-flow. There are currently no alternative to those library in the Vanilla Javascript world. Solid is amazing: having both velocity (easy to code) and performance seems like a dream come true, but I can't leave React ecosystem (one of the largest ecosystem) behind. Writing all of the diffuse light and blur shadow in react-three-fiber, or recreate react-flow is insane. I'm not going to do that! I don't want to write 100.000 lines in Solid JS just to finally have to convert to React again!

That's why I write this article: how to integrate React component into Solid JS.

In part 1, we'll learn how to render a React component in Solid JS through simple minimal example like this:

You can check the source code here on Github.

In part 2, we'll learn how passing data between React component and Solid JS through this counter application:

You can check the source code here on Github.

In part 3 we'll learn how to build and config a more (somewhat) "real-world" application:

You can view this application here and check the source code here on Github.

There are many ways to integrate React component into Solid JS, here I'll introduce the 'monorepo' way of doing it.

Why it seems like an easy-to-solve problem but actually not

At first, integrate React into Solid JS seems like it's not going to be a problem at all. React and Solid is so similar. Can't we just install both React and Solid JS into one project, and then write parent component in Solid JS, the child component in React, and that's it?

Naive React component in Solid component implementation

It's not that simple.

Turns out the Vanilla JS that React code and Solid code are compiled down to are completely different (even the compiled JSX part is different!). The compiled React code is not "compatible" with the compiled Solid code. And we also have to tell Vite to compile React and Solid files differently.

Basically we have 2 big problems:

How do we even tell Vite / CRA to compile React and Solid differently?
How do React code and Solid code communicate with each other?

My approach to the compile problem is to create 2 different project, one for the React component and one for the Solid main app.

Solution to the compile problem: separate React and Solid project

For the communication problem my solution is to compile the React component into Vanilla JS and then install it into the main Solid app.

React and Solid can't understand each other but they both understand a common language: Vanilla JS. By compile the React component into Vanilla JS, Solid will be able to understand it.

Solution to the communication problem: compile React into Vanilla JS

Now that they understand each other, the Solid main application will give the React component a div to render on.

Here's a more technical diagram:

The React component library expose a mount function: give it a div, the mount function will render on that div
Compile it into Vanilla JS
Import it into the Solid application
Since we compile the React code into Vanilla JS, the Solid application will understand
Supply a div to the mount function and tell it to render

So let's get into how to make the React component into a separate library with the help of PNPM Workspace.

Solving the compile problem (with PNPM workspace)

We'll create 2 separate applications: React application and Solid application. Imagine the Solid application is the "main" application while the React application is a "library" that you npm install into the Solid "main" application.

Here's the traditional workflow:

Develop and build the React app
Publish to NPM Registry
Install it from NPM Registry to the Solid app

Looking at this workflow you might think, what's the point of making and publishing a library that only I use? I wish I don't have to publish to NPM Registry. Is there someway to use a package locally in my computer?

This is when PNPM workspace come to the rescue.

PNPM workspace

PNPM workspace helps one project use another project as a library without having to publish to NPM Registry.

Let's take an example: project #1 uses project #2 and project #3 as dependencies:

In our example, here's what PNPM Workspace would do:

Project #1 asks PNPM Workspace for Project #2 and Project #3 as dependencies
PNPM Workspace finds the location of Project #2 and Project #3 (through pnpm-workspace.yaml)
PNPM Workspace then asks for the build files of Project #2 and Project #3 (through package.json of each project)
PNPM Workspace deliver those files to Project #1

Here's a more... technical diagram explains the basic file structure of our example PNPM Workspace:

pnpm-workspace.yaml at the root of project: tells pnpm workspace the location of all projects
packages is the folder houses all projects: if you rename this folder you have to change in the pnpm-workspace.yaml accordingly
package.json in the "library" (in our example, project #2 and #3): show the entry to that library
package.json in "parent" project: the "workspace:*" part tells pnpm workspace that it wants to use project #2 and project #3 locally

Yarn workspace and NPM workspace also offer the same functionality but in this article I'll use PNPM workspace. They're all really similar to each other.

So let's use PNPM workspace to build a Solid project that uses a React component.

Let's create a PNPM Workspace and add our Solid project to it

First, let's create a new folder for our new project. I'll name it react-in-solid.

Next, create the pnpm-workspace.yaml file tell PNPM about our main Solid project called "solid-project":

packages:
  - "packages/solid-project"

Then, create the packages folder that will house both our React and Solid project. In that folder, let's use Vite to create a new Solid project named "solid-project".

cd packages

npx create-vite@latest

√ Project name: ... solid-project
√ Select a framework: » Solid
√ Select a variant: » TypeScript

Here's a diagram explain what we did:

Now let's install dependencies. Remember to run install at the root folder. PNPM needs to know about pnpm-workspace.yaml.

pnpm install

Next, let's run the server by:

pnpm run dev

Remember to run this in the packages/solid-project folder!

Optional: the `--filter` flag

Having to remember to switch folder to run certain command is quite annoying sometimes. So PNPM workspace offers the --filter flag to solve this problem.

You can run the start dev server above command at the root project with the --filter flag like this:

pnpm --filter \"solid-project\" run dev

The --filter flag specify which project that the dev command should run. It's like you run pnpm run dev at the "solid-project" folder.

For our convenience, let's make a package.json file at the root of the project and then add the script dev. First, let's run:

pnpm init

Then, in the package.json file add the "dev" script:

"scripts": {
    "dev": "pnpm --filter \"solid-project\" run dev"
}

Now you can run pnpm run dev in the root folder!

Let's create our React project and add to PNPM workspace

First, add our new project called react-component into pnpm-workspace.yaml to tell pnpm about it:

packages:
  - "packages/solid-project"
  - "packages/react-component"

Then, use Vite to create a new React project in the packages folder.

cd packages

npx create-vite@latest

√ Project name: ... react-component
√ Select a framework: » React
√ Select a variant: » TypeScript + SWC

I use SWC here for speed but you can just choose Typescript and leave out SWC if you like

Next, install dependencies from the root folder:

pnpm install

Here's a diagram explain what we did:

Linking the React and Solid project together

Before continuing how to render a React component in a Solid project, you might want to get a rough idea about what Vite, Solid or React does.

Optional: what does Vite and React (and Solid) do?

In simple term, React (and Solid) allows us to "draw" our interface using Javascript on a div.

You (the developers) write code to teach React (or Solid JS) how to create the interface we want
We then supply an index.html with a root div
React draw on the root div

So with the bird's eye overview of what React does, here's what the setup code in the main.tsx means:

We supply the createRoot function with div with id "root", and then tell React (or Solid) to insert elements on that div based on the JSX code we write.

Since the browser only understand Vanilla JS, Vite then compile and bundle the React source code and our code into Vanilla JS for us, supply the index.html file with the "#root" div, and create the dev-server so that we can run in http://localhost:5173.

Overall architecture

Back to our initial idea of how to render React component in a Solid app:

Combine with the basic understand of what React and Vite do for us behind the scene, here's the complete architecture:

Our own React component library expose a mount function: give it a div, it'll render on that div
Compile our own component library into Vanilla JS
Import it into the Solid application
Supply a div to the mount function and tell it to draw
Vite will do the rest of the compiling, bundling, hot reloading,... for us

Let's apply it to build a Hello World "React in Solid application"!

Compile the React component (or we can call it make it a library!)

First, in the React app, let's delete everything in the ./src directory. Then, create the App.tsx file in that directory with the following content:

// src/App.tsx
export const App = () => {
  return <div>Hi from React</div>;
};

The App component render the div with the text "Hi from React" inside.

Next, create the index.tsx file with the following content:

// src/index.tsx
import { StrictMode } from "react";
import { createRoot } from "react-dom/client";
import { App } from "./App";

// For the main Solid app
export const mount = (root: HTMLElement) => {
  createRoot(root).render(
    <StrictMode>
      <App />
    </StrictMode>
  );
};

The mount function accept a root HTML element and render the React element on it. The index.tsx file serves as an entry point for the Solid app.

Now, let's compile the React code we write above to Vanilla JS for the main Solid app to use.

One of the most simple way to compile React TSX code into Vanilla JS is to use tsc. tsc (installed with Typescript) will compile .ts, .tsx file into Vanilla Javascript. You can use tools from Webpack (which CRA use), ESBuild (which Vite use), Rspack (which Rsbuild use), to tools that built specifically for compiling library like Tsup, Rslib, to very basic simple tool like tsc, swc. In this article for the sake of simplicity I'll use tsc.

Let's create tsconfig.build.json file specifically for tsc to compile our React app. We'll tell tsc to start with an entry file ./src/index.tsx and output the compiled Vanilla JS into the dist folder like so:

{
  "compilerOptions": {
    "target": "ES2016",
    "jsx": "react-jsx",
    "module": "Preserve",
    "declaration": true,
    "inlineSourceMap": true,
    "outDir": "./dist",
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "strict": true,
    "skipLibCheck": true
  },
  "files": ["./src/index.tsx"]
}

Next, we'll tell tsc to use the tsconfig.build.json when compile our React app. In the package.json of the react-component project, change the build command to this:

"scripts": {
    ...
    "build": "tsc -p tsconfig.build.json",
    ...
  },

Now, in the react-component project, let's run build our react component:

pnpm run build

You'll see it generate a new dist folder with all the compiled Vanilla JS file with all the .d.ts type file necessary for it.

The last step we need to do is to set the entry file for our React library. In this case, the entry is the compiled index.tsx file: ./dist/index.js. In the package.json file, add to following:

{
  "name": "react-component",
  "main": "./dist/index.js",
  ...
}

Here's a diagram explain what we've done so far:

Optional: Running the react-component project independently

Out of all what Vite does for us, to make the React component a library we only need the compile phase.

This means that we can uninstall Vite and only keep the part that compile for us (which behind the scene is ESBuild / SWC). Though it's ok to do that, I want to keep Vite around so that we can have both options to run this project independently and serves as a library.

The tricky thing is while the main Solid application only expects the React component to return a mount function but not to run it immediately, Vite expects the React component to run it immediately. You can see that in the default main.tsx given to us will render our app in the #root div immediately:

createRoot(document.getElementById('root')!).render(
  <App/>,
)

To solve this problem, we'll create 2 entry file. The first is index.tsx which export a mount function for the main Solid application to use. The second is main.tsx which actually run the mount function on the #root div.

Here's a more technical diagram:

Let's create the main.tsx file that serves as an entry point for stand-alone development with the following:

// src/main.tsx
import { mount } from ".";

// For stand-alone development
mount(document.getElementById("root")!);

This main.tsx file will immediately call the mount function to render our React component in the #root div.

In index.html file of the React component application, make sure the tag import main.tsx file:

...
  <script type="module" src="/src/main.tsx"></script>
...

The index.html file will import main.tsx file (make sure it's not the index.tsx file) which will run the React application for us.

If you run the server in react-component, you'll this on the screen:

Import into Solid application

First, let's "install" our React application as a dependency. In the package.json of the solid-project, add the following:

"dependencies": {
    ...
    "react-component": "workspace:*"
  },

Here's a diagram explain what we've done so far:

Now let's run pnpm install react component into the Solid main application. Remember to run at the root folder:

pnpm install

Next, in the solid-project app, let's delete everything in the src folder. First, create the App.tsx with the following content:

export const App = () => {
  return <div>Hi from Solid</div>;
};

The App component render a div with text "Hi from Solid".

Next, create the index.tsx with the following content:

import { render } from 'solid-js/web'
import { App } from './App.tsx'

const root = document.getElementById('root')

render(() => <App />, root!)

The index.tsx render our app in the div with id "root".

If you run the server, you'll see the following in the screen:

Next, in App.tsx, let's import the React application into our main Solid application:

import { mount } from "react-component";
import { onMount } from "solid-js";

export const App = () => {
  let container!: HTMLDivElement;

  onMount(() => {
    mount(container);
  });

  return (
    <>
      <div ref={container} />
      <div>Hi from Solid</div>
    </>
  );
};

The App.tsx import mount function from react component, and when the App component mount, give the mount function a div.

Now, if you run the server, you'll see the following in the screen:

It's working! We have a React component rendered inside a Solid application.

That's it for part 1. In part 2 we'll solve to communication problem.

Credits

If you like the cute fish that I'm using, check out: https://thenounproject.com/browse/collection-icon/stripe-emotions-106667/.

Why you will love Solid JS as a React developer

TuanNQ — Mon, 19 May 2025 13:40:39 +0000

Yet another JS framework? Why should I care about that Solid JS thing? Isn't that React is good enough? Here's why you should care about Solid JS from a viewpoint of a React developer.

Have you ever encounter a massive React component that a team spends months to build happened to be awfully laggy? It seems that nobody can figure out it's re-rendering so much and if one figure out, it would be too risky to re-write the logic.

Have you ever integrate a non-React library into React? Somehow your component just freeze because it was re-rendered again and again, and your React state not in sync with that outside library at all?

If I tell you to use another JS framework to solve those problem, you'd tell me, wouldn't I have to throw away all my muscle memory and technical details I know about React to learn another new framework? How can I justify that?

Here Solid come to the rescue! Solid has nearly identical syntax compare to React and really, really fast. You and your team can get productive with Solid in almost no time and you'll never have to worry about performance issues again!

Another amazing thing is that contrary to React, Solid also allow you to integrate with non-React library almost seamlessly.

In short, Solid allows you to have the best from both world: the JSX component way of doing things combine with the power of good old Vanilla JS. Plus, you never have to worry about all the useRef, memo,... things for performance anymore.

In this article we'll learn about how Solid JS can make our lives significantly easier, get familiar with basic Solid JS (which trust me, nearly identical with React, almost no learning curve required!), and how to do the store thing (like Redux) and context in Solid JS.

First, let's delve into the pain points of React that Solid solve.

Pain points of React

Excessive re-rendering problem (eg: resizing, drag'n'drop, very large form...)

Have you ever tried to write a resizable component yourself in React? If I tell you to write a resizable React component that wrap around another expensive React component, what would you do?

Here's how you might approach the problem: change the state, and React will handle the UI change for you. With that in mind, you might write some code like this:

import React, { useState, useRef } from 'react';

export const ResizableComponent: React.FC = () => {
    const [width, setWidth] = useState<number>(100);

    const containerRef = useRef<HTMLDivElement>(null);

    const onDrag = (e: MouseEvent) => {
        const delta =
          e.pageX - containerRef.current!.getBoundingClientRect().right;
                  
        setWidth((prevWidth) => prevWidth + delta);
    };

    return (
        <div ref={containerRef} style={{ width }}>

          <ExpensiveComponent />
          
          {/* Handle */}
          <div
            onMouseDown={() => {
              document.addEventListener("mousemove", onDrag);

              document.addEventListener("mouseup", () => {
                document.removeEventListener("mousemove", onDrag);
              });
            }}
          />
        </div>
      );
    }

But oh boy was it laggy! The reason is that the Expensive Component was re-rendered so many times. To avoid this, you need to store the width in ref to avoid the excessive re-rendering.

Unspoken rule: you should put everything in state, except those that changed 1000 times per second.

The same pain point apply for drag and drop, or re-render the whole gigantic form on every key strokes,... You have to use ref and deal with the integration between state and ref, and its various edge cases and bugs.

Integrate with not-for-React library

Have you ever find some very nice library but it's for Vanilla Javascript instead of for React? (for example: D3, GSAP, VisJS Timeline,...)

If those library don't have a React port, and you're just get started with React, good luck try to integrate those. All those crazy re-rendering and useRef, useEffect, useMemo, useCallback,... none of that works! Somehow my page just lag, my library just got re-render again and again, and my state absolutely not in sync with those outside library.

Integrate some simple outside library sometimes requires quite a bit of knowledge about React!

If you wish those nasty issues are just magically dealt with, and you don't even have to learn yet another crazy JS framework, Solid JS come to the rescue!

Why you should try Solid JS?

Syntax extremely familiar with React

Don't have time to learn a new framework? Have trouble hiring or training people some obscure JS framework?

Don't worry! Just replace useState with createSignal, useEffect with createEffect, and voila!, you're starting to get productive with Solid JS!

export const App = () => {
  const [count, setCount] = createSignal<number>(1);

  return (
    <div>
      <div>{count()}</div>
      <button
        onClick={() => {
          setCount((prevState) => prevState + 1);
        }}
      >
        Increment
      </button>
    </div>
  );
};

And remember don't destructuring props like this:

// NOT OK!
const Component = ({ data, onClick }) => {}

// OK!
const Component = (props) => {
    props.data;
    props.onClick();
}

For a majority of the time, that's enough!

Of course there are some more minor differences, but just consult the documentation, no big deal!

Don't worry about excessive re-rendering

Let's write the resizable component above again but in Solid JS:

import { createSignal, type VoidComponent } from "solid-js";

const App: VoidComponent = () => {
  const [width, setWidth] = createSignal<number>(100);

  let containerRef!: HTMLDivElement;

  const onDrag = (e: MouseEvent) => {
    if (containerRef) {
      const delta = e.pageX - containerRef.getBoundingClientRect().right;
      setWidth((prevWidth) => prevWidth + delta);
    }
  };

  return (
    <div
      ref={containerRef}
      style={{
        width: `${width()}px`,
      }}
    >
      <ExpensiveComponent />

      <div
        onMouseDown={() => {
          document.addEventListener("mousemove", onDrag);
          
          document.addEventListener("mouseup", () => {
            document.removeEventListener("mousemove", onDrag);
          });
        }}
      />
    </div>
  );
};

If you try it, it's super smooth! The main reason is that ExpensiveComponent is not forced to re-render again and again.

Solid JS only update what's needed to be updated, and don't touch anything else. They call it "fine-grained reactivity", I guess.

With Solid JS, you can truly just put everything in state without worrying about performance and all the crazy optimization like ref, useCallback, useMemo ever again!

Integrate nicely with Vanilla Javascript library

Need some nice timeline library (vis-timeline) which currently don't have a React nor Solid port?

Here you go, just make a ref and wrap all the Vanilla Javascript code on onMount (equivalent of useEffect with an empty array dependency):

import { onMount, type VoidComponent } from "solid-js";
import { type DataItem, Timeline } from "vis-timeline";
import "vis-timeline/dist/vis-timeline-graph2d.min.css";

const App: VoidComponent = () => {
  let containerRef!: HTMLDivElement;

  onMount(() => {
    // Items
    const items = [
        { id: 1, content: "item 1", start: "2014-04-20" },
        { id: 2, content: "item 2", start: "2014-04-14" },
        { id: 3, content: "item 3", start: "2014-04-18" },
        { id: 4, content: "item 4", start: "2014-04-16", end: "2014-04-19" },
        { id: 5, content: "item 5", start: "2014-04-25" },
        { id: 6, content: "item 6", start: "2014-04-27", type: "point" },
    ];

    // Create a Timeline
    const timeline = new Timeline(containerRef, items, {});

    // Do whatever you need with timeline here
  });

  return (
    <div
      ref={containerRef}
      style={{
        width: `600px`,
        height: `400px`,
      }}
    />
  );
}

Here's the result:

Need some fancy D3js?

import { onMount, type VoidComponent } from "solid-js";
import * as d3 from "d3";

const D3Demo: VoidComponent = () => {
  let container!: HTMLDivElement;

  onMount(() => {
    // Declare the chart dimensions and margins.
    const width = 640;
    const height = 400;
    const marginTop = 20;
    const marginRight = 20;
    const marginBottom = 30;
    const marginLeft = 40;

    // Declare the x (horizontal position) scale.
    const x = d3
      .scaleUtc()
      .domain([new Date("2023-01-01"), new Date("2024-01-01")])
      .range([marginLeft, width - marginRight]);

    // Declare the y (vertical position) scale.
    const y = d3
      .scaleLinear()
      .domain([0, 100])
      .range([height - marginBottom, marginTop]);

    // Create the SVG container.
    const svg = d3.create("svg").attr("width", width).attr("height", height);

    // Add the x-axis.
    svg
      .append("g")
      .attr("transform", `translate(0,${height - marginBottom})`)
      .call(d3.axisBottom(x));
      
    // Add the y-axis.
    svg
      .append("g")
      .attr("transform", `translate(${marginLeft},0)`)
      .call(d3.axisLeft(y));

    // Append the SVG element.
    container.append(svg.node()!);
  });

  return <div ref={container} />;
};

Here's the result:

All I need to do is to make a container ref, then copy and paste from the documentation to onMount! And it works! They said the reason you can do this because each component only mount once.

Solid JS give you both options to write in a normal Vanilla Javascript way and nicely integrate with the React way. Imagine how cool is that! You have the best from both worlds!

But what about store management and context?

Ok, I was sold on Solid JS, you said, but what about all the store management Redux thing? What's the equivalent of Context and Redux in Solid JS world?

Did I tell you that you can move state outside of component is Solid JS?

const [count, setCount] = createSignal<number>(1);

export const App = () => {
  return (
    <div>
      <div>{count()}</div>
      <button
        onClick={() => {
          setCount((prevState) => prevState + 1);
        }}
      >
        Increment
      </button>
    </div>
  );
};

Let's talk about what this means to the store management problem below.

Context

If you need some state that both component A and component B need to use, just move it outside of A and B:

// State (outside of component A and B)
const [count, setCount] = createSignal<number>(1);

// Component A
export const ComponentA = () => {
  return (
    <div>
      <div>{count()}</div>
      <button
        onClick={() => {
          setCount((prevState) => prevState + 1);
        }}
      >
        Increment
      </button>
    </div>
  );
};

// Component B
export const ComponentB = () => {
  return (
    <div>
      <div>{count()}</div>
      <button
        onClick={() => {
          setCount((prevState) => prevState - 1);
        }}
      >
        Decrement
      </button>
    </div>
  );
};

No need to worry about props drilling, lift up state, performance issues (and the god forbid useImperativeHandle!) anymore.

Redux

In case of Redux, Solid JS offer createStore for more complex data structure.

import { createSignal, For, onMount, type VoidComponent } from "solid-js";
import { createStore, produce } from "solid-js/store";

// Imagine this is a slice
const [todos, setTodos] = createStore<string[]>([]);

// Imagine this is selector
export const selectTodos = () => {
  return todos;
};

// Imagine this is a dispatcher
export const addTodo = (newTodo: string) => {
  setTodos(produce((state) => state.push(newTodo)));
};

// Add todo component
const AddTodo: VoidComponent = () => {
  const [todo, setTodo] = createSignal<string>("");
  
  return (
    <>
      <input
        onInput={(e) => {
          setTodo(e.currentTarget.value);
        }}
      />

      <button
        onClick={() => {
          addTodo(todo());
        }}
      >
        Add todo
      </button>
    </>
  );
};

// List todo component
const TodoList: VoidComponent = () => {
  const todos = selectTodos();

  return <For each={todos}>{(todo) => <div>{todo}</div>}</For>;
};

And that's how you can get the familiar Redux-y way in Solid JS just like you get with React.

But what are the downsides?

Since Solid JS has not yet reach popularity like React, its ecosystem still lack many of the equivalent libraries like react-flow, react-three-fiber, react-input-number (for input validation and masking),...

Solid JS does have Solid Start, which is like NextJS, but obviously is not battle-tested like NextJS yet.

Conclusion

First time trying out Solid JS, I feel like having magic 'It just works TM' experience. Whatever you throwing at Solid, it will always works, and works fast! I can focus on building my application, instead of learning and fighting the framework, and worrying about performance.

With almost no new learning required, ease of coding couple with insane performance, plus easily combine the best from both world (Vanilla JS way and React way of doing things) in one codebase, I feel like Solid JS is the perfect version of React. I think Solid JS has a bright future ahead.

If you have a personal or a small project which need to be fast-moving, performance, and familiar with the React people, definitely trying Solid JS!

Credits

If you like the cute fish that I'm using, check out: https://thenounproject.com/browse/collection-icon/stripe-emotions-106667/.

Forem: TuanNQ

How I optimize my React Flow application

The problem

Memoize the React Flow node component

Yield to the main thread

What about worker thread?

The glorious flashing second

Conclusion

Credits

How I help a huge enterprise React project run dev 5x times faster

The compiling and Create React App bottleneck

Change tsc with swc

Replace CRA (Create React App) with Vite

Replace Vite with Rsbuild

The irony aftermath

Credits

Git for grad students (part 3)

Create a new repository on Github

git remote add origin

git branch -M

git push -u origin

git clone

The full workflow

Optional: the develop branch

Review and merge a Pull Request (or Merge Request)

Tasks that depends on each other

"Incorrect" ways

Solution

Conclusion

Credits

Git for grad students (part 2)

What problem does Git branch solves?

Basic workflow

View, create, merge branch

Conflict and resolve conflict

Explain strange commands from part 1

A fun thought experiment

Conclusion

Credits

Git for grad students (part 1)

More background on why I wrote this article

What problem are we trying to solve?

What is Git?

What is versioning?

Create a new version

View all your project's versions

Practice a little bit

See a previous version

Rollback to a previous version

.gitignore file

Conclusion

Credits

Integrate React component into Solid JS (with Typescript) (part 3)

Why not use the tsc way?

Why Rslib?

Setup our application

Understand Rslib configuration

Bundle and entry settings

dts settings

Format esm setting

Output target web setting

Plugin React setting

Use Tailwind CSS with Rslib

Optional: dts settings abort on error

Serves both as a library and running independently

Add Rsbuild

Config Rslib to ignore the main.tsx file

Mount function improvements

Render many times

Render on full screen option

Conclusion

Integrate React component into Solid JS (with Typescript) (part 2)

Communicate from React component to the main Solid application

Communicate from the main Solid application to the React component

Conclusion

Integrate React component into Solid JS (with Typescript) (part 1)

I really like Solid JS, but...

Why it seems like an easy-to-solve problem but actually not

Solving the compile problem (with PNPM workspace)

PNPM workspace

Optional: the `develop` branch

Optional: the `--filter` flag