DEV Community: Vyacheslav Chub

The secrets of efficient CV analyzing. The E-pattern. Tips & Tricks.

Vyacheslav Chub — Mon, 14 Jul 2025 14:47:43 +0000

Long time no see! 😉

It's been over a year since I published my first non-technical article, The Interview Under the Hood. Hiring, recruitment, and candidate evaluation have been integral parts of my career, as I’ve spent the last six years working as a technical interviewer.

I take great pride in being part of a team that helps shape the future of my amazing team, Valor Software.

The world is changing faster than ever, and the IT market is feeling the impact. AI advancements, financial instability, and company optimizations have led to fewer job openings and higher expectations for candidates. As a result, the number of CVs being reviewed has skyrocketed.

I'm sure my fellow recruiters understand this challenge all too well. As a technical interviewer, I review many CVs—but you handle even more. On top of that, technical interviewers must balance CV estimating with development work, making CV evaluation faster.

However, speed should never come at the cost of quality. We're selecting our future colleagues! It's just as important to identify the right candidates as it is to filter out the wrong ones—both are equally essential.

CV evaluation is the first step in recruitment, yet it's often underestimated. It's time to give it the attention it deserves.

In this article, I explore key patterns in CV evaluation and share my own insights tailored to the specifics of the IT industry. I’m excited to offer practical yet essential strategies to enhance the hiring process.

Before diving into the main topic, I’d like to highlight some key aspects of CV analysis. It’s important that we’re on the same page.

The goal

Although we evaluate the CV's content rather than the candidate directly, our goal is to gain the clearest possible understanding of the person behind it.

The CV-related antipatterns

Candidates sometimes exaggerate their skills or include irrelevant information, making it harder to assess their true qualifications. This can complicate decision-making and slow down the hiring process.

Let’s take a closer look at this issue by classifying some well-known CV anti-patterns.

💡 Tip #1: Always keep this challenge in mind when reviewing resumes.

Technological Zoo

Some candidates list every possible technology used in their projects—even those they barely worked with—just to make their CVs look impressive. Sometimes, these lists are labeled as Technologies used on the project.

This raises a valid question: What part of this tech stack did you actually work with?

In other cases, we encounter even more misleading approaches, such as the following…

Example 1.
There is a senior developer with 5 years of experience. There is only one part of the experience.

Foo Bar Ltd.   2023-01 -- 2023-11
...
Technologies used: TypeScript, Express.js, Nest.js, PostgreSQL, React.js, Redis, RabbitMQ, MongoDB, Golang, .NET, GCP, Jest, Chai, AWS, Lambda, Terraform, MS SQL server.

The list above is not so, long and could look relevant at first glance. However, we see a drastically wide list of technologies including different IT specializations like JS/TS, Golang/Devops, and .NET. Is it possible to use deeply all of them in the short period above (2023-01 - 2023-11) by one person? I guess, not.

💡 Tip #2: If you choose to address the Technological Zoo during the prescreening stage, politely ask the candidate:

Which technologies did you personally use?
How much time (ideally in hours) did you spend working with each?
Keep in mind that while this approach provides clarity, it can also extend the screening process.

"Water" Explanations in Job Descriptions.

Let's consider the following example

Example 2.

Collaborated with the foreign to comprehend requirements and develop efficient solutions, resulting in a 15% increase in project productivity speed.

Demonstrated expertise in back-end technologies, contributing to the successful launch of over 100 major projects that improved user engagement.

The descriptions above might be suitable for a managerial CV, where broader explanations are expected. However, for a technical candidate, this doesn’t suffice.

In technical CVs, we need clear, concise descriptions of decisions and contributions to properly assess the candidate’s expertise.

Example 3.

Backend optimizations, reducing data processing times by 30% using
Node.js streams.

Developed and maintained unit and integration tests using Jest, improving test coverage.

Built authentication and authorization flow using Keycloak

The example above is very informative from a technical perspective. Isn't it?

💡 Tip #3: Pay close attention to metrics in a CV, such as "Improved data processing by 30%" or "Reduced load times by 15%".

A good way to verify these claims is to ask:

👉 "According to your CV, you reduced data processing times by 30% using Node.js streams. How did you measure this?"

If the candidate cannot explain how they arrived at the number, it’s a red flag—it could indicate exaggeration or irrelevance.

✅ A credible response might be:
"I (or my DevOps/Product Manager) gathered this data from DataDog (or another monitoring tool). The system was already being monitored before I started working on the project."

🔹 For projects older than three years, the candidate should confidently recall the monitoring system used—otherwise, their claim may be questionable.

Third-person narration

We need to be mindful of We statements in CVs—yes, it’s a bit of a tautology, but an important one.

Some candidates use team-based phrasing to subtly exaggerate their contributions. This tactic helps them mask knowledge gaps while avoiding outright falsehoods. Instead of highlighting their individual impact, they shift focus to the team as a whole—this is a psychological trick.

This anti-pattern is particularly common during pre-screen introductions.

💡 Tip #4: If you choose to address third-person narration during prescreening, ask the candidate politely:

👉 "What were your personal contributions to this project?"

Also, pay close attention to their reaction—hesitation or vagueness may indicate an attempt to inflate their role. However, keep in mind that this approach takes extra time.

An inconsistent set of Job positions

Experienced developers will likely agree that many of us must adapt to new tech stacks every 3 to 6 years. Migrations—such as PHP to Node.js, jQuery, and ExtJS to React or Angular, or C++ to Rust or Golang—are common in our fast-paced industry.

However, not all migrations are positive career moves—some can be anti-patterns. The key indicator for identifying whether a migration might be problematic is the time range of job positions in the candidate’s history.

Let's look at the CV below.

Example 4.

Looking at the CV, it's a Senior Java Developer. But if we dig the CV much more preciously we will find that the relevant experience of Jack is only one year and his previous around 10 years of experience is mostly about the PHP stack. Should we consider this candidate as a Senior Java Developer? I guess not because Java and PHP stacks are drastically different. If his experience could, say regarding .NET instead of PHP, it would be maybe worth considering him as a Senior Java Developer because the .NET stack is much closer to Java than PHP.

💡 Tip #5: Deepen your understanding of technological aspects!

Being familiar with tech stacks, frameworks, and industry trends will help you better assess CVs, spot inconsistencies, and ask the right questions during evaluations.

The patterns of CV scanning

After reviewing the anti-patterns, we can now move on to CV analysis.

As you may have gathered from the context of this article, we’re focusing on fast reading techniques—so instead of "reading," I'll use the term "scanning."

Here are the key scanning patterns to consider. You can find more information regarding the patterns in this article.

F-Pattern
Z-Pattern
Layer-Cake Pattern
Love-at-First-Sight Pattern
Lawn-Mower Pattern
Spotted Pattern
Marking Pattern
Bypassing Pattern
Commitment Pattern

In this article, I focus solely on the F- and Z-patterns, as other approaches don’t seem well-suited for the fast scanning of IT-related CVs. I won’t dive into the reasons behind this choice, but if you’ve read the article so far, I trust you’ll understand my perspective.

The F-pattern

The F-pattern of CV analyzing refers to how recruiters and hiring managers visually scan a resume. This pattern is based on eye-tracking studies that show readers naturally follow an "F" shape when skimming text-heavy documents.

How the F-Pattern Works in CV Analysis:

Top Horizontal Scan - Recruiters start by reading the top section, typically scanning from left to right. This includes the name, contact details, and professional summary.
Second Horizontal Scan - Their eyes move down slightly and scan another horizontal section, usually where job titles, company names, and key skills are located.
Vertical Scan on the Left - Finally, they move down the left side, quickly glancing at bullet points, dates, and section headings (like Work Experience, Education, etc.).

The spoiler. The feature of my using the F-pattern is slightly different from the above. I usually stop on the latest job position.

The Z-pattern

The Z-pattern of CV analyzing is another way recruiters scan resumes, but it's more common in visually structured layouts, such as modern, two-column CVs or those with graphics and design elements.

How the Z-Pattern Works in CV Analysis:

Top Horizontal Scan (Left to Right) - The recruiter first looks at the top section, scanning from left to right. This typically includes your name, contact details, and headline (or professional summary).
Diagonal Movement (Top Right to Bottom Left) - Their eyes then move diagonally across the page, looking at job titles, key skills, or important highlights that stand out.
Bottom Horizontal Scan (Left to Right Again) - Finally, they scan the bottom of the page, where they might see education, certifications, or additional skills.

The Psychology of Reading a CV / Resume - F & Z Patterns

F-Pattern vs. Z-Pattern in CVs:

F-Pattern = Best for text-heavy, traditional resumes (e.g., corporate, finance, law).
Z-Pattern = Best for modern, visually structured resumes (e.g., marketing, design, tech).

In F-Shape Pattern And How Users Read you can find the list of well-known reading patterns with brief explanations.

Based on the explanations above, each of the discussed scanning patterns has its own strengths and weaknesses. However, through my experience, I’ve found that neither fully fits the IT industry’s needs, especially when analyzing Senior Developer CVs.

As a result, I’ve developed my own approach—one that I’m excited to share with you, my dear reader.

Meet the E-pattern!

Let me explain how this method works:

Step-by-Step Process

1️⃣ First Motion (N1): Initial Scan

Look at the CV’s top section, focusing on: Candidate’s description, Contact information, Technological stack, Latest job position
Apply the F-pattern to quickly grasp key details.
This gives us an initial understanding of the candidate.

2️⃣ Second Motion (N2): Bottom-Up Analysis

Start from the bottom of the CV, where education details are listed.
Move upward, scanning each job position quickly but effectively by applying these rules:

✅ For each job position:

Check the date range → If it’s less than six months, it may not be worth much attention (depends on the role).
Identify potential anti-patterns → Use insights from the F-pattern scan.
Grasp the essence of the position as fast as possible.

💡 By the way, if you ask me which letter best represents this process, my answer is 100% "L"!

Why Scan from the Bottom Up?

You might wonder why we start from the earliest experience instead of reading top-down. Here’s the reasoning:

📌 A CV isn’t just about reading experience—it’s about understanding the person behind it.

📌 The best way to do that is by analyzing the candidate’s evolution and career growth step by step.

📌 Since we already gathered key insights from the F-pattern scan, we’re now prepared to connect the dots and see the bigger picture.

This chronological approach helps us decode the candidate’s journey—not just their latest role, but how they got there. It’s like solving a puzzle with a structured, efficient method.

E = F + L is quite simple ;)

The key feature of the E-pattern is that it combines two essential perspectives:

F-pattern → Helps us quickly understand who the candidate is.
L-pattern → Reveals how the candidate got there.
By identifying anti-patterns along the way, we gain valuable insights to decide whether a pre-screen interview is necessary.

Why This Approach Saves Time

Top-down (F-motion) → Quickly scans critical details like skills, contact info, and the latest role.
Bottom-up (L-motion) → Provides a deeper understanding of career progression and consistency.
As you can see, the F-pattern works best for the top section, while the L-pattern is ideal for the rest of the CV.

Now, let’s explore some hypothetical practical examples to see this method in action.

Example 5.

In this example, we’re evaluating a Senior Back-End Developer using the E-pattern approach.

Step 1: Apply the F-Pattern

Scanning the top section of the CV:

✅ The summary information suggests relevance.

✅ Some fluff ("water") is present, but it's not a dealbreaker at this stage.

Step 2: Apply the L-Pattern

1️⃣ Education → ✅ Looks fine.

2️⃣ Call Bank position → ❌ Not relevant (not related to development) → Skip.

3️⃣ R&B Consulting position → ❌ Only 4 months → Skip.

4️⃣ T&T Consulting position → ❌ 7 months isn’t enough for proper onboarding → Skip.

5️⃣ Descriptions → ❌ All roles contain fluff and at least two anti-patterns per position.

6️⃣ Final check under L-pattern → ❌ All positions had to be skipped.

7️⃣ Latest role is just 7 months long → Total relevant experience = 7 months.

Final Decision

Does this CV align with Senior-level expectations?
❌ No!

This candidate does not qualify for a Senior Back-End Developer role.

🔍 Key Takeaway: Even if a CV looks promising at first glance, applying structured scanning techniques like the E-pattern (F + L) helps us filter out unqualified candidates efficiently.

💡 Tip #6: Time ranges matter!

Pay close attention to job durations—they can reveal a lot about a candidate’s stability, experience depth, and career progression. Short stints (less than six months) may indicate instability, while longer tenures can suggest commitment and expertise in a given role.

Let's consider another CV.

Example 6.

In the example above, we’re evaluating a Senior Full-Stack Developer using the E-pattern approach.

Step 1: Apply the F-Pattern

Scanning the top section of the CV:

✅ The summary information indicates that the candidate is generally relevant.

✅ There might be some fluff ("water"), but it’s not a major concern at this stage.

Step 2: Apply the `L-Pattern`

🔹 Education → ✅ Looks good.

🔹 Job positions → ✅ Time ranges and descriptions appear relevant.

🔹 Career progression → ✅ Shows a consistent evolution from Front-end Developer to Full-Stack Developer—a strong indicator of growth.

Final Decision
Is this candidate suitable for the pre-screen? Yes, absolutely!

Of course, my approach is not a strict rule—it’s simply a guideline. In some cases, anti-patterns might not be as critical as they seem, and a candidate could still be a strong fit.

Ultimately, the final decision should be based on your recruiter’s intuition and professional judgment. The E-pattern is just a tool to assist you—not a replacement for your expertise.

💡 Tip #7: The Candidate’s CV Is NOT the Candidate!

📌 A poorly structured or messy CV does not necessarily mean a bad candidate.

📌 Likewise, a well-polished CV does not guarantee strong technical skills.

📌 In my experience, I’ve seen candidates with terrible CVs ace every interview stage—and others with flawless resumes fail completely.

I hope my experience helps you refine your CV screening process.

Happy recruiting! 🚀

Tauri CRUD Boilerplate

Vyacheslav Chub — Wed, 10 Apr 2024 07:23:35 +0000

Hi, dear Tauri! Long time no see. I published my first post, Developing a Desktop Application via Rust and NextJS. The Tauri Way almost a year ago. Since then, Tauri has become stronger. I'm happy about that! And now, I am very pleased to make a useful contribution to the Tauri community. As a full-stack developer, I frequently face situations where I need to start a DB-based UI project as fast as possible. It's stressful if I need to start the project from 100% scratch. I prefer to keep some boilerplates on hand, which will save me time and nerves and will be the subject of this article.

I want to present you with my first version of the Tauri CRUD Boilerplate, which will help you bootstrap and prototype a new Tauri project from scratch. Let me focus on explanations in a What-Where-When style.

My Tauri CRUD Boilerplate is not a silver bullet; it's just a set of valuable scratches that help you build and connect the DB and UI parts via Tauri. Also, the Tauri CRUD Boilerplate is useful primarily for fast prototyping because it contains React and Ant Design as UI players inside, and, of course, you can substitute them with another library or framework or even provide your custom solution instead. If we focus on the DB part, I use SQLite due to its simplicity and portability. In the future, you can change SQLite. As a roadmap, I'll think about the second version of the bootstrap when DB will be substituted with the equivalent REST API plus authentication.

Let's get started.

There are a couple of tables, person and todo.

CREATE TABLE IF NOT EXISTS person (
    id INTEGER PRIMARY KEY NOT NULL,
    name VARCHAR(250) NOT NULL
);

CREATE TABLE IF NOT EXISTS todo (
    id INTEGER PRIMARY KEY NOT NULL,
    date VARCHAR(20) NOT NULL,
    notes TEXT,
    person_id INTEGER NOT NULL,
    completed INTEGER NOT NULL,
    FOREIGN KEY(person_id) REFERENCES person(id)
);

As we can see, each person can contain a set of todos. person_id is a foreign key here.

I implemented the following functionality.

Data management (see Data tab below). The main aim is to create an empty SQLite DB (according to the definitions above) and fill it with the test data.
The Persons tab contains a table that shows a set of persons and provides functionality for adding, editing, and deleting them.
The Todos tab contains two related widgets: Persons as a read-only list and a table that shows a set of person-related todos. It provides functionality for adding, editing, and deleting them.

Data

Let me highlight some essential points in the Data tab code.

You can find Create DB-related DB code here and UI code here.
You can find Fill DB-related DB code here and UI code here.

It's important to have test data and the ability to recreate it when needed (via Create DB). If you want to remove the DB, you can just delete a related file.

DB connect

It's time to know how the connection with the DB works. First, we need to get the SQLite DB path

fn get_database_path() -> io::Result<PathBuf> {
    let mut exe = env::current_exe()?;
    exe.set_file_name("./db");
    #[cfg(dev)]
    exe.set_file_name("../../../db");
    Ok(exe)
}

In production mode, we use the current folder to keep the DB, and the DB will be kept in the same folder as the executable file. But in the case of the debug mode, I prefer to keep the database file at the root of the project. Because the executable file in debug mode is placed in [project folder]/src-tauri/target/debug, we conditionally use the ../../../ path that's equal to the project folder in debug mode. Fortunately, the cfg attribute helps us to do that. BTW, you can change this logic if needed.

After we have a DB part, we need to get a path as a string

pub fn get_database() -> String {
    let db_url = match get_database_path() {
        Ok(path) => path.into_os_string().into_string().unwrap(),
        Err(e) => e.to_string(),
    };
    return db_url;
}

We use the util function above in other functions the following way. For example, when we need to insert a new record into the person table.

#[tauri::command]
pub async fn person_insert(name: &str) -> Result<i64, String> {
    // get DB url as a string
    let db_url = util::db::get_database();
    // Connect with the DB; get connection from the pool
    let db = SqlitePool::connect(&db_url).await.unwrap();
    // Do all needed DB stuff
    let query_result = sqlx
        ::query("INSERT INTO person (name) VALUES (?)")
        .bind(name)
        .execute(&db).await;
    if query_result.is_err() {
        db.close().await;
        return Err(format!("{:?}", query_result.err()));
    }

    let id = query_result.unwrap().last_insert_rowid();
    // Close the connection
    db.close().await;
    Ok(id)
}

Persons

It's time to understand how our first CRUD works on the example of Persons.

Let's dig into the UI part. You can read full text of the component here.

Also, let's dig into the data loading. Please, read comment in the following code.

  const load = async () => {
    try {
      // get the data
      const result = await apiCall("person_select");
      // make it as a JSON
      const items = JSON.parse(JSON.parse(result as unknown as string));
      // set the related React state variable
      setData(
        items.map((item: any) => ({
          key: item.id,
          ...item,
        }))
      );
    } catch (e) {
      console.error(e);
      errorMessage.open({
        type: "error",
        content: "Can't load the person list",
      });
    }
  };

Let's focus on apiCall function. This function is important because it's a link between React and Rust parts.

import { InvokeArgs, invoke } from "@tauri-apps/api/tauri";

export const apiCall = async <T>(
  name: string,
  parameters?: InvokeArgs
): Promise<T> =>
  new Promise((resolve, reject) =>
    invoke(name, parameters)
      .then(resolve as (value: unknown) => PromiseLike<T>)
      .catch(reject)
  );

We import invoke function from @tauri-apps/api/tauri and just call the following functionality in Rust part. In this example we are talking about person_select

#[tauri::command]
pub async fn person_select() -> Result<String, String> {
    let db_url = util::db::get_database();
    let db = SqlitePool::connect(&db_url).await.unwrap();
    let query_result = sqlx
        ::query_as::<_, Person>("SELECT id, name FROM person ORDER BY id DESC")
        .fetch_all(&db).await;
    if query_result.is_err() {
        db.close().await;
        return Err(format!("{:?}", query_result.err()));
    }
    let results = query_result.unwrap();
    let encoded_message = serde_json::to_string(&results).unwrap();
    db.close().await;
    Ok(format!("{:?}", encoded_message))
}

Also, I'd like to focus your attention on the following data structure.

#[derive(Serialize, Clone, FromRow, Debug)]
pub struct Person {
    id: i64,
    name: String,
}

After that, I intend to be brief because I don't want to waste your time. That's why I am providing you with some significant points regarding the code.

Let's look at Insert and Edit...

Press New Person button or Edit button on each row of data.
Both of addNewRow and doEdit works with the modal window here that use PersonEdit component.
The following logic works when the form from the component above has been submitted. Its main goal is to make all expected changes (call Rust code), hide the modal window, or show the error if it is not OK.

Todos

Todos functionality is a bit more complicated than Persons because it contains Persons and is represented by TodoContainer component that you see below. Let's focus on how TodoContainer works.

It based on a Antd's Tab component.
Tab's items are persons.
Each Tab-person has its own Todo table that also contains adding and editing functionalities.

Focusing on the Todo and TodoEdit components doesn't matter because their logic is similar to that of Person and PersonEdit.

How to use

I want to stop discussing the code and focus on some practical aspects. Let's run the app in dev mode.

Traditionally,

npm ci

Run in dev mode

npm run tauri dev

In production mode:

npm run tauri build

You can found:

An installer-based (dmg) app in [project root]/src-tauri/target/release/bundle/dmg if you want to run the installer
Or just the app in [project root]/src-tauri/target/release/bundle/macos if you want to run the app directly

Components refreshing

The app's most tricky part concerns data synchronization. Imagine we just added a new person to the Persons tab and moved them to the Todo tab. The person list on the left side should be refreshed, shouldn't it? Let me share some thoughts about data synchronization.

I provided a context that contains the following data.

refreshDescriptor that contains a couple of fields person and todo.
A set of methods for the state refreshing: refreshPerson and refreshTodo

import React, { createContext, useContext, useState } from "react";

export interface DataRefreshDescriptor {
  person: Date;
  todo: Date;
}

type GlobalContextProps = {
  refreshDescriptor: DataRefreshDescriptor;
  refreshPerson: () => void;
  refreshTodo: () => void;
};

const GlobalContext = createContext({} as GlobalContextProps);

export type TargetKey = React.MouseEvent | React.KeyboardEvent | string;

export const GlobalProvider = ({ children }: { children: React.ReactNode }) => {
  const now = new Date();
  const [refreshDescriptor, setRefreshDescriptor] =
    useState<DataRefreshDescriptor>({
      person: now,
      todo: now,
    });

  const refreshPerson = () => {
    setRefreshDescriptor({ ...refreshDescriptor, person: new Date() });
  };

  const refreshTodo = () => {
    setRefreshDescriptor({ ...refreshDescriptor, todo: new Date() });
  };

  return (
    <GlobalContext.Provider
      value={{
        refreshDescriptor,
        refreshPerson,
        refreshTodo,
      }}
    >
      {children}
    </GlobalContext.Provider>
  );
};

export const useGlobalContext = () => useContext(GlobalContext);

The following fragment of code illustrates us how to use the refreshDescriptor. Please, read comments there.

// let's skip imports
export default function TodoContainer() {
  // get the refreshDescriptor
  const { refreshDescriptor } = useGlobalContext();
  const [errorMessage, errorMessageHolder] = message.useMessage();
  const [tabs, setTabs] = useState<TabsProps["items"]>([]);

  const loadPersons = async () => {
    // let's skip the details
  };

  useEffect(() => {
    // if refreshDescriptor.person has been changed, we need to reload the person list
    loadPersons();
  }, [refreshDescriptor.person]);

  return (
    <>
      {errorMessageHolder}
      <Tabs tabPosition={"left"} items={tabs} />
    </>
  );
}

Please, look at another example of refreshing. You can find the full version here. Please, read comments.

// imports ...

export default function Person() {
  const { refreshDescriptor, refreshPerson } = useGlobalContext();
  // skip...

  const doDelete = async (id: number) => {
    try {
      await apiCall("person_delete", { id });
      // change the 'person' field of the descriptor if a new person was deleted
      refreshPerson();
    } catch (e) {
      // skip...
    }
  };

  // skip...

  const load = async () => {
    // skip...
  };

  useEffect(() => {
    load();
    const columns: ColumnsType<DataType> = [
      /// skip...
    ];
    setColumns(columns);
  }, [refreshDescriptor.person]);

  const doEditOk = () => {
    editFormRef.current.submit();
  };

  const handleEditOk = async (formData: DataType) => {
    try {
      if (currentRecord?.id) {
        await apiCall("person_update", {
          name: formData.name,
          id: currentRecord.id,
        });
      } else {
        await apiCall("person_insert", {
          name: formData.name,
        });
      }
      setEditVisible(false);
      // change the 'person' field of the descriptor if a new person was added or changed
      refreshPerson();
    } catch (e) {
      setEditVisible(false);
      // skip...
    }
  };

  // skip...

  return !columns ? (
    <></>
  ) : (
    <div>
      {errorMessageHolder}
      <Button onClick={addNewRow} style={{ margin: 10 }}>
        New Person
      </Button>
      <Table
        columns={columns}
        dataSource={data}
        pagination={false}
        scroll={{ y: "calc(100vh - 200px)" }}
      />
      <Modal
        title="Person"
        open={editVisible}
        onOk={doEditOk}
        onCancel={handleEditCancel}
      >
        <PersonEdit
          ref={editFormRef}
          currentRecord={currentRecord}
          handleEditOk={handleEditOk}
        ></PersonEdit>
      </Modal>
    </div>
  );
}

We call refreshPerson if we expect another or the current widget refreshing. If you add some new functionality in the future, you need to:

add new fields to refreshDescriptor
provide the related functions and add them to the context
use them the way described above

The App component

I suppose it's the simplest part of the solution.

import { Tabs, TabsProps } from "antd";
import "./App.css";
import Person from "./Person";
import TodoContainer from "./TodoContainer";
import Data from "./Data";
import { useGlobalContext } from "./GlobalContext";

const tabs: TabsProps["items"] = [
  {
    key: "persons",
    label: "Persons",
    children: <Person />,
  },
  {
    key: "todo",
    label: "Todo",
    children: <TodoContainer />,
  },
  {
    key: "data",
    label: "Data",
    children: <Data />,
  },
];

function App() {
  const { refreshPerson, refreshTodo } = useGlobalContext();

  return (
    <Tabs
      items={tabs}
      onTabClick={(key: string) => {
        if (key === "persons") {
          refreshPerson();
        }
        if (key === "todo") {
          refreshTodo();
        }
      }}
    />
  );
}

export default App;

Please pay attention to the onTabClick handler. We change the related fields of refreshDescriptor every time we open a related tab.

The recommendations

This part is essential because all that I just told you should be continued with your, my dear reader, part. I aim to summarize and guide you regarding your future steps with the boilerplate. Of course, all that I intend to share with you is not dogma; it's just my subjective opinion that I hope will help you.

I recommend starting with the Rust part.
You could create a separate rs-file. This is a good example. Also, don't forget to add it to mod.rs
After you need to make the following changes in main.rs: use the module and tell Tauri about the new functionality. That's it regarding Rust-part. It's time to code in React.
Create a table-based component like the following
Create a form-based component like the following
Use the table-based component in the following way

PS: It's important to note that the solution above is just one of my first attempts at the topic; therefore, do not judge strictly. Also, I'd like to know how this solution works under Windows. Anyway, happy hacking, guys ;)

Painless CLI integration testing

Vyacheslav Chub — Wed, 10 Jan 2024 13:15:03 +0000

Introduction

Most of my articles describe stories from my routine software development. This particular article continues that pattern. Some time ago, I was given a task that forced me to think conceptually. Apart from that, the task contained some challenging aspects that I hadn't faced before. That's why I have decided to share my knowledge after completing the task.

There is a CLI application based on Inquirer. Potentially, it could be another CLI library, say something from the following list. Our goal is to provide integration tests. But before that, let's look at the related terminology.

According to https://katalon.com/resources-center/blog/integration-testing

Integration testing is a type of software testing where components of the software are gradually integrated and then tested as a unified group. Usually, these components are already working well individually, but they may break when integrated with other components. With integration testing, testers want to find defects that surface due to code conflicts between software modules when they are integrated with each other.

I like integration testing because it's always about balance between something small and something big. Google terminology defines it as 'medium' for a reason.

In short, we need to test the user's input from one hand simultaneously and the result of the input processing on the other.

The second question is quite the opposite. What we shouldn't test? We can answer it only considering the solution because our code is not a black box in the case of integration tests.

The original solution

original.ts

import { prompt, Answers } from "inquirer";
import { writeFile } from "fs";

async function sleep(time: number) {
  return new Promise((resolve) => setTimeout(resolve, time));
}

prompt([
  {
    name: "name",
    type: "input",
    message: "What's your name?",
    validate: async function (input: string) {
      await sleep(1500);
      if (input === "wrong") {
        return "Incorrect user!";
      }
      return true;
    },
  },
  {
    name: "iceCream",
    type: "list",
    message: "Which is your favorite of the following ice cream flavors?",
    choices: ["Green tea", "Strawberry", "Blackberry", "Chile", "Vanilla"],
  },
  {
    name: "programmingLanguage",
    type: "list",
    message: "What programming language do you prefer?",
    choices: ["Basic", "Golang", "Javascript", "Cobol", "Java", "Rust", "C++"],
  },
]).then((answers: Answers) => {
  writeFile(
    `result-${new Date().toISOString()}.json`,
    JSON.stringify(answers, null, 2),
    (err) => {
      if (err) {
        console.log(err);
        return;
      }
      console.log("Done...");
    }
  );
});

I intentionally skipped some apparent technological aspects because it's off-topic. Despite that, I'll provide you with some mandatory thoughts and commands. First, you can find the solution here.

Please download and npm ci, and npm start or npm test it.

Let's run and test the solution manually.

➜  cli-testing git:(main) ✗ npm start

> cli-testing@1.0.0 start
> ts-node app.ts

? What's your name? Test name
? Which is your favorite of the following ice cream flavors? Blackberry
? What programming language do you prefer? Javascript
Done...
➜  cli-testing git:(main) ✗ ls
README.md                            eslintrc.js                          node_modules                         package.json
app.spec.ts                          jest.config.ts                       original.ts                          result-2023-12-19T11:02:52.815Z.json
app.ts                               lib.ts                               package-lock.json                    tsconfig.json
➜  cli-testing git:(main) ✗ cat result-2023-12-19T11:02:52.815Z.json
{
  "name": "Test name",
  "iceCream": "Blackberry",
  "programmingLanguage": "Javascript"
}

It proposes three questions, and after answering, it writes the answers into a separate file containing a JSON-based result. Also, pay attention to the validate function in the code above. It's a powerful mechanism to make additional checks before the answer is accepted. I put a delay there.

    validate: async function (input: string) {
      await sleep(1500);
      if (input === "wrong") {
        return "Incorrect user!";
      }
      return true;
    },
  },

But it could be an API call or tricky logic in real life. There are no prizes for guessing that we don't need to test this functionality in case of integration tests. Also, we shouldn't test external file writing functionality.

The solution above looks like a monolith. That's why integration testing testing is impossible here. To reach our goal, we must split the following logic into separate external modules or functionalities.

Validator's logic.
Result writing.
The rest. It means the central part, including the user's input.

Based on the following, we need to refactor the code above. Let's do our solution in a test-friendly way.

Make the solution test-friendly

Please don't hesitate to read the comments in the code below. It will be helpful.

lib.ts

import { prompt, Answers } from "inquirer";

async function sleep(time: number) {
  return new Promise((resolve) => setTimeout(resolve, time));
}

// Validator's logic.
export const nameValidator = async (input: string) => {
  await sleep(1500);
  if (input === "wrong") {
    return "Incorrect user!";
  }
  return true;
};

// The central part, including the user's input.
export default function cli(resultHandler: (answers: Answers) => void) {
  prompt([
    {
      name: "name",
      type: "input",
      message: "What's your name?",
      validate: nameValidator,
    },
    {
      name: "iceCream",
      type: "list",
      message: "Which is your favorite of the following ice cream flavors?",
      choices: ["Green tea", "Strawberry", "Blackberry", "Chile", "Vanilla"],
    },
    {
      name: "programmingLanguage",
      type: "list",
      message: "What programming language do you prefer?",
      choices: [
        "Basic",
        "Golang",
        "Javascript",
        "Cobol",
        "Java",
        "Rust",
        "C++",
      ],
    },
  ]).then(resultHandler);
}

and use it as

app.ts

import { Answers } from "inquirer";
import { writeFile } from "fs";
import cli from "./lib";

cli((answers: Answers) => {
  // Result writing
  writeFile(
    `result-${new Date().toISOString()}.json`,
    JSON.stringify(answers, null, 2),
    (err) => {
      if (err) {
        console.log(err);
        return;
      }
      console.log("Done...");
      process.exit(0);
    }
  );
});

As a result of the above, we have the essential decisions below.

Now, nameValidator is external, and we can mock it.
The main cli part is encapsulated in the external function, and we can use it in both the app and tests.
We separated the main logic from file writing functionality.

The points above give us the opportunity to test the solution as easily as possible.

Before test writing, I want to focus on the central moment of the article. There are the following main conceptual approaches to test the CLI.

Run the CLI as a separate process and intercommunicate with them.
Run the CLI functionality inside the tests.

I chose the second one because it's more suitable for integration testing. The first is mostly regarding e2e or Big (Google definitions) tests. Also, the second approach is much more straightforward in implementation. But there is one critical answer here. We must pass the input data (key presses) to the CLI.

If we talk about the first approach, the following approaches will be useful: Nodejs Child Process: write to stdin from an already initialised process, RobotJS. It makes sense to note here that the approaches above are rather for e2e testing than integration.

If we work with the integration tests, node-mock-stdin is mandatory! It provides a mock readable stream, useful for testing interactive CLI applications. It allows to put the different data to the stdin the following way.

var stdin = require('mock-stdin').stdin();
stdin.send("Some text", "ascii");
stdin.send(Buffer("Some text", "Some optional encoding"));
stdin.send([
  "Array of lines",
  "  which are joined with a linefeed."
]);

// sending a null will trigger EOF and dispatch an 'end' event.
stdin.send(null);

Testing

We use Jest Framework for testing. Jest is not a dogma, and, of course, in its place can be any other test runner, such as Mocha or Ava. Let's focus on tests. I'll provide a short example because I don’t want to waste your time. You can find the full version here. It's crucial to read the comments in the code below. Let's go!

import {
  describe,
  it,
  expect,
  beforeEach,
  afterEach,
  jest,
} from "@jest/globals";

import { Answers } from "inquirer";
import { stdin } from "mock-stdin";

import cli from "./lib";

// We need to import the whole lib module for future mocking.
import * as funcModule from "./lib";

// There are key press code sequences to pass them to mocked stdin.
const DOWN = "\x1B\x5B\x42";
const ENTER = "\x0D";

describe("Cli", () => {
  let mockStdin: any;
  let validatorSpy: any;

  // Let's spy nameValidator function.
  const getValidatorSpy = () => jest.spyOn(funcModule, "nameValidator");

  // This is a util function 
  const pauseAndSend = async (data: string): Promise<void> =>
    new Promise((resolve) => {
      process.nextTick(() => {
        mockStdin.send(data);
        resolve();
      });
    });

  beforeEach(async () => {
    // According to https://github.com/caitp/node-mock-stdin?tab=readme-ov-file#modulestdin
    mockStdin = stdin();
  });

  afterEach(async () => {
    // According to https://github.com/caitp/node-mock-stdin?tab=readme-ov-file#mockstdinrestore
    mockStdin.restore();
    validatorSpy.mockRestore();
  });

  it("should get the correct data on happy flow 1", (done: () => void) => {
    // The mocked implementation returns valid. It means the validator has been passed the imagined input data.
    validatorSpy = getValidatorSpy().mockImplementationOnce(() =>
      Promise.resolve(true)
    );

    // Call the main functionality. It expects keyboard input, in this case, from mockStdin's side.
    // It waits for the input provided in the next block of code. That's why, without this block, the "cli" call below never ends.
    cli((answers: Answers) => {
      expect(answers).toStrictEqual({
        // The expected result should match with the input below.
        name: "Foo Bar",
        iceCream: "Chile",
        programmingLanguage: "Javascript",
      });
      done();
    });

    // This block pushes the keyboard input to mocked stdin and allows to finish the block above.
    (async () => {
      // Pass
      for (const command of [
        // Enter "Foo Bar" text and press Enter as an answer to the "name" question.
        "Foo Bar",
        ENTER,
        // DOWNx3 and press Enter means "Chile" option for the "iceCream" question.
        DOWN,
        DOWN,
        DOWN,
        ENTER,
        // DOWNx2 and press Enter means "Javascript" option for the "programmingLanguage" question
        DOWN,
        DOWN,
        ENTER,
      ]) {
        await pauseAndSend(command);
      }
    })();
  });
});

You can understand the comments above much better if you run and test manually the app.

npm start

The video below will be helpful, too.

Let's summarize crucial points regarding the code above.

Test only cli function, not file writing.

import cli from "./lib";

Mock the nameValidator the following way. We don't need to count it in integration tests. At least we can provide related unit tests.

const getValidatorSpy = () => jest.spyOn(funcModule, "nameValidator");

and

validatorSpy = getValidatorSpy().mockImplementationOnce(() =>
  Promise.resolve(true)
);

Call the main functionality to test. It is worth noting that the callback in the code below will be called after all the questions have been answered, i.e., all data has been entered. That's why if we don't enter the data into stdin, the cli call will wait infinitely or break after the timeout if we talk about Jest.

cli((answers: Answers) => {
  expect(answers).toStrictEqual({
    name: "Foo Bar",
    iceCream: "Chile",
    programmingLanguage: "Javascript",
  });
  done();
});

According to the thoughts above, we need to push the whole expected data into mocked stdin. After the data has been accepted the test can compare the actual result with the expected one.

(async () => {
  for (const command of [
    "Foo Bar",
    ENTER,
    DOWN,
    DOWN,
    DOWN,
    ENTER,
    DOWN,
    DOWN,
    ENTER,
  ]) {
    await pauseAndSend(command);
  }
})();

Pay attention to the pauseAndSend call, especially on the process.nextTick inside the function.

const pauseAndSend = async (data: string): Promise<void> =>
  new Promise((resolve) => {
    process.nextTick(() => {
      mockStdin.send(data);
      resolve();
    });
  });

We need to interrupt the current tick because the Inquirer needs some time for input processing. It could turn out that process.nextTick is not enough for the proper pause; that's why in other cases, say, we use another library instead of Inquirer, I'd like to recommend using setTimeout instead of process.nextTick.

The best illustration of the boring points above is the video below. Enjoy :)

Geeks' Post Scriptum

Now, I want to provide some knowledge related to real geeks. I'm fond of libraries like node-mock-stdin. And so, I firmly intend to share some exciting points regarding the amazing library above. But first, I'd like to remind you of some knowledge regarding process.stdin. So, node-mock-stdin substitutes process.stdin the following way.

function mock() {
  var mock = new MockSTDIN(process.stdin);
  Object.defineProperty(process, 'stdin', {
    value: mock,
    configurable: true,
    writable: false
  });
  return mock;
}

mock.Class = MockSTDIN;

module.exports = mock;

The approach above allows us to automate the data input.

I hope it helps you to understand the CLI testing concept under the hood. Happy testing!

Google Translate customization#2 under NextJS.

Vyacheslav Chub — Tue, 24 Oct 2023 10:59:41 +0000

You know, sometimes our first feelings let us down because the world around us is not so simple. I was going to stop with Google Translate customization under NextJS. This article reveals an approach to translate any content freely without pain via Google Translate on a NextJS-based project. But a couple of occasions became a game changer.

First, I found one essential improvement regarding language configuration. Second, my colleague Bruno Silva provided me with valuable code improvements. I decided to make a new series by analyzing the factors above. I recommend reading the previous series if you want to understand my following thoughts.

Let's get started.

The central part of the previous solution is public/assets/scripts/lang-config.js contains custom languages settings

window.__GOOGLE_TRANSLATION_CONFIG__ = {
  languages: [
    { title: "English", name: "en" },
    { title: "Deutsch", name: "de" },
    { title: "Español", name: "es" },
    { title: "Français", name: "fr" },
  ],
  defaultLanguage: "en",
};

The solution above is legal, but it doesn't look like a NextJS-pure. I found a more elegant way to define global data through NextJS config. Let's add env section to next.config.js and remove public/assets/scripts/lang-config.js

/** @type {import('next').NextConfig} */
const nextConfig = {
  reactStrictMode: true,
  env: {
    GOOGLE_TRANSLATION_CONFIG: JSON.stringify({
      languages: [
        { title: "English", name: "en" },
        { title: "Deutsch", name: "de" },
        { title: "Español", name: "es" },
        { title: "Français", name: "fr" },
      ],
      defaultLanguage: "en",
    }),
  },
};

module.exports = nextConfig;

I also changed public/assets/scripts/translation.js the following way because pageLanguage parameter is not mandatory.

function TranslateInit() {
  new google.translate.TranslateElement();
}

According to Bruno's proposal, I encapsulated most of the logic into a custom hook, src/hooks/useLanguageSwitcher.ts.

import { useEffect, useState } from "react";
import { parseCookies, setCookie } from "nookies";
import { NextPageContext } from "next";

export const COOKIE_NAME = "googtrans";

export interface LanguageDescriptor {
  name: string;
  title: string;
}

export interface LanguageConfig {
  languages: LanguageDescriptor[];
  defaultLanguage: string;
}

export type UseLanguageSwitcherResult = {
  currentLanguage: string;
  switchLanguage: (lang: string) => () => void;
  languageConfig: LanguageConfig | undefined;
};

export type UseLanguageSwitcherOptions = {
  context?: NextPageContext;
};

export const getLanguageConfig = (): LanguageConfig | undefined => {
  let cfg: LanguageConfig | undefined;

  if (process.env.GOOGLE_TRANSLATION_CONFIG) {
    try {
      cfg = JSON.parse(process.env.GOOGLE_TRANSLATION_CONFIG ?? "{}");
    } catch (e) {}
  }

  return cfg;
};

export const useLanguageSwitcher = ({
  context,
}: UseLanguageSwitcherOptions = {}): UseLanguageSwitcherResult => {
  const [currentLanguage, setCurrentLanguage] = useState<string>("");

  useEffect(() => {
    const cfg = getLanguageConfig();
    const cookies = parseCookies(context);
    const existingLanguageCookieValue = cookies[COOKIE_NAME];

    let languageValue = "";
    if (existingLanguageCookieValue) {
      const sp = existingLanguageCookieValue.split("/");
      if (sp.length > 2) {
        languageValue = sp[2];
      }
    }
    if (cfg && !languageValue) {
      languageValue = cfg.defaultLanguage;
    }
    setCurrentLanguage(languageValue);
  }, []);

  const switchLanguage = (lang: string) => () => {
    setCookie(context, COOKIE_NAME, "/auto/" + lang);
    window.location.reload();
  };

  return {
    currentLanguage,
    switchLanguage,
    languageConfig: getLanguageConfig(),
  };
};

export default useLanguageSwitcher;

Important note. process.env.GOOGLE_TRANSLATION_CONFIG allows us to get GOOGLE_TRANSLATION_CONFIG variable from the above mentioned NextJS config.

A couple of final stitches.

src/components/lang-switcher.tsx

import { NextPageContext } from "next";
import useLanguageSwitcher, {
  LanguageDescriptor,
} from "@/hooks/useLanguageSwitcher";
import React from "react";

export type LanguageSwitcherProps = {
  context?: NextPageContext;
};

export const LanguageSwitcher = ({ context }: LanguageSwitcherProps = {}) => {
  const { currentLanguage, switchLanguage, languageConfig } =
    useLanguageSwitcher({ context });

  if (!languageConfig) {
    return null;
  }

  return (
    <div className="text-center notranslate">
      {languageConfig.languages.map((ld: LanguageDescriptor, i: number) => (
        <React.Fragment key={`l_s_${ld}`}>
          {currentLanguage === ld.name ||
          (currentLanguage === "auto" &&
            languageConfig.defaultLanguage === ld.name) ? (
            <span className="mx-3 text-orange-300">{ld.title}</span>
          ) : (
            <a
              onClick={switchLanguage(ld.name)}
              className="mx-3 text-blue-300 cursor-pointer hover:underline"
            >
              {ld.title}
            </a>
          )}
        </React.Fragment>
      ))}
    </div>
  );
};

export default LanguageSwitcher;

useLanguageSwitcher looks elegant :)

src/pages/_document.tsx

import { Html, Head, Main, NextScript } from "next/document";
import Script from "next/script";

export default function Document() {
  return (
    <Html>
      <Head>
        <Script
          src="/assets/scripts/translation.js"
          strategy="beforeInteractive"
        />
        {process.env.GOOGLE_TRANSLATION_CONFIG && (
          <Script
            src="//translate.google.com/translate_a/element.js?cb=TranslateInit"
            strategy="afterInteractive"
          />
        )}
      </Head>
      <body>
        <Main />
        <NextScript />
      </body>
    </Html>
  );
}

We don't even physically include the translation engine if the config is missing.

You can find the final solution here.

May the Google Translate, NextJS, and Force be with you!

Google Translate customization under NextJS

Vyacheslav Chub — Mon, 16 Oct 2023 07:59:19 +0000

Traditionally, I'd like to start the article with the following. A few months ago, I faced a situation when my customer asked for a multi-language feature on a NextJS-based solution. The issue is that providing all local content with its vast volume and limited budget is impossible.

In other words, we have only one local version, say, English, and we need to translate it automatically to some others, say, Italian, Spanish, French, etc. But this isn't over. The future language switcher should be friendly with the current UI and 100% under the developer's control.

I started thinking and found that only one approach was suitable. It doesn't require additional settings on the Google Console side and allows us to translate to any language without pain.

You can try the solution, by the way.

However, the following problems still need to be solved.

Not the fact that the solution above, as it is, matched with NextJS specific.
The standard dropdown component looks too generic and is not customizable as the customer requested.

I don't want to put my routine of the research process on your plate, but describe the final decision step by step. If you want to face with my final solution now, please look at https://github.com/buchslava/nextjs-gtrans-demo.

Let's get started with the explanation!

Bootstrapping

Create a new NextJS project.

npx create-next-app@latest

What is your project named? -> nextjs-gtrans-demo
Would you like to use TypeScript? -> Yes
Would you like to use ESLint? -> No
Would you like to use Tailwind CSS? -> Yes
Would you like to use `src/` directory? -> Yes
Would you like to use App Router? -> No
Would you like to customize the default import alias? -> No

Also, install one extra dependency.

npm i nookies --save

Now we can run the app

npm run dev

It's time to implement the solution into the app. Please don't worry if you don't find some expected components during placing the code. Future steps will resolve it.

The main part

Let's change content in src/pages/index.tsx

import { LanguageSwitcher } from "./lang-switcher";

export default function Home() {
  return (
    <div className="h-screen flex flex-col">
      <header className="w-full pt-4">
        <LanguageSwitcher />
      </header>
      <div className="flex flex-col flex-1 overflow-auto">
        <hr className="h-px my-8 bg-gray-200 border-0 dark:bg-gray-700" />
        <article>
          <h2 className="mb-4 text-4xl font-extrabold leading-none tracking-tight text-gray-900 md:text-5xl lg:text-3xl dark:text-white">
            What is Lorem Ipsum?
          </h2>
          <p className="mb-7">
            Lorem Ipsum is simply dummy text of the printing and typesetting
            industry....
          </p>
        </article>
        // This is a part of the content. Please take the full version for the original solution!
      </div>
      <footer>
        <p className="mt-3">
          <a
            href="https://www.lipsum.com/"
            target="_blank"
            className="inline-flex items-center justify-center px-5 py-3 text-base font-medium text-center text-white bg-blue-700 rounded-lg hover:bg-blue-800 focus:ring-4 focus:ring-blue-300 dark:focus:ring-blue-900"
          >
            Source
            <svg
              className="w-3.5 h-3.5 ml-2"
              aria-hidden="true"
              xmlns="http://www.w3.org/2000/svg"
              fill="none"
              viewBox="0 0 14 10"
            >
              <path
                stroke="currentColor"
                stroke-linecap="round"
                stroke-linejoin="round"
                stroke-width="2"
                d="M1 5h12m0 0L9 1m4 4L9 9"
              />
            </svg>
          </a>
        </p>
      </footer>
    </div>
  );
}

I recommend temporarily forgetting the LanguageSwitcher component and focusing on the content mentioned above. The file contains three logical parts.

The header includes the language switcher component (will be described later)
The central part includes four paragraphs regarding Lorem Ipsum explanation
The footer contains a button as a link to the source of the content

Let's change src/pages/_document.tsx

import { Html, Head, Main, NextScript } from "next/document";
import Script from "next/script";

export default function Document() {
  return (
    <Html>
      <Head>
        <Script
          src="/assets/scripts/lang-config.js"
          strategy="beforeInteractive"
        />
        <Script
          src="/assets/scripts/translation.js"
          strategy="beforeInteractive"
        />
        <Script
          src="//translate.google.com/translate_a/element.js?cb=TranslateInit"
          strategy="afterInteractive"
        />
      </Head>
      <body>
        <Main />
        <NextScript />
      </body>
    </Html>
  );
}

The main difference between this file and the default one is a set of three scripts below.

public/assets/scripts/lang-config.js contains custom languages settings
public/assets/scripts/translation.js contains TranslateInit callback function definition that will be used as a parameter to the main translation script
//translate.google.com/translate_a/element.js?cb=TranslateInit - the main translation script by Google. Pay attention on cb=TranslateInit. The callback function must be passed here.

The scripts

It's time to provide the code of the scripts mentioned above.

public/assets/scripts/lang-config.js

window.__GOOGLE_TRANSLATION_CONFIG__ = {
  languages: [
    { title: "English", name: "en" },
    { title: "Deutsch", name: "de" },
    { title: "Español", name: "es" },
    { title: "Français", name: "fr" },
  ],
  defaultLanguage: "en",
};

In this example, we declared four languages to use.

public/assets/scripts/translation.js

function TranslateInit() {
  if (!window.__GOOGLE_TRANSLATION_CONFIG__) {
    return;
  }
  new google.translate.TranslateElement({
    pageLanguage: window.__GOOGLE_TRANSLATION_CONFIG__.defaultLanguage,
  });
}

Here is a callback definition that includes google.translate.TranslateElement call. If we don't have the configuration, we pass it to Google's script nothing i.e. an empty callback. Otherwise, we call google.translate.TranslateElement and pass the original content language.

And it's finally time to provide and explain the most critical part of the solution. I'm talking about the LanguageSwitcher mentioned before.

The LanguageSwitcher component

src/components/lang-switcher.tsx

Please, pay attention to the comments inside the code below.

import { useEffect, useState } from "react";
import { parseCookies, setCookie } from "nookies";

// The following cookie name is important because it's Google-predefined for the translation engine purpose
const COOKIE_NAME = "googtrans";

// We should know a predefined nickname of a language and provide its title (the name for displaying)
interface LanguageDescriptor {
  name: string;
  title: string;
}

// The following definition describes typings for JS-based declarations in public/assets/scripts/lang-config.js
declare global {
  namespace globalThis {
    var __GOOGLE_TRANSLATION_CONFIG__: {
      languages: LanguageDescriptor[];
      defaultLanguage: string;
    };
  }
}

const LanguageSwitcher = () => {
  const [currentLanguage, setCurrentLanguage] = useState<string>();
  const [languageConfig, setLanguageConfig] = useState<any>();

  // When the component has initialized, we must activate the translation engine the following way.
  useEffect(() => {
    // 1. Read the cookie
    const cookies = parseCookies()
    const existingLanguageCookieValue = cookies[COOKIE_NAME];

    let languageValue;
    if (existingLanguageCookieValue) {
      // 2. If the cookie is defined, extract a language nickname from there.
      const sp = existingLanguageCookieValue.split("/");
      if (sp.length > 2) {
        languageValue = sp[2];
      }
    }
    // 3. If __GOOGLE_TRANSLATION_CONFIG__ is defined and we still not decided about languageValue, let's take a current language from the predefined defaultLanguage below.
    if (global.__GOOGLE_TRANSLATION_CONFIG__ && !languageValue) {
      languageValue = global.__GOOGLE_TRANSLATION_CONFIG__.defaultLanguage;
    }
    if (languageValue) {
      // 4. Set the current language if we have a related decision.
      setCurrentLanguage(languageValue);
    }
    // 5. Set the language config.
    if (global.__GOOGLE_TRANSLATION_CONFIG__) {
      setLanguageConfig(global.__GOOGLE_TRANSLATION_CONFIG__);
    }
  }, []);

  // Don't display anything if current language information is unavailable.
  if (!currentLanguage || !languageConfig) {
    return null;
  }

  // The following function switches the current language
  const switchLanguage = (lang: string) => () => {
    // We just need to set the related cookie and reload the page
    // "/auto/" prefix is Google's definition as far as a cookie name
    setCookie(null, COOKIE_NAME, "/auto/" + lang)
    window.location.reload();
  };

  return (
    <div className="text-center notranslate">
      {languageConfig.languages.map((ld: LanguageDescriptor, i: number) => (
        <>
          {currentLanguage === ld.name ||
          (currentLanguage === "auto" &&
            languageConfig.defaultLanguage === ld) ? (
            <span key={`l_s_${ld}`} className="mx-3 text-orange-300">
              {ld.title}
            </span>
          ) : (
            <a
              key={`l_s_${ld}`}
              onClick={switchLanguage(ld.name)}
              className="mx-3 text-blue-300 cursor-pointer hover:underline"
            >
              {ld.title}
            </a>
          )}
        </>
      ))}
    </div>
  );
};

export { LanguageSwitcher, COOKIE_NAME };

Pay attention to notranslate class in the root div before. This is also Google's definition. It means that all of the content inside should not be translated. It's crucial because language titles should stay untouched, i.e., as they are.

Working principles

It's time to gather all the information above and explain how the solution works.

The start point is placed in src/pages/_document.tsx

import { Html, Head, Main, NextScript } from "next/document";
import Script from "next/script";

export default function Document() {
  return (
    <Html>
      <Head>
        <Script
          src="/assets/scripts/lang-config.js"
          strategy="beforeInteractive"
        />
        <Script
          src="/assets/scripts/translation.js"
          strategy="beforeInteractive"
        />
        <Script
          src="//translate.google.com/translate_a/element.js?cb=TranslateInit"
          strategy="afterInteractive"
        />
      </Head>
      <body>
        <Main />
        <NextScript />
      </body>
    </Html>
  );
}

There are three scripts there

The first one contains language configuration
The second one contains a callback with the translation logic runner
Standard Google's script gets the callback described before and runs it.

Pay attention to the following facts.

We use Script tag from next/script because of NextJS ;)
We use strategy="beforeInteractive" for a couple of first scripts
We use strategy="afterInteractive" for the last one

It's important. More information regarding the above you can find here. Let me provide you some related theory.

beforeInteractive: Load the script before any Next.js code and before any page hydration occurs.

afterInteractive: (default) Load the script early but after some hydration on the page occurs.

What happens if the user presses a language on `LanguageSwitcher`?

It's very easy. When the user presses a new language link, say, for Spanish language, switchLanguage function described above sets /auto/es value for googtrans cookie. This is a message to the translation engine that Spain-translated content is expected. After that switchLanguage reloads the page, and we will see the Spanish content. Google Translate did this job!

That's it regarding the main flow. But let me focus on some additional important stuff.

Conclusion

Let's run the solution

npm run dev

and switch the language, say, Deutsch. However, the issue is that the standard Google Translate bar is still on top.

We definitely ought to fix it. Let's add a couple of the following changes to src/styles/globals.css

Much better now!

One of the tastiest features of NextJS is Static Site Generation (SSG). Let's test SSG on this solution.

We need to add ssg script into package.json

  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "ssg": "next build && next export",
    "start": "next start",
    "lint": "next lint"
  },

Let's build a static version.

npm run ssg

> nextjs-gtrans-demo@0.1.0 ssg
> next build && next export

 ✓ Linting and checking validity of types
 ✓ Creating an optimized production build
 ✓ Compiled successfully
 ✓ Collecting page data
 ✓ Generating static pages (3/3)
 ✓ Finalizing page optimization

Route (pages)                              Size     First Load JS
┌ ○ /                                      4.24 kB        82.1 kB
├   /_app                                  0 B            77.9 kB
├ ○ /404                                   181 B            78 kB
└ λ /api/hello                             0 B            77.9 kB
+ First Load JS shared by all              80.1 kB
  ├ chunks/framework-66d32731bdd20e83.js   45.2 kB
  ├ chunks/main-12e9c77dbbe57e7c.js        31.5 kB
  ├ chunks/pages/_app-3cfebadf4e2e7ae1.js  298 B
  ├ chunks/webpack-5c046346608af636.js     807 B
  └ css/24fee595fee43abd.css               2.29 kB

λ  (Server)  server-side renders at runtime (uses getInitialProps or getServerSideProps)
○  (Static)  automatically rendered as static HTML (uses no initial props)
...........
   Copying "public" directory
 ✓ Exporting (3/3)
Export successful. Files written to /Users/slava/Desktop/projects11/nextjs-gtrans-demo/out

You can find the static version in out folder.

Let's test it. If don't have http-server installed, please install it.

npm i -g http-server

cd ./out
http-server

The final solution is here.

May the Google Translate, NextJS, and Force be with you!

The Interview Under the Hood

Vyacheslav Chub — Mon, 04 Sep 2023 09:45:17 +0000

The 10 Commandments of Technical Interviewing

Technical interviewing in the lack of time always looks challenging because, as an interviewer, I mustn't have room for mistakes. Probably not worth mentioning that a "question from a book" is often a false friend. Instead of the original answer, my interviewee could reproduce it mechanically, i.e., read from Wikipedia in the worst case or read before the interview without deep knowledge of the best one. But I'm not a judge. I'm just a searcher for my future colleague to join my team! I'm always trying to deal with a dilemma. The dilemma is that, on the one hand, the technical question should be less well-known because, in the case of a positive answer to the famous question, I can't correctly estimate this answer due to the above. Let's illustrate this case. Imagine you start asking about OOP.
You asked, Please, tell me about the OOP principles? The candidate answered perfectly. What is your conclusion regarding the candidate's knowledge? Are they firm or not? Does the candidate know the topic, or did he/she just read this answer on Wikipedia? Should I proceed with another similar question on this topic? The issue is that you don't have enough time for that. Also, you shouldn't spam the candidate with many such questions or waste time on irrelevant questions. How to fix this situation?

I see only one promising approach. You need to ask indirect, preferably practical, questions instead. In this case, for example, you can ask the following. Does it possible to instantiate an abstract class? And after that, ask some other additional questions. I suppose after answers gathering, you understand the candidate's knowledge.

On the other hand, your "tricky" question should not be so tricky. It's crucial because, imagine, the candidate didn't answer. I want to ask the almost same as above. What is your conclusion regarding the candidate's knowledge? Are they firm or not? Does the candidate know the topic, or was he/she confused due to lack of time and the complexity of the question? Is the question too contextual?

A good interview question is always about the balance between simplicity and complexity, straightforward and contextuality. A good interview looks like art. Please, remember that the form of the question and the estimated answer could be variated due to the expected candidate level. Please, attend to every candidate more comprehensively and evaluate their skills more personally because he/she is possibly your colleague in the nearest future.

The NodeJS Scratch

I want to switch to the most challenging part of this article and illustrate a more complicated case. Imagine you are an interviewer for a NodeJS developer position and need to cover some critical knowledge points.

Let's get started. As a technical interviewer, I prefer to start from the authentic code fragment. Here is the following one.

const p1 = new Promise(resolve => {
  console.log('start first promise', new Date());
  console.time('first');
  for (let i = 0; i < 9999999999; i++) {
  }
  resolve(1);
  console.timeEnd('first');
  console.log('finish first promise', new Date());
});
const p2 = new Promise(resolve => {
  console.log('start second promise', new Date());
  console.time('second');
  setTimeout(() => {
    resolve(2);
    console.timeEnd('second');
    console.log('finish second promise', new Date());
  }, 2000)
});
const p3 = new Promise(resolve => {
  console.log('start third promise', new Date());
  console.time('third');
  setTimeout(() => {
    resolve(3);
    console.timeEnd('third');
    console.log('finish third promise', new Date());
  }, 10000);
});

(async () => {
  const r = await Promise.all([p1, p2, p3]);
  console.log(r);
})();

And here is the result.

start first promise 2023-08-17T11:50:10.064Z
first: 9.444s
finish first promise 2023-08-17T11:50:19.513Z
start second promise 2023-08-17T11:50:19.513Z
start third promise 2023-08-17T11:50:19.514Z
second: 2.002s
finish second promise 2023-08-17T11:50:21.516Z
third: 10.001s
finish third promise 2023-08-17T11:50:29.515Z

I'm not fond of the "interviewer-interviewee" style during our conversation. As I meant before, I'm searching for my future colleague. That's why my first question will be the following. What do you think about the code above? I'm asking this way because I need to know how the interlocutor thinks and what parts of the topic are important to him/her, and depending on the first clues, I'll build my future interview tactics.

And now, it's time for the interview's most creative, exciting, and unpredictable part. Let me provide you with some possible scenarios as dialogs.

Please, read my thoughts under the dialog details carefully. I provided them because I want to reveal the holy of holies of the dialog - my own thoughts! I hope it helps you understand my thinking and related future steps. It's important because there is no "silver bullet" or generic pattern regarding the interview. That's why it's critically important to understand how I think here and adapt it to your practice.

Scenario 1.

Interviewer: What do you think about the code above?

Candidate: Promise.all() static method takes an iterable of promises as input and returns a single Promise. This returned promise fulfills when all of the input's promises fulfill (including when an empty iterable is passed), with an array of the fulfillment values.

Oops N1! Looks like a Wikipedia-based answer.

Interviewer: Do you have nothing more to add?

In this case, I prefer to ask brief, direct questions like the above.

Candidate: No

Oops N2! Really? Are you kidding me? (Remember, it's just a thought in my mind. Please don't say this way in the interview!) There are two explanations for my interviewee's behavior. The first one is a lack of knowledge, and the second one is about we are not on the same page or he/she is hesitating. Let's understand the reason.

Interviewer: Could you explain why the result looks differently from, say, the following?

start first promise ...
start second promise ...
start third promise ...
finish second promise ...
finish first promise ...
finish third promise ...

In other words, I wondered whether my interlocutor could explain why the first promise works synchronously. This proposal above is quite provocative because it contains 100% incorrect flow. This question is the best indicator for understanding the candidate's level. In other words, this is the catharsis of the interview. BTW, I recommend providing the candidate with some error-based code or results. This way is perfect from a technical and psychological point of view at the same time. The best way to unblock the candidate's stuck brain is to discuss incorrect flow. Moreover, after the candidate successfully resolved the issue, he/she became more confident.

Candidate: First, Promises are not regarding multithreading. Second, if we face long-executing synchronous code, then this code will block the whole solution. In this example, the first promise starts and blocks others because the following code

  console.log('start first promise', new Date());
  console.time('first');
  for (let i = 0; i < 9999999999; i++) {
  }
  resolve(1);
  console.timeEnd('first');
  console.log('finish first promise', new Date());

executes by the V8 engine consistently in the time, and no other code in the app can interrupt it internally. Moreover, I want to explain why the last couple of promises run "almost simultaneously." They start after the first one has been resolved. The difference is that a couple last have asynchronous code based on timers. That's why no one from them blocks each other. Also, if we talk about I/O operations like fs.readFile then these operations will be executed in separate threads according to NodeJS architecture. That's why if we have an array of promises only with similar (execution time) asynchronous I/O operations inside, then Promise.all details will be executed almost simultaneously.

Cool! The candidate's mind has been unblocked! It's a pleasure to me cause this kind of situation. The answer above is not academic and is a bit compacted, but it shows me the candidate's level. Additionally, I'd like to ask some questions regarding the history of NodeJS, Event Loop, and LibUV. But it's optional stuff. Generally, I'm satisfied with the answers.

I asked the additional question because the start of the answer looks like a definition from the well-known resource, and as an interviewer, I need to be sure that the candidate's words come from himself. It's important!

Scenario 2.

Interviewer: What do you think about the code above?

Candidate: Well, we shouldn't put such a heavyweight code into a promise like in Promise 1.

I'm skeptical about this way of answering because a bit different question was responded to. I didn't ask, "What should we do?" or "How can we fix it?" Even though the answer looks wise, I need to clarify the topic.

If you get an inappropriate answer such above, please, don't repeat the question or don't tell the candidate that he/he has answered another question. It doesn't work. Believe me! In my mind, it's a bit impolite, and this way can ruin the relationship between your interlocutor and you. It's important even if you are already decided regarding the candidate. Please, be intelligent and polite!

Interviewer: But what happens if we put the "lightweight" code?

Attention! This is a psychological trick. I intentionally ignored the "heavyweight" definition and used the antonym blindly. It's not important now. I need to 100% understand the candidate's way of thinking.

Candidate: I guess the promises will run simultaneously in the case of Promise.all.

Oops N1! I just caused him/her to give me the "real" answer and proceed with this topic.

Interviewer: Could you explain why?

Let's finish this topic. This point is the catharsis of the interview.

Candidate: In my last project, I implemented a similar code like the following, and all promises worked simultaneously.

const p1 = new Promise((resolve, reject) => {
  fs.readFile('./test-1.txt', 'utf8', (err, data) => {
    if (err) {
      reject(err);
      return;
    }
    resolve(data)
  });
});
const p2 = new Promise((resolve, reject) => {
  fs.readFile('./test-2.txt', 'utf8', (err, data) => {
    if (err) {
      reject(err);
      return;
    }
    resolve(data)
  });
});
const p3 = new Promise((resolve, reject) => {
  fs.readFile('./test-3.txt', 'utf8', (err, data) => {
    if (err) {
      reject(err);
      return;
    }
    resolve(data)
  });
});

(async () => {
  const r = await Promise.all([p1, p2, p3]);
  console.log(r);
})();

Let me explain what happens here. The candidate provided a 100% valid code with the correct result. Despite the similarity between this and the original example, the current example has another context. This kind of answer is a good indicator of the issues in the candidate's knowledge. He/she provided this example mechanically due to lacking fundamental skills.

Interviewer: Could you explain why they work "simultaneously"?

Oops N2! I'm generally disappointed about my candidate!

Candidate: Oh, I didn't have a chance to dig deeply. I'm not a theoretical guy. It's a feature of Promise.all, I guess.

Oops N3! I'm always disappointed about this kind of candidate because they spent some time for practice and have been working on real projects for some years. Although, my candidate hasn't become a proper software developer. I'm always so sorry in this kind of situation.

Interviewer: Do you know the difference between fs.readFile and other code, for example, the plain loop (as in my original example), in terms of the code execution?

The last chance! I must be 100% sure the candidate is unfamiliar with the topic.

Candidate: Unfortunately, no:(

I suppose now you understand how a dialog is essential and how important to finish the answer logically. In this case, the candidate started the answer more optimistically than in the previous scenario. But in fact, he doesn't match as a proper developer. The lack of knowledge here is critical, and I'm not satisfied with the answers.

BTW, this kind of candidate is the most "dangerous" because, at first glance, he/she has substantial knowledge, especially practical skills. But gaps in the fundamental skills could cause severe troubles in the company, which will engage the candidate. This is why the interviewing experience in the company is so critical.

The Golang Scratch

At this point, I want to proceed with another example of another technology from a different point of view. I want to share the Golang illustration that allows us to understand how important to count the technological specific during the mandatory question preparation.

Let's consider Golang. As a technical interviewer, I want to start with only one eloquent question covering many sensitive points. It will help me to ask my future questions more effectively. One of the most critical topics in Golang is goroutines and channels. Formally, there are a lot of points on this topic in literature and guides. The team will waste a lot of time in case of brute-force asking. Moreover, in this case, as a technical interviewer, you can estimate only book-based knowledge, not skills! And what about the candidate's nerves?

Let's choose another way. There is the following minimalistic fragment of code.

package main

import "fmt"

func main() {
    messages := make(chan string)

    messages <- "message 1"
    messages <- "message 2"

    fmt.Println(<-messages)
}

Let me provide you with a happy-based scenario.

Interviewer: How could you fix the code above?

Both of us, Gophers, understand that the code above contains a very silly mistake;)

Candidate: There is a deadlock here because, first, we are working on the same thread, and second, the channel above is unbuffered. Let me provide you with the ways to fix it.

The first approach is the simplest one. We need to make the channel buffered.

package main

import "fmt"

func main() {
    messages := make(chan string, 2)

    messages <- "message 1"
    messages <- "message 2"

    fmt.Println(<-messages)
}

Honestly, the original code above is unusual because channel approach usage is a good way to communicate between goroutines. Let me provide a proper way to use them.

package main

import (
    "fmt"
)

func main() {
    c := generator()
    receiver(c)
}

func receiver(c <-chan int) {
    for v := range c {
        fmt.Println(v)
    }
}

func generator() <-chan int {
    c := make(chan int)

    go func() {
        for i := 0; i < 10; i++ {
            c <- i
        }
        close(c)
    }()

    return c
}

Interviewer: Brilliant! Well done.

This question saved the team's time because we partially covered two topics from Golang and got a positive result about the candidate's practical skills.

Are you feeling the difference between the question above and What pros and cons of Golang?

Conclusion

Of course, I provided only a tiny slice of the imaginable interview as an illustration. There are more questions, interactions, and situations in real life. I offered just some of typical. But in any case, your interview should follow the principles below. They could be interesting outside of technical society only. That's why I recommend reading the following to different roles including recruiters, HRs, PMs, etc. But stop, no principles! I'll have the courage and say more...

The 10 Commandments of Technical Interviewing

Prepare for the interview, including plan, code, and questions according to the candidate's CV, position, and specific technology. Please, read the CV before. Imagine your candidate according to the CV and check if your imagination matches your feelings after the interview. 100% of the material should be at hand. It helps you decide what questions need to be taken from the pool. Any preparation during the interview is entirely unacceptable because time is valuable!
Keep the dialog and collaboration. Be on the same page with the candidate. Be sophisticated.
In the case of an unreasonably long answer, don't hesitate to interrupt the candidate politely. Remember, your time and your colleagues` time is valuable!
Follow the plan. Some questions should be mandatory. Your plan is a kind of pilot's checklist. Any diversion could cause a crash in the future.
Remember that practice is the criterion of the truth. Discuss actual code as often as possible.
Creativity and variability. Don't repeat the same questions. Don't discuss the same subject too much. Other topics are valuable too. Change the plan (except for mandatories) on the fly if necessary; your deep knowledge will help you. Remember, you are an expert. Be flexible!
Keep a pure mind and be pragmatic. Your emotions are your enemy. Objectivity is your friend, although you are not a judge. Even a person's poor appearance at first glance tells you nothing regarding his/her IQ/EQ.
Communicate productively with other team members like developers, recruiters, etc. Don't try taking advantage. Give time to your colleagues. Analyze answers to their questions.
Keep all essential points during the interview, even soft skill-related. Don't miss this information during your result-making because you don't know which point will be decisive when the CEO or someone else from superiors makes the final decision. Your goal is to provide as objective as possible information regarding the candidate.
Try to ask about the candidate's fate. Does the company offer him/her? Decline? Why? Does he/she approve the offer? First, because you are a part of the company. Second, this practice will broaden your horizons.

Offtopic! If you want to get pleasure from coding, please read my previous Game-n-Qwik series.

PS: This topic is one of my favorites. I'm fond of interviewing activities and always want to share my knowledge with my colleagues. In my strong opinion, proper staff selection makes our world much much and much better;) That's why I want to proceed with this topic. See you!

Game-n-Qwik. The Final Episode.

Vyacheslav Chub — Fri, 11 Aug 2023 13:22:39 +0000

The Final Stitches.

Congratulations! We are in the final stretch! Let's summarize our previous points.

In Episode 01, I introduced you to the Columns Game history and concept.
Episode 02 is devoted to initial technical points like Bootstrapping, Libraries, and gameplay's first steps.
Episode 03 is the most complicated and exciting. In this episode, we passed all the mandatory steps to get the natural Qwik Columns gameplay.

Despite the above, our current solution still needs to be finished for the reasons below.

A player can set the game on pause.
Move the actor somehow immediately to the bottom of the board. This feature is essential because, in many cases, a player has decided on the final actor's color combination, and the player wants to drop it to the bottom immediately. Moreover, the dropping above is preferable to be animated.
Provide visual controls "Start," "Stop," and "Pause" as a set of buttons.
Provide different customized speeds for the moving actor, like "Slow," "Normal," and "Fast," with related score calculation. Slow speed gives us less score; Fast pace gives us more.
Visual end of the game. Currently, we have only "console.log" when the game has finished.
UI footer, preferably UI responsive.

Traditionally I'll explain all my modifications step by step. My impatient readers can read and run the final working solution.

If you want to trace future steps with me, please use the destination code from the previous episode.

Let's get started!

Gameplay changes

First, let's deal with src/components/game-play/game-logic.ts. Please, read my comments in the code!

Pay attention to the new Phase

export enum Phase {
  INACTIVE,
  // Pause is ON
  PAUSED,
  MOVING,
  // Drop is requested
  DROP,
  // Drop action is under progress
  FLYING,
  MATCH_REQUEST,
  COLLAPSE_REQUEST,
}

and change the main game definition.

export interface Game {
  board: ColumnsColor[][];
  actor: Actor;
  phase: Phase;
  // we need to save our current phase before pause
  savedPhase: Phase;
  nextActor: ColumnsColor[];
  score: number;
  // this is a key/value-based score descriptors
  // key describes type of speed, Slow, Normal, Fast
  // value is a related score extent
  scores: { [key: string]: number };
}

Pass current speed (Level) to matching function. It's needed for score calculation.

export function matching(
  game: Game,
  // new parameter
  level: Level,
  mark: boolean,
  customBoard?: ColumnsColor[][]
) {
  // ...
  function checkCollapsed(match: boolean[][], mark: boolean): boolean {
    let result = false;
    for (let row = 0; row < rowsQty; row++) {
      for (let col = 0; col < columnsQty; col++) {
        if (match[row][col]) {
          if (mark) {
            board[row][col] = colorsToDisappearHash[board[row][col]];
            // calculate the score according to the level
            game.score += game.scores[level];
          }
          result = true;
        }
      }
    }
    return result;
  }

  // ...
  return checkCollapsed(match, mark);
}

isFinish should also know about the level

export function isFinish(game: Game, level: Level): boolean {
  // ...
  if (matching(game, level, false, getNextBoard())) {
    return false;
  }
  // ...
}

Add pause implementation.

export function pause(game: Game) {
  if (game.phase === Phase.PAUSED) {
    game.phase = game.savedPhase;
  } else {
    game.savedPhase = game.phase;
    game.phase = Phase.PAUSED;
  }
}

That's it regarding the gameplay definitions. It's time to focus on src/components/game-play/game.tsx

There are the expected definitions.

// Levels definitions
export enum Level {
  SLOW = "SLOW",
  NORMAL = "NORMAL",
  FAST = "FAST",
}
// Connects levels with the interval speeds in milliseconds
export const SPEEDS = {
  [Level.SLOW]: 1000,
  [Level.NORMAL]: 500,
  [Level.FAST]: 200,
};
// Connects levels with the scores
export const SCORES = {
  [Level.SLOW]: 1,
  [Level.NORMAL]: 2,
  [Level.FAST]: 3,
};

Please, look at the following fragment of code. We need to draw the actor also if the phase is PAUSED and DROP.

There are the following changes in the store

export interface MainStore {
  width: number;
  height: number;
  game: Game;
  blockSize: number;
  // Add the level
  level: Level;
  // We need to control intervalId (start, stop).
  // It's important in the context of Controls (see above).
  intervalId: any | null;
  gameOverPopup: boolean;
}

and related changed for the initial state.

const store = useStore<MainStore>({
  width: 0,
  height: 0,
  game: {
    board: [...initData],
    actor: {
      state: [...initActor],
      column: Math.floor(initData[0].length / 2),
      row: -2,
    },
    // Start from INACTIVE instead MOVING.
    // Now the game is inactive and the user should press Play button.
    phase: Phase.INACTIVE,
    // add this one...
    savedPhase: Phase.INACTIVE,
    nextActor: randomColors(3),
    score: 0,
    scores: SCORES,
  },
  blockSize: 0,
  // initial level will be NORMAL
  level: Level.NORMAL,
  // add this one...
  intervalId: null,
  gameOverPopup: false,
});

An important note regarding Qwik!

At this point, I'd like to interrupt my telling and share one tricky Qwik feature with you. The following information has been taken from the official Qwik documentation.

According to Qwik Deep Objects

export const MyComp = component$(() => {
  const store = useStore({
    person: { first: null, last: null },
    location: null,
  });

  store.location = { street: "main st" };

  return (
    <section>
      <p>
        {store.person.last}, {store.person.first}
      </p>
      <p>{store.location.street}</p>
    </section>
  );
});

In the above examples, Qwik will automatically wrap child objects person and location into a proxy and correctly create subscriptions on all deep properties.

The wrapping behavior described above has one surprising side-effect. Writing and reading from a proxy auto wraps the object, which means that the identity of the object changes. This should normally not be an issue, but it is something that the developer should keep in mind.

export const MyComp = component$(() => {
  const store = useStore({ person: null });
  const person = { first: "John", last: "Smith" };
  store.person = person; // store.person auto wraps object into proxy

  if (store.person !== person) {
    // The consequence of auto wrapping is that the object identity changes.
    console.log("store auto-wrapped person into a proxy");
  }
});

Let's continue and move all core logic to a separate moveTick function. Please, read my comments there. Uncommented logic is the same as in the previous episode.

// Create a separate function
const moveTick = $(() => {
  const game = store.game;

  // Do nothing if the actor is under dropping, I'll explain it below.
  if (game.phase === Phase.FLYING) {
    return;
  }

  if (game.phase === Phase.MOVING) {
    if (isNextMovePossible(game)) {
      actorDown(game);
    } else {
      endActorSession(game);
      // Pass the level.
      if (isFinish(game, store.level)) {
        game.phase = Phase.INACTIVE;
        store.gameOverPopup = true;
      } else {
        game.phase = Phase.MATCH_REQUEST;
      }
    }
    // If the current phase is DROP.
  } else if (game.phase === Phase.DROP) {
    // We actually don't need to change the current state of the game
    // that's why we create a clone of the game
    const gameClone = clone(game);

    // Calculate how many steps should be passed to reach the bottom.
    let steps = 0;
    // Iterate until the next move is possible.
    while (isNextMovePossible(gameClone)) {
      // Move the actor (on the cloned game) one step down.
      actorDown(gameClone);
      // Increase the steps counter
      steps++;
    }
    // Pass the related steps to the "render" function.
    // It causes the DROP animation running. I'll explain it a bit later.
    reRender(steps);
    return;
  } else if (game.phase === Phase.MATCH_REQUEST) {
    // Pass the level
    const matched = matching(game, store.level, true);
    if (matched) {
      game.phase = Phase.COLLAPSE_REQUEST;
    } else {
      doNextActor(game);
      game.phase = Phase.MOVING;
    }
  } else if (game.phase === Phase.COLLAPSE_REQUEST) {
    collapse(game);
    game.phase = Phase.MATCH_REQUEST;
  }

  reRender();
});

Add doDrop function

  const doDrop = $(() => {
    if (store.game.phase === Phase.MOVING) {
      store.game.phase = Phase.DROP;
    }
  });

and add the related keys binding

  useOnDocument(
    "keypress",
    $((event) => {
      const keyEvent = event as KeyboardEvent;
      const { phase } = store.game;
      if (phase !== Phase.MOVING) {
        return;
      }
      if (keyEvent.code === "KeyA") {
      // ...
      } else if (keyEvent.code === "KeyS" || keyEvent.code === "Space") {
        doDrop();
      } 
      // ...
    })
  );

Attention! The part below is the most tricky here. Please, read my comments in the code carefully!

It's time to focus on modifications in reRender and render functions.

// Just added steps as an optional parameter.
const reRender = $((steps?: number) => {
  render(store.game, svgRef, store.width, store.height, store.blockSize, steps);
});

export function render(
  game: Game,
  svgRef: Signal<Element | undefined>,
  width: number,
  height: number,
  blockSize: number,
  // New parameter
  passThroughSteps?: number
) {
  // ...
  // Also, render the actor if the current phase is PAUSED or DROP
  if (
    game.phase === Phase.MOVING ||
    game.phase === Phase.PAUSED ||
    game.phase === Phase.DROP
  ) {
    // ...
    svg
      .selectAll()
      .data(actorData)
      .enter()
      .append("g")
      .append("rect")
      // All shapes related to the actor should have "could-fly" class.
      // This class is a fake one and we use it for future animation
      .attr("class", "could-fly")
      // ...
      .attr("stroke-width", 1);

    // We need to run "flying" process if passThroughSteps is existing
    if (passThroughSteps) {
      // Set the phase.
      // Now "flying process" will be simultaneous with the current interval,
      // but the current interval's handler will ignore any activity;
      // see the code under the following comment: "if the current phase is DROP"
      game.phase = Phase.FLYING;

      // This is a good example of D3 animation.
      svg
        // We need to select all shapes includes "could-fly" fake class (the whole actor)
        .selectAll(".could-fly")
        // Run animation.
        // Pay attention! This process is asynchronous!
        .transition()
        // with 700ms duration
        .duration(700)
        // This aim of animation is moving the current actor
        // to the Y-axis destination that equals
        // current actor's Y + passThroughSteps * blockSize.
        .attr("y", (d: any) => d.y + passThroughSteps * blockSize)
        // don't mix with on('end', ...); it doesn't work in this case (D3 feature)
        .end()
        .then(() => {
          // change the state of the game
          // when asynchronous animation process has been finished
          // move the actor down passThroughSteps for the current game
          actorDown(game, passThroughSteps);
          // let's move!
          game.phase = Phase.MOVING;
        });
    }
  }
}

Let's briefly repeat the DROP animation concept.

If the DROP action happens, we need to calculate how many steps the actor should fly (animation distance) to reach the bottom.
Set the current phase to FLYING.
Run animation when Y axis destination (vertical) of the actor equals current actor's Y + passThroughSteps * blockSize
Wait for the end of the animation and move the actor down passThroughSteps
Set the phase back to MOVING

That's it about DROP.

useVisibleTask$ became much simpler because we moved all of the logic there to moveTick function above!

useVisibleTask$(({ cleanup }: { cleanup: Function }) => {
  setSvgDimension(containerRef, store);
  // create the interval an save it in the store
  // because we should be able to control this interval outside useVisibleTask$
  // SPEEDS[store.level] describes the current game speed by the level
  store.intervalId = setInterval(moveTick, SPEEDS[store.level]);
  cleanup(() => clearInterval(store.intervalId));
});

Some notes regarding the end of the game.

useTask$(({ track }: { track: Function }) => {
  track(() => store.gameOverPopup);

  // track gameOverPopup, if it fires then hide it (the related popup) after 5 seconds
  if (store.gameOverPopup) {
    setTimeout(() => {
      store.gameOverPopup = false;
    }, 5000);
  }
});

Please, also, look at the related UI part of the code. The HTML block appears only if store.gameOverPopup is true. I guess, React guys should be familiar with this technique.

{
  store.gameOverPopup && (
    <div class="fixed top-1/2 left-1/2 -translate-y-1/2 -translate-x-1/2 z-50 w-72 text-center max-w-sm p-6 bg-white text-white border border-gray-200 rounded-lg shadow dark:bg-gray-800 dark:border-gray-700 z-50">
      GAME OVER
    </div>
  );
}

The time finally came, and I'm glad to provide the way how to use Controls components. Don't worry. I'll focus on the component's details a bit later.

<Controls
  game={store.game}
  blockSize={15}
  level={store.level}
  onStart$={() => {
    // start the game
    init(store.game);
    store.gameOverPopup = false;
    store.game.phase = Phase.MOVING;
  }}
  onPause$={() => {
    // pause the game
    pause(store.game);
  }}
  onStop$={() => {
    // stop the game
    store.game.phase = Phase.INACTIVE;
    store.gameOverPopup = true;
  }}
  // and also pass other activities
  onLeft$={doLeft}
  onRight$={doRight}
  onSwap$={doSwap}
  onDrop$={doDrop}
  // including the level switching
  onLevel$={(level: Level) => {
    // update the level
    store.level = level;
    // clear the current interval if it's exists
    if (store.intervalId !== null) {
      clearInterval(store.intervalId);
    }
    // re-create the interval
    store.intervalId = setInterval(moveTick, SPEEDS[store.level]);
  }}
/>

Here is Controls component.

import type { PropFunction, Signal } from "@builder.io/qwik";
import { useSignal } from "@builder.io/qwik";
import { component$ } from "@builder.io/qwik";
import * as d3 from "d3";
import type { Game } from "./game-logic";
import { Phase } from "./game-logic";
import { Level } from "./game";

interface ControlsProps {
  game: Game;
  onStart$: PropFunction<() => void>;
  onPause$: PropFunction<() => void>;
  onStop$: PropFunction<() => void>;
  onLeft$: PropFunction<() => void>;
  onRight$: PropFunction<() => void>;
  onSwap$: PropFunction<() => void>;
  onDrop$: PropFunction<() => void>;
  onLevel$: PropFunction<(level: Level) => void>;
  blockSize: number;
  level: Level;
}

// This function is responsible for the "next actor" rendering
export function renderNextActor(
  data: string[],
  size: number,
  svgRef: Signal<Element | undefined>
) {
  // this logic is similar to the logic from
  // https://github.com/buchslava/qwik-columns/blob/final-devto-edition/src/components/game-play/game.tsx#L56
  if (!svgRef.value) {
    return;
  }
  const svg = d3.select(svgRef.value);

  svg.selectAll("*").remove();

  svg
    .append("svg")
    .attr("width", size)
    .attr("height", size * data.length)
    .append("g")
    .attr("transform", "translate(0,0)");

  const displayData = data.map((d, i) => ({
    value: d,
    y: i * size,
    size,
  }));

  svg
    .selectAll()
    .data(displayData)
    .enter()
    .append("g")
    .append("rect")
    .attr("x", 0)
    .attr("width", (d) => d.size)
    .attr("y", (d) => d.y)
    .attr("height", (d) => d.size)
    // @ts-ignore
    .attr("fill", (d) => d3.color(d.value))
    .attr("stroke", "#000000")
    .attr("stroke-width", 1);
}

export default component$<ControlsProps>(
  ({
    onStart$,
    onPause$,
    onStop$,
    onLeft$,
    onRight$,
    onSwap$,
    onDrop$,
    onLevel$,
    game,
    blockSize,
    level,
  }) => {
    const svgRef = useSignal<Element>();

    // run next actor rendering
    renderNextActor(game.nextActor, blockSize, svgRef);

    return (
      <div class="relative text-white w-72 h-48">
        <div class="pl-3 inset-x-0 top-0">
          <div class="mb-5 text-base lg:text-2xl md:text-xl font-extrabold font-mono">
            SCORE: {game.score}
          </div>
          <div class="mb-5">
            <div class="bg-white w-32 pt-2 pb-2 flex justify-center">
              // this is a SVG for the next actor rendering
              <svg
                width={blockSize}
                height={blockSize * game.nextActor.length}
                ref={svgRef}
              />
            </div>
          </div>
          // We need to show "Start" button only if the phase is INACTIVE
          {game.phase === Phase.INACTIVE && (
            <div class="mb-5">
              <button
                // use the passed (input property) function
                onClick$={onStart$}
                type="button"
                class="font-mono px-8 py-3 w-32 text-white bg-pink-300 rounded focus:outline-none"
              >
                START
              </button>
            </div>
          )}
          // We need to show "Stop" and "Pause" button only if the phase is NOT
          INACTIVE
          {game.phase !== Phase.INACTIVE && (
            <div class="mb-5">
              <button
                // use the passed (input property) function
                onClick$={onPause$}
                type="button"
                class="font-mono px-8 py-3 w-32 text-white bg-blue-300 rounded focus:outline-none"
              >
                {game.phase === Phase.PAUSED ? "GO" : "PAUSE"}
              </button>
            </div>
          )}
          {game.phase !== Phase.INACTIVE && (
            <div class="mb-5">
              <button
                // use the passed (input property) function
                onClick$={onStop$}
                type="button"
                class="font-mono px-8 py-3 w-32 text-white bg-gray-300 rounded focus:outline-none"
              >
                STOP
              </button>
            </div>
          )}
        </div>
        <div class="pl-3 mb-5 flex w-36 justify-between">
          // 1-st Slow level
          <button
            onClick$={() => {
              // pass SLOW to the function in the parent component
              onLevel$(Level.SLOW);
            }}
            type="button"
            // we use dynamic class with Tailwind-based classes to highlight the current level
            class={[
              "w-10 py-3 text-white rounded focus:outline-none",
              level === Level.SLOW ? "bg-green-700" : "bg-yellow-500",
            ]}
            disabled={level === Level.SLOW}
          >
            1
          </button>
          // 2-nd Normal level
          <button
            onClick$={() => {
              // pass NORMAL to the function in the parent component
              onLevel$(Level.NORMAL);
            }}
            type="button"
            class={[
              "w-10 py-3 text-white rounded focus:outline-none",
              level === Level.NORMAL ? "bg-green-700" : "bg-yellow-500",
            ]}
            disabled={level === Level.NORMAL}
          >
            2
          </button>
          // 3-rd Fast level
          <button
            onClick$={() => {
              // pass FAST to the function in the parent component
              onLevel$(Level.FAST);
            }}
            type="button"
            class={[
              "w-10 py-3 text-white rounded focus:outline-none",
              level === Level.FAST ? "bg-green-700" : "bg-yellow-500",
            ]}
            disabled={level === Level.FAST}
          >
            3
          </button>
        </div>
        // Display other control buttons if the phase is NOT INACTIVE
        {game.phase !== Phase.INACTIVE && (
          <div class="pl-3 grid grid-rows-3 grid-cols-2 gap-4">
            // Swap the actor colors (alternative "W" key)
            <div class="col-span-2">
              <button
                onClick$={onSwap$}
                type="button"
                class="text-2xl py-3 w-32 text-white bg-gray-400 rounded focus:outline-none"
              >
                W
              </button>
            </div>
            // Move the actor left (alternative "A" key)
            <div class="w-32 grid grid-flow-col justify-stretch">
              <button
                onClick$={onLeft$}
                type="button"
                class="text-2xl mr-2 py-3 text-white bg-green-300 rounded focus:outline-none"
              >
                A
              </button>
              // Move the actor right (alternative "D" key)
              <button
                onClick$={onRight$}
                type="button"
                class="text-2xl ml-2 py-3 text-white bg-green-300 rounded focus:outline-none"
              >
                D
              </button>
            </div>
            // Drop the actor (alternative "W" key)
            <div class="col-span-2">
              <button
                onClick$={onDrop$}
                type="button"
                class="text-2xl py-3 w-32 text-white bg-gray-400 rounded focus:outline-none"
              >
                S
              </button>
            </div>
          </div>
        )}
      </div>
    );
  }
);

The Footer

Finally, lets make the last stitch. We need to set the footer.

return (
  <div class="flex justify-center w-screen h-screen pt-5" ref={containerRef}>
    {store.gameOverPopup && (
      <div class="fixed top-1/2 left-1/2 -translate-y-1/2 -translate-x-1/2 z-50 w-72 text-center max-w-sm p-6 bg-white text-white border border-gray-200 rounded-lg shadow dark:bg-gray-800 dark:border-gray-700 z-50">
        GAME OVER
      </div>
    )}
    <div>
      <svg
        class="game-area"
        width={store.width}
        height={store.height}
        ref={svgRef}
      />
    </div>
    <Controls
    // ...
    />
    <Footer />
  </div>
);

Here the component's code.

import { component$ } from "@builder.io/qwik";

export default component$(() => {
  // The year of copyright should be dynamic.
  const year = new Date().getFullYear();

  return (
    <div class="fixed bottom-0 left-0 w-full h-8 text-center text-white bg-gray-600">
      // see my comment below
      <span class="hidden lg:inline">
        <span class="text-red-500 font-bold font-mono text-xl pr-2">C</span>
        <span class="text-yellow-500 font-bold font-mono text-xl pr-2">O</span>
        <span class="text-green-500 font-bold font-mono text-xl pr-2">L</span>
        <span class="text-blue-500 font-bold font-mono text-xl pr-2">U</span>
        <span class="text-teal-500 font-bold font-mono text-xl pr-2">M</span>
        <span class="text-fuchsia-500 font-bold font-mono text-xl pr-2">N</span>
        <span class="text-lime-500 font-bold font-mono text-xl pr-7">S</span>
      </span>
      <span class="text-sm text-white">
        <a
          href="https://valor-software.com/"
          class="no-underline hover:underline"
          target="_blank"
        >
          Valor Software
        </a>{" "}
        edition. (C) {year},{" "}
        <a
          href="https://dev.to/buchslava"
          class="no-underline hover:underline"
          target="_blank"
        >
          Vyacheslav Chub
        </a>
      </span>
    </div>
  );
});

Tailwind classes `hidden lg:inline' there means that we show "C O L U M N S" spans only on large screens. You can gain more knowledge on Tailwind Responsive Design here.

It's time to summarize our decisions!

git clone git@github.com:buchslava/qwik-columns.git cd qwik-columns git checkout final-devto-edition npm ci npm start

Start the game. Switch the speed

Core controls

The end of the game

The responsive footer

Enjoy the source
Enjoy the game

... and happy coding ;)

PS: During the game implementation, I got pleasure every moment I faced Qwik functionality and documentation. That's why I want to thank Builder.io for the perfect solution!

Game-n-Qwik. Episode 03.

Vyacheslav Chub — Fri, 11 Aug 2023 13:19:40 +0000

Make it a pure game! The main changes.

I'm glad to see you in Game-n-Qwik Episode 03. I appreciate your patience! In the past episode, I explained what steps we should pass before implementing actual gameplay. I want to highlight some critical steps we passed there.

Bootstrapping. Qwik. Tailwind. D3.
First scratches regarding gameplay.

Just to be sure that we are on the same page now, I'd like to recommend returning to the source of the last episode, running it, and reading the explanation.

In a nutshell, we stopped at a simple example with a big white canvas and a red square that moves down. Also, the user can move it left and right via the keyboard. This example allows us to move forward. Please use this source if you want to pass all future steps manually. For my impatient audience, I'd like to provide the final version of this episode's code.

Let's move forward. Our aim, for now, is to provide the game's basic functionality. Traditionally, I'll give the code before and comment afterward.

The Screen Management

First, let's change src/components/game-play/utils.ts to...

import type { Signal } from "@builder.io/qwik";
import type { MainStore } from "./game";

export function setSvgDimension(
  svgRef: Signal<Element | undefined>,
  store: MainStore
) {
  if (svgRef?.value) {
    const { height } = svgRef.value.getBoundingClientRect();
    const rows = store.game.board.length;
    const columns = store.game.board[0].length;

    const newHeight = (height * 5) / 6;
    const blockSize = newHeight / rows;
    const newWidth = blockSize * columns;

    store.width = newWidth;
    store.height = newHeight;
    store.blockSize = blockSize;
  }
}

In the last version of the game, board dimensions were equal to the root component's dimensions. In this case, we need to provide trickier logic.

The height of the game's canvas should be 5/6 of the root height

const newHeight = (height * 5) / 6;

The width should relate to height and the horizontal number of the board's cells. That's why we must detect the cell size using the following formula.

const blockSize = newHeight / rows;

One note regarding the board's grid. As I explained in Episode 01, the game is represented by a grid-based canvas. Of course, the main attributes of each grid are rows and columns numbers. You can look at the initial state of the grid here

export const COLOR_WHITE = "#ffffff";

const w = COLOR_WHITE;
// .......
export const initData: ColumnsColor[][] = [
  [w, w, w, w, w, w, w],
  // .......
  [w, w, w, w, w, w, w],
];

According to the above information, we can calculate our columns and rows quantities using the following formulas.

const columnsQty = initData[0].length;
const rowsQty = initData.length;

const columnsQty = board[0].length;
const rowsQty = board.length;

This is a good example.

And calculate the width.

const newWidth = blockSize * columns;

And finally, we can update the Qwik store. I'll focus on it a bit later.

store.width = newWidth;
store.height = newHeight;
store.blockSize = blockSize;

That's it for setSvgDimension.

The most important and complicated part of the game is [https://github.com/buchslava/qwik-columns/blob/step-2/src/components/game-play/game-logic.ts]. I'll break my tradition and ask you to put this file as it is to src/components/game-play without the source code provided. Also, I want to explain only some of the code because the all-code explanation will be too dull. You can dig into this outside this alone. The reason is quite simple. This file contains all of the logic details. Despite that, I'll provide you with all exported functions and explain what they do because they are used in our Qwik part.

The Phase

One of the basic definitions regarding gameplay is a Phase. The thing is that each game is a process that has one state per time. The following enum describes all possible states of our Columns. Please, read carefully the comments in the code below.

export enum Phase {
  INACTIVE, // Has not started or stopped
  PAUSED, // On pause
  MOVING, // An actor moves down
  MATCH_REQUEST, // Checking process, see Episode 01
  COLLAPSE_REQUEST, // Calls collapsing process after checking, see Episode 01
}

The Actor

The second important definition is regarding the Actor. Please, read carefully the comments in the code below.

export interface Actor {
  state: ColumnsColor[]; // The actor's state is represented by 3 colored cells
  column: number; // Actor's horizontal position
  row: number; // Actor's vertical position
}

The Main Definition

The third and most important definition is the Game. The following interface describes all information about our Columns. Please, read carefully the comments in the code below.

export interface Game {
  board: ColumnsColor[][]; // Current board state as a two-dimensional array (horizontal x vertical)
  actor: Actor; // The actor; described above
  phase: Phase; // Current phase; described above
  nextActor: ColumnsColor[]; // We also need to display the next actor that's why we define it here
  score: number; // Current score as a number
}

Exports

I'd like to recommend you refresh your knowledge about the gameplay before you browse the following table. Please, look through Episode 01.

The following calculations as a set of functions are directly related to the gameplay.

The name of the function	Purpose
matching	Conducts checking process
collapse	Conducts collapsing process
isNextMovePossible	Answers, if the next actor's moving down possible?
endActorSession	Finalizes current actor's moving down if it's impossible due to `isNextMovePossible` above
isFinish	Checks, is the game finished?
swapActorColors	Swaps colors in the actor
init	Init a new game; resets a state of the game.
isActorEmpty	Answers is the actor empty?
isNextActorInit	Answers, is the next actor colored?
randomColors	Provides an array of random colors
doNextActor	Bumps the new actor's state due to the next one and init the new next state after that.
actorDown	Moves the actor down
moveLeft	Moves the actor one cell left
moveLeftTo	Moves the actor N cells left
moveRight	Moves the actor one cell right
moveRightTo	Moves the actor N cells right

Please, don’t be scared by the list above. We will use all these functions, and I'll describe how exactly.

And now, I'm happy to give you the most exciting part of the code when we gather all previous knowledge: I've grouped all of them into the following features.

The store.
Gameplay utilization functions.
The heart of the game.

All our future activities will be around the source of the game 1. The related destination is placed in the source of the game 2. All my future reasonings will reveal the source of the game transformation from state 1 to 2.

Let's get started!

The store

Let's focus on the store definition.

export interface MainStore {
  // Canvas width
  width: number;
  // Canvas height
  height: number;
  // We should keep the current state of the game. See "The Main Definition" above.
  game: Game;
  // We need to keep the size of the cell because if relates to the screen size
  blockSize: number;
  // The following field is an indicator of the finished game. I'll focus on it a bit later.
  gameOverPopup: boolean;
}

And now, we are ready for the store initialization. I hope it helps you ultimately understand the declarative part of the game.

const store = useStore<MainStore>({
  // Initially, we don't know about the screen dimensions
  width: 0,
  height: 0,
  // The initial state of the game
  game: {
    // The current board should be a clone of initData
    board: [...initData],
    actor: {
      // The current actor should be a clone of initActor
      state: [...initActor],
      // start actor's column (horizontal position) should be ±at the middle of the canvas
      column: Math.floor(initData[0].length / 2),
      // start actor's row (vertical position) should be outside the canvas
      row: -2,
    },
    // Let's set Phase.MOVING
    phase: Phase.MOVING,
    // Set "nextActor" as a randomly generated
    nextActor: randomColors(3),
    score: 0,
  },
  // Initially, we don't know about the screen dimensions that's why blockSize = 0
  blockSize: 0,
  // The game is not over yet
  gameOverPopup: false,
});

Gameplay utilization functions

Let me introduce you to the "workhorse" of the game. The feature is that all UI stuff here is encapsulated in one function. Please, look at the render function and read carefully the comments there.

export function render(
  game: Game, // pass the state of the game; I'll focus on it a bit later
  svgRef: Signal<Element | undefined>, // we also need the SVG representation
  width: number, // tha shapes; see also "setSvgDimension"
  height: number,
  blockSize: number
) {
  if (!svgRef.value) {
    return;
  }

  // Associate our SVG with D3; read also, https://github.com/d3/d3-selection
  const svg = d3.select(svgRef.value);
  // Remove all existing content from the SVG if it present.
  // The reason is that all render calls should fully refresh the screen
  svg.selectAll("*").remove();
  // Append the root SVG element
  svg
    .append("svg")
    .attr("width", width)
    .attr("height", height)
    .append("g")
    .attr("transform", "translate(0,0)");
  // Draw a white rectangle over ALL canvas
  svg
    .append("g")
    .append("rect")
    .attr("x", 0)
    .attr("width", width)
    .attr("y", 0)
    .attr("height", height)
    // @ts-ignore
    .attr("fill", () => d3.color(COLOR_WHITE));

  // Prepare board cells data by the game state (board).
  // The data is represented by an array of objects.
  // Each object contains
  // x (horizontal coordinate of the cell),
  // y (vertical coordinate of the cell)
  // value - cell's color
  const data = [];
  for (let i = 0, x = 0, y = 0; i < game.board.length; i++) {
    x = 0;
    for (let j = 0; j < game.board[i].length; j++) {
      data.push({ x, y, value: game.board[i][j] });
      x += blockSize;
    }
    y += blockSize;
  }

  // Draw the current board
  svg
    .selectAll()
    // Data binding allows us to draw each cell of the board
    // It's a kind of declarative loop.
    .data(data.filter((d) => d.value !== COLOR_WHITE))
    .enter()
    .append("g")
    .append("rect")
    // x is taken from the data; see data preparation above
    .attr("x", (d) => d.x)
    .attr("width", blockSize)
    // y is taken from the data; see data preparation above
    .attr("y", (d) => d.y)
    .attr("height", blockSize)
    // color/value is taken from the data; see data preparation above
    // it represented by a hex value as a string and finally
    // it should be transformed to the D3 compatible color: "d3.color(d.value)"
    // @ts-ignore
    .attr("fill", (d) => d3.color(d.value))
    .attr("stroke", "#000000")
    .attr("stroke-width", 1);

  // We need to draw an actor only the actor should be moving (Phase.MOVING)
  if (game.phase === Phase.MOVING) {
    // Actor data preparation
    const actorData = [];
    for (let i = 0; i < game.actor.state.length; i++) {
      actorData.push({
        x: game.actor.column * blockSize,
        y: (game.actor.row + i - 1) * blockSize,
        value: game.actor.state[i],
      });
    }

    // Draw the actor according to the data above
    // similarly to "Draw the current board" above
    svg
      .selectAll()
      .data(actorData)
      .enter()
      .append("g")
      .append("rect")
      .attr("class", "could-fly")
      .attr("x", (d) => d.x)
      .attr("width", blockSize)
      .attr("y", (d) => d.y)
      .attr("height", blockSize)
      // @ts-ignore
      .attr("fill", (d) => d3.color(d.value))
      .attr("stroke", "#000000")
      .attr("stroke-width", 1);
  }
}

The following functions are responsible for the user's actions.

//  Just call the render
const reRender = $(() => {
  render(store.game, svgRef, store.width, store.height, store.blockSize);
});
// Move left action handler
const doLeft = $(() => {
  // if the actor is moving then call "moveLeft" (see Exports above) and re-render
  if (store.game.phase === Phase.MOVING) {
    moveLeft(store.game);
    reRender();
  }
});
// Move right action handler
const doRight = $(() => {
  // if the actor is moving then call "moveRight" (see Exports above) and re-render
  if (store.game.phase === Phase.MOVING) {
    moveRight(store.game);
    reRender();
  }
});
// Swap colors in the actor action handler
const doSwap = $(() => {
  if (store.game.phase === Phase.MOVING) {
    // if the actor is moving then call "swapActorColors" (see Exports above) and re-render
    swapActorColors(store.game);
    reRender();
  }
});

An important note regarding Qwik

I suppose you just noticed that the functions above are wrapped by $(). It could look weird for a non-Qwik guy. I want to explain the reason for $() usage because it's essential if you want to understand the most essential part of Qwik.

Let's remove $() from, say, reRender and run the app... We will see the error below.

const reRender = () => {
  render(store.game, svgRef, store.width, store.height, store.blockSize);
};

Captured variable in the closure can not be serialized because it's a function named "reRender". You might need to convert it to a QRL using $(fn):

const reRender = $(()=>{

        render(store.game, svgRef, store.width, store.height, store.blockSize);
    });

Please check out https://qwik.builder.io/docs/advanced/qrl/ for more information.

If we refactor the function above the following way

function reRender() {
  render(store.game, svgRef, store.width, store.height, store.blockSize);
}

then we also get an error.

Seems like you are referencing "reRender" inside a different scope ($), when this happens, Qwik needs to serialize the value, however it is a function, which is not serializable.
Did you mean to wrap it in `$()`?

The cause of the errors above is Qwik architecture. The fact is that Qwik is uniquely focused on performance, and I'd like to recommend that you dig into the QRL idea.

QRL (Qwik URL) is a particular form of URL that Qwik uses to lazy load content.

In this context, I recommend you read the following brief but eloquent explanations of Qwik fundamentals.

In short, we must wrap our functions by $() to make them Qwik-friendly!

The heart of the game.

Let's dig into the heart of the game. I used a heart as allegory because our game looks like a living thing. In our case, we are talking about a 700-millisecond interval that keeps the gameplay. I intentionally don't want to write comments in the code because it does not need extra explanations. Just read and enjoy it!

useVisibleTask$(({ cleanup }: { cleanup: Function }) => {
  setSvgDimension(containerRef, store);
  const intervalId = setInterval(() => {
    const game = store.game;

    if (game.phase === Phase.MOVING) {
      if (isNextMovePossible(game)) {
        actorDown(game);
      } else {
        endActorSession(game);
        if (isFinish(game)) {
          game.phase = Phase.INACTIVE;
          store.gameOverPopup = true;
        } else {
          game.phase = Phase.MATCH_REQUEST;
        }
      }
    } else if (game.phase === Phase.MATCH_REQUEST) {
      const matched = matching(game, true);
      if (matched) {
        game.phase = Phase.COLLAPSE_REQUEST;
      } else {
        doNextActor(game);
        game.phase = Phase.MOVING;
      }
    } else if (game.phase === Phase.COLLAPSE_REQUEST) {
      collapse(game);
      game.phase = Phase.MATCH_REQUEST;
    }

    reRender();
  }, 700);
  cleanup(() => clearInterval(intervalId));
});

And finally, there is a small stitch regarding the finished game criteria.

useTask$(({ track }: { track: Function }) => {
  track(() => store.gameOverPopup);

  if (store.gameOverPopup) {
    console.log("Game Over!");
  }
});

We need to track the gameOverPopup field and inform the user. Please, don't worry about console.log. We will deal with it in the next episode.

What's next?

I hope this episode was exciting despite its size ;) Feel free to read and run the related solution.

Are you worrying about the situations when you decide about the actor's colors and need to move the actor somehow immediately to the bottom of the board? What about controls like "Start," "Stop," and "Pause"? What about the score and the speed of the actor's movement?

I'm going to reveal these points in the next episode. Stay in touch!

Game-n-Qwik. Episode 02.

Vyacheslav Chub — Fri, 11 Aug 2023 13:16:30 +0000

The First Scratches.

I introduced you to the general Columns Game idea in the previous episode. And now, it's time to move forward. This episode will explain how to start the game implementation on Qwik. The first steps will include the following points.

Bootstrapping.
The first steps in gameplay.

But before, I want to speculate a bit regarding the Web implementation of an Arcade Game and focus on one strategic topic. First, we must understand what issues to consider to implement the game successfully. They are the following:

Library or Framework. In this case, we talk about Qwik, as I explained in Episode 01.
We need to choose an approach for graphical objects drawing. Of course, we can use a pure HTML canvas-based approach. But let's not reinvent the wheel; let's wear it out.
It is also essential to determine which CSS framework we will use. In my mind, pure CSS usage is also not a good idea for the reason explained in the previous point.

It's time to start our implementation with the points above covering.

Bootstrapping.

I recommend Getting Started Qwikly before we start.

Please, run

npx npm create qwik@latest

and answer the following questions as:

Where would you like to create your new project?

./qwik-columns

Select a starter

Basic App

Would you like to install npm dependencies?

Yes

Initialize a new git repository?

Yes or No, it's your choice...

Congratulations! We just successfully started bootstrapping.

cd qwik-columns

Let's return to the points above regarding Graphical Drawing and CSS.

Before the first serious facing with D3, I thought this beautiful library was just about charts. But as far as I implemented different custom charts, I found this is a delusion. One of the main pros of D3 is its universality. In the following episodes, I'll prove it! Together we will implement the game via D3!

Currently, I don't see any alternative to the D3 drawing approach because:

It has powerful shape-drawing tools and color management.
D3 is about vector graphics; also, this library is animation-friendly.
It allows associating (or binding) data to the graphical representation.
It has a lot of patterns, like different, even tricky chart types.
D3 is well-documented and has a vast community.

Let's install D3 dependencies.

npm i d3 --save

Also, we need to install expected typings.

npm i @types/d3 --save-dev

Let's switch to CSS issue.

The relationships between me and CSS are very pragmatic because I'm a full-stack guy and always don't have much time for sophisticated dancing with CSS. Of course, I understand and respect the beauty of BEM and some other methodologies. But I'm simultaneously thinking about architecture and design, the beauty of JS, TS, Go, Rust code, DB structure, etc. Moreover, some existing CSS-based implementations make me suffer and waste my time. A good example is Node-sass and Node-gyp Errors. That's why I expect something powerful, easy, and lightweight. According to the following points, I think Tailwindcss is the best choice.

Control Over Styling
Faster CSS Styling Process
Responsiveness and Security
Additional Features. Tailwind CSS works in the front end of a website. For this reason, it is reasonable for developers to demand ultimate responsiveness. Well, Tailwind provides the ability to create responsive themes for your web applications and remove all unused CSS classes. With PurgeCSS, Tailwind helps you keep your final CSS as small as possible.

Of course, it has some cons.

Styling and HTML are Mixed
Lack of Important Components
It Takes Time to Learn

Let's analyze them. The first couple is only relevant when considering big or even enterprise projects. In that case, we could think about another framework. Regarding the third point, I agree only partially because Tailwind is well-documented, and you can also find many examples and valuable existing approaches. Our current project is not so large, and we can 100% use Tailwind which keeps our time and nervousness.

Fortunately, Qwik is super friendly with Tailwind!

Please, follow this documentation.

Let's do it.

npm run qwik add tailwind

Answer "Yes." That's it. Feel free to use Tailwind in the project!

The first steps in Gameplay.

It's time to think about our first steps regarding gameplay. I want to take my time with this and pass it through the following steps.

Make a working canvas.
Implement an elementary moving shape, say, a square.
Make the shape above also movable via keyboard events.

These steps will efficiently introduce you to the future tricky gameplay.

Create a new folder: src/components/game-play

Put utils.ts there.

import type { Signal } from "@builder.io/qwik";
import type { MainStore } from "./game";

export function setSvgDimension(
  svgRef: Signal<Element | undefined>,
  store: MainStore
) {
  if (svgRef?.value) {
    const { width, height } = svgRef.value.getBoundingClientRect();

    store.width = width;
    store.height = height;
  }
}

The main goal of setSvgDimensionis to set keep width and height of a component in the Qwik store. The component is represented by svgRef as a Qwik Signal. Please, look at a couple of links above if Qwik is something new to you.

Put the following content into src/routes/index.tsx

import { component$ } from "@builder.io/qwik";
import Game from "../components/game-play/game";

export default component$(() => {
  return <Game />;
});

Remove src/components/starter folder. Also, remove all files except src/routes/index.tsx from src/routes/. And finally, put game.tsx file into src/components/game-play.

game.tsx

import type { Signal } from "@builder.io/qwik";
import { useVisibleTask$ } from "@builder.io/qwik";
import {
  component$,
  useStore,
  useSignal,
  useOnDocument,
  useOnWindow,
  $,
} from "@builder.io/qwik";
import * as d3 from "d3";
import { setSvgDimension } from "./utils";

export function render(
  svgRef: Signal<Element | undefined>,
  width: number,
  height: number,
  x: number,
  y: number
) {
  if (!svgRef.value) {
    return;
  }

  const svg = d3.select(svgRef.value);
  svg.selectAll("*").remove();
  svg
    .append("svg")
    .attr("width", width)
    .attr("height", height)
    .append("g")
    .attr("transform", "translate(0,0)");

  svg
    .append("g")
    .append("rect")
    .attr("x", 0)
    .attr("width", width)
    .attr("y", 0)
    .attr("height", height)
    // @ts-ignore
    .attr("fill", () => d3.color("#ffffff"));

  const data = [{ x, y }];

  svg
    .selectAll()
    .data(data)
    .enter()
    .append("g")
    .append("rect")
    .attr("x", (d) => d.x)
    .attr("width", 15)
    .attr("y", (d) => d.y)
    .attr("height", 15)
    // @ts-ignore
    .attr("fill", () => d3.color("#ff0000"));
}

export interface MainStore {
  width: number;
  height: number;
  horPos: number;
  vertPos: number;
}

export default component$(() => {
  const store = useStore<MainStore>({
    width: 0,
    height: 0,
    horPos: 200,
    vertPos: 0,
  });
  const containerRef = useSignal<Element>();
  const svgRef = useSignal<Element>();

  useOnWindow(
    "resize",
    $(() => {
      setSvgDimension(containerRef, store);
    })
  );

  useOnDocument(
    "keypress",
    $((event) => {
      const keyEvent = event as KeyboardEvent;
      if (keyEvent.code === "KeyA") {
        store.horPos -= 10;
      } else if (keyEvent.code === "KeyD") {
        store.horPos += 10;
      }
    })
  );

  useVisibleTask$(({ cleanup }: { cleanup: Function }) => {
    setSvgDimension(containerRef, store);
    const intervalId = setInterval(() => {
      store.vertPos += 10;
      render(svgRef, store.width, store.height, store.horPos, store.vertPos);
    }, 700);
    cleanup(() => clearInterval(intervalId));
  });

  return (
    <div class="flex justify-center w-screen h-screen pt-5" ref={containerRef}>
      <svg
        class="game-area"
        width={store.width}
        height={store.height}
        ref={svgRef}
      />
    </div>
  );
});

It's time to run the solution: npm start.

As we can see here, there is a moving square. You can move it left via the "A" key and right via "D."

If you want to dig into this code immediately, please use this source.

The HTML part

<div class="flex justify-center w-screen h-screen pt-5" ref={containerRef}>
  <svg
    class="game-area"
    width={store.width}
    height={store.height}
    ref={svgRef}
  />
</div>

We use SVG as a game board container. It will be represented as a Qwik Signal.

The Signals

Use useSignal() to create a reactive signal (a form of state). The useSignal() takes an initial value and returns a reactive signal.

The reactive signal returned by useSignal() consists of an object with a single property .value. If you change the value property of the signal, any component that depends on it will be updated automatically.

We use containerRef as a data associated with the root element. BTW, pay attention to the Tailwind-based 'class.' The aim of containerRef is to keep the dimension of the screen.

const containerRef = useSignal<Element>();
const svgRef = useSignal<Element>();

The Store

The heart of the component is a store.

export interface MainStore {
  width: number;
  height: number;
  horPos: number;
  vertPos: number;
}

const store = useStore<MainStore>({
  width: 0,
  height: 0,
  horPos: 200,
  vertPos: 0,
});

We keep the following data:

Width and height of the component (root component dimension equals to the root's)
Horizontal and vertical positions of the square

Initializing/resuming

useVisibleTask$ hook is very important in Qwik because

Use useVisibleTask$() to execute code after the component is resumed. This is useful for setting up timers or streams on the client when the application is resumed.

useVisibleTask$(({ cleanup }: { cleanup: Function }) => {
  setSvgDimension(containerRef, store);
  const intervalId = setInterval(() => {
    store.vertPos += 10;
    render(svgRef, store.width, store.height, store.horPos, store.vertPos);
  }, 700);
  cleanup(() => clearInterval(intervalId));
});

There are two main activities above.

Set the root component/board dimension: setSvgDimension(containerRef, store);
Provide a main loop of the game via setInterval.

The main loop

Let's dig into the main loop. Moving down is represented by store.vertPos += 10;.
We just adding 10 pixels every 700 millisecond.

After, we should render the board and the square.

The render

render function literally does the following things.

It takes the SVG-based component representation svgRef.value and binds it with svg variable via d3.select method. Clears all previous stuff in the SVG if it does exist.

const svg = d3.select(svgRef.value);
svg.selectAll("*").remove();

Draws a white rectangle due to the screen dimension. BTW, the following link will be useful.

svg
  .append("svg")
  .attr("width", width)
  .attr("height", height)
  .append("g")
  .attr("transform", "translate(0,0)");

svg
  .append("g")
  .append("rect")
  .attr("x", 0)
  .attr("width", width)
  .attr("y", 0)
  .attr("height", height)
  // @ts-ignore
  .attr("fill", () => d3.color("#ffffff"));

Associate the SVG-based component with x and y (just one element) and draw it.

const data = [{ x, y }];

svg
  .selectAll()
  .data(data)
  .enter()
  .append("g")
  .append("rect")
  .attr("x", (d) => d.x)
  .attr("width", 15)
  .attr("y", (d) => d.y)
  .attr("height", 15)
  // red
  .attr("fill", () => d3.color("#ff0000"));

Recalculate the board dimension and keyboard processing

Use useOn() / useOnDocument() / useOnWindow() to programmatically set up listeners on host elements. This is useful when you are creating custom APIs and don't have access to place these events in the JSX or if the events are not known ahead of time, such as if they are created based on component props.

The following code allows us to resize the component during the window resizing.

useOnWindow(
  "resize",
  $(() => {
    setSvgDimension(containerRef, store);
  })
);

The following code allows us to process keyboard events. In this example, a user moves the square left when the "A" key has been pressed and right if the "D" key has been pressed.

useOnDocument(
  "keypress",
  $((event) => {
    const keyEvent = event as KeyboardEvent;
    if (keyEvent.code === "KeyA") {
      store.horPos -= 10;
    } else if (keyEvent.code === "KeyD") {
      store.horPos += 10;
    }
  })
);

Build process

It's time to build the solution.

npm run build

It seems we passed this step successfully. But please pay attention to the text at the bottom:

 Missing an integration 

・ Use npm run qwik add to add an integration
・ Use npm run preview to preview the build

As a result, you don't see index.html in the dist folder. Let's fix this issue.

If you want to make this solution web-friendly, please run:

npm run qwik add

What integration would you like to add?

Adapter: Static site (.html files)

Ready to apply the static updates to your app?

Yes looks good, finish update!

Let's build the solution again...
And now we should see the expected index.html.

Please, read Qwik Deployments if you need to learn more about Qwik providers.

What's next?

I hope this episode was useful and informative. Feel free to read and run this solution. But it is just preparation before the actual gameplay implementation. The next episode will disclose all the main secrets about the game! See you!

Game-n-Qwik. Episode 01.

Vyacheslav Chub — Fri, 11 Aug 2023 13:15:21 +0000

The Columns Game

Preface.

This story started in 1991 when I had just finished high school and began studying at Kharkiv Polytechnic University. During my first face with IBM PC, I faced this beautiful game, and since then, I can't get it out of my head. I want to tell you about the Columns game. This game is a perfect example of an arcade game. Although it has many different implementations, including Sega version, my favorite one is Nathan Meyers 1989 MS-DOS port. I'm keen on its coloristic, minimalistic, and aesthetic.

I'm a person who follows traditions, and this game has become one of them. Whenever an interesting UI-related technology emerges or when I begin using one, I implement my Columns solution using that particular technology. For example 2007, I created the Adobe Flash version, and in 2019, I provided a Flutter-based one.

But let's stop digging into the history and focus on today.

The Qwik web framework was released in 2021 and, in my mind, became one of the most ambitious competitors in the UI area. A few months ago, I provided an article regarding Qwik.

However, in retrospect, I realize that I didn’t provide as much information as I intended to. The best way to disclose an essential topic is to provide a real-life example. And then, I remembered my old tradition and decided that the Web-based Columns game could be a great option if I want to improve my Qwik skills and tell this story to you, my dear reader.

Looking ahead, I'm glad to introduce you Qwik Columns!

Most of my friends compare this game with Tetris. At first glance, it really looks like Tetris. But this game is a bit different because it forces you to think differently than you do it playing Tetris. The main point is that colors are valuable in Columns. I'll explain the rules a bit later.

The Aim

I guess you noticed "Episode 01" in the title. This topic, frankly, could not be represented as an article due to the number of points to be covered. That's why I decided to split my telling into chunks and provide you with episodes. Each episode will focus on a subtopic, including Gameplay Architecture, Animation, Vector graphics via the D3 library, and, of course, Qwik. The current episode is just an introduction.

The Rules

There is a rectangle-based area that contains squares. It will be empty (white) before playing. A shape (actor) consists of three vertically arranged squares with different colors. It moves down until possible; that is, it reaches the bottom of the area or is faced with the next cell as a colored one. After, the related cells become colored according to the actor's colors. And then, a new actor appears at the top of the area. There is a checking process before the new actor appears. If colored squares are three or more equal colors on horizontal, vertical, and diagonal, then they should be demolished with increasing scores, and gaps will be collapsed. These are the original rules. Please look at the illustrations below.

Diagonal

Vertical and Horizontal

Checking and collapsing works till all of the same-colored verticals, horizontals, and diagonals are demolished.

But it would not be me if I implemented the rules as they are. I decided to add a couple of extra points.

1. If a square containing 4 squares appears, this shape should be demolished.

2. If a square containing 2 + 2 squares like the one below appears, this shape should be demolished.

Let's enjoy the game!

What's next?

As I mentioned earlier, this article is the start of the episodes that reveal the exciting game creation process. Step by step, we will reach the final solution!

In the next episode, I will explain how to bootstrap the project and make the first scratches via Qwik and D3.

Developing a Desktop Application via Rust and NextJS. The Tauri Way.

Vyacheslav Chub — Mon, 08 May 2023 07:08:34 +0000

Introduction

This article introduces you to a specific but exciting topic and is the sequel to my previous article. If you are keen on Rust integrations, please read Node & Rust: Friendship Forever. The NAPI-rs Way..

I suppose all of you, dear colleagues work or at least know about VSCode. Did you think about the technologies used in VSCode creation? You probably will be surprised if I tell you that VSCode is mainly written on Typescript. But stop... Typescript and Javascript are typical for web or backend-based applications, and VSCode is a standalone UI application. Is it possible to create a Javascript-based standalone UI application? Yes, it is!

If we had discussed this topic a couple of months ago, I would have recommended ElectronJS if you were looking for a way to create a standalone Javascript application. Also, I would provide you the following list of popular Electron-based applications.

Microsoft Teams
Zoom
Slack for Desktop
WordPress for Desktop
Skype
Discord
WhatsApp Desktop
Postman
MongoDB Compass

But the modern IT World does not stand still, and we’ve already had a powerful ElectronJS competitor (it could be its killer in the nearest future, BTW).

Meet Tauri!

If you want to get a brief comparison Tauri with Electron, please, read this article. "Goodbye Electron. Hello Tauri" will also be helpful if you want to understand Tauri pros and some brief technical details.

There is a brief comparison for my impatient readers.

Framework	"Frontend"	"Backend"
Electron	Chromium browser	NodeJS
Tauri	Native Webview	Rust-compiled code

One small note regarding Native Webview meant above. You can find ultimate information on this topic here. In a nutshell, Tauri applications use as HTML renderer Webkit (safari engine) on MacOS, Microsoft Edge WebView2 on Windows, and WebKitGTK on Linux (port of Webkit for Linux). Pay attention to the fact that a Tauri application could behave differently on different platforms according to the information above.

What thoughts would we conclude regarding the table above? Tauri is about performance and simplicity! As a developer who spent several years on Electron-related projects, I'm pretty sure NodeJS could be a bottleneck for the following reasons.

NodeJS is a heavyweight solution with complicated architecture. I mean V8, LibUV with Event Loop, etc.
NodeJS is not a good choice if we need to implement heavy processes like image, data processing, or complicated math calculations.
Inter-Process Communication (Electron IPC) is a way of communication between the "Frontend" and "Backend" in Electron. Its functionality is overcomplicated in coding.
Implementing a multithreading NodeJS-based "Backend" in our Electron-based application could be a nightmare.

Tauri demolishes all of the cons above for the following reasons.

Rust-complied code contains only the needed minimum of functionality (without redundant architectural stuff like V8 or LibUV).
Rust is multithreading-friendly and allows us to get multi-platform implementations.
Rust is full of useful memory-safe mechanisms that prevent developers from making the mistakes, and as a result, we get high-quality predictable code.
Rust-complied code is also more performative than NodeJS-based.

In my opinion, the pros above are critical for the "Backend." That's why according to the reasons above, I found Tauri approach as a perspective.

BTW if you are not a Rust expert and want to know something new about Rust multithreading , please read Multi-threading for Impatient Rust Learners..

The Objective

Of course, Tauri is something new. Despite this, it has good documentation. There are many interesting articles on this topic, and I recommend the following resources reading or watching.

Tauri, a Rust-powered Electron alternative - a video allows us to do the first steps
Goodbye Electron. Hello Tauri - provides an exciting example including events between "Frontend" and "Backend"
Tauri - Next.js - explains how to provide NextJS-based "Frontend"

My objective is to provide you with something new to run and test. I created a Tauri application with NextJS & Ant Design-based "Frontend" with some "Backend" calculations that look heavyweight. This application shows us Progress Bar on a screen, and related "progress" data is prepared on the "Backend" (Rust) side.

First Steps

Let's get started!

Create "Frontend" part



npx create-next-app@latest --use-npm --typescript

Answer the following questions...

Install Tauri dependencies



cd tauri-nextjs-demo
npm i --save-dev @tauri-apps/cli
npm i @tauri-apps/api --save

Updates

Update next.config.js



/** @type {import('next').NextConfig} */

const nextConfig = {
  reactStrictMode: true,
  // Note: This feature is required to use NextJS Image in SSG mode.
  // See https://nextjs.org/docs/messages/export-image-api for different workarounds.
  images: {
    unoptimized: true,
  },
};

module.exports = nextConfig;

Update scripts section in package.json



{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "export": "next export",
    "start": "next start",
    "tauri": "tauri",
    "lint": "next lint"
  }
}

Initialize "Backend" (Tauri) part



npm run tauri init

Answer the following questions...

src-tauri folder contains our backend part.

"Backend" functionality

The first bootstrapped version contains a minimal set of functionality. Let's fix it.

Please, open src-tauri/src/main.rs and put the following code.



#![cfg_attr(
  all(not(debug_assertions), target_os = "windows"),
  windows_subsystem = "windows"
)]
use tauri::Window;
use std::{thread, time};

#[derive(Clone, serde::Serialize)]
struct Payload {
    progress: i16,
}

#[tauri::command]
async fn progress_tracker(window: Window){
  let mut progress = 0;
  loop {
      window.emit("PROGRESS", Payload { progress }).unwrap();
      let delay = time::Duration::from_millis(100);
      thread::sleep(delay);
      progress += 1;
      if progress > 100 {
        break;
      }
  }
}

fn main() {
  tauri::Builder::default()
    .invoke_handler(tauri::generate_handler![progress_tracker])
    .run(tauri::generate_context!())
    .expect("error while running tauri application");
}

Pay attention to the points below.

progress_tracker function should be called from the "Frontend" (Typescript) part.
#[tauri::command] is an attribute that defines the function above as a Javascript-friendly
window: Window parameter should be passed from the "Frontend" side.
The loop inside progress_tracker returns a number every 100ms 100 times.
Pay attention on .invoke_handler(tauri::generate_handler![progress_tracker]) in main function. You must "register" your Frontend-friendly function.

Also, you need to change tauri.identifier value in src-tauri/tauri.conf.json. Say, to com.buchslava.dev in my case.
After that, change build.beforeBuildCommand value to npm run build && npm run export in the file above. It's important because in this example we work with NextJS SSG.

"Frontend" first scratches.

Let's move to our "Frontend" part.

Move to the project's root folder and put the following code into src/pages/index.tsx



import { invoke } from "@tauri-apps/api/tauri";
import { listen } from "@tauri-apps/api/event";
import { useEffect, useState } from "react";

interface ProgressEventPayload {
  progress: number;
}

interface ProgressEventProps {
  payload: ProgressEventPayload;
}

export default function Home() {
  const [busy, setBusy] = useState<boolean>(false);

  useEffect(() => {
    // listen what can Rust part tell us about
    const unListen = listen("PROGRESS", (e: ProgressEventProps) => {
      console.log(e.payload.progress);
    });

    return () => {
      unListen.then((f) => f());
    };
  }, []);

  return (
    <div>
      {!busy && (
        <button
          onClick={() => {
            setBusy(true);
            setTimeout(async () => {
              const { appWindow } = await import("@tauri-apps/api/window");
              // call Rust function, pass the window
              await invoke("progress_tracker", {
                window: appWindow,
              });
              setBusy(false);
            }, 1000);
          }}
        >
          Start Progress
        </button>
      )}
    </div>
  );
}

It's time to run the example...



npm run tauri dev

Let's open Developer Console (Right click on the screen -> Inspect -> Switch to Console tab) and press "Start Progress" button.

Congrats! We finished the basic Touri stuff and it's time to focus on "Frontend" upgrading.

You can find this solution here.

Add UI part

We need to add a Progress Bar widget to the screen and show the progress on it instead of Console.

First, install Ant Design dependency.



npm i antd --save

Second, remove all content from src/styles/Home.module.css.
Third, put the following content into src/styles/globals.css.



body {
  position: relative;
  width: 100vw;
  height: 100vh;
  font-family: sans-serif;
  overflow-y: hidden;
  display: flex;
  justify-content: center;
  align-items: center;
}

Fourth, put the following code into src/pages/index.tsx instead the existing.



import { invoke } from "@tauri-apps/api/tauri";
import { listen } from "@tauri-apps/api/event";
import { useEffect, useState } from "react";
import { Button, Progress } from "antd";

interface ProgressEventPayload {
  progress: number;
}

interface ProgressEventProps {
  payload: ProgressEventPayload;
}

export default function Home() {
  const [busy, setBusy] = useState<boolean>(false);
  const [progress, setProgress] = useState<number>(0);

  useEffect(() => {
    const unListen = listen("PROGRESS", (e: ProgressEventProps) => {
      setProgress(e.payload.progress);
    });

    return () => {
      unListen.then((f) => f());
    };
  }, []);

  return (
    <div>
      <div style={{ width: "70vw" }}>
        <Progress percent={progress} />
      </div>
      <Button
        type="primary"
        disabled={busy}
        onClick={() => {
          setBusy(true);
          setTimeout(async () => {
            const { appWindow } = await import("@tauri-apps/api/window");
            await invoke("progress_tracker", {
              window: appWindow,
            });
            setBusy(false);
          }, 1000);
        }}
      >
        Start Progress
      </Button>
    </div>
  );
}

Let's look at the result...



npm run tauri dev

Looks good. But I'm a suspicious guy, and I must be 100% sure that everything between Rust and NextJS parts stays together. I want to add a timer to the "Frontend" screen. As a result, Progress and Timer should work simultaneously without stops.

Let's put the following code into src/pages/index.tsx instead the existing.



import { invoke } from "@tauri-apps/api/tauri";
import { listen } from "@tauri-apps/api/event";
import { useEffect, useState } from "react";
import { Button, Progress } from "antd";

interface ProgressEventPayload {
  progress: number;
}

interface ProgressEventProps {
  payload: ProgressEventPayload;
}

export default function Home() {
  const [busy, setBusy] = useState<boolean>(false);
  const [progress, setProgress] = useState<number>(0);
  const [timeLabel, setTimeLabel] = useState<string>();

  useEffect(() => {
    const timeIntervalId = setInterval(() => {
      setTimeLabel(new Date().toLocaleTimeString());
    }, 1000);
    const unListen = listen("PROGRESS", (e: ProgressEventProps) => {
      setProgress(e.payload.progress);
    });

    return () => {
      clearInterval(timeIntervalId);
      unListen.then((f) => f());
    };
  }, []);

  return (
    <div>
      <div style={{ position: "fixed", top: 20, left: 20 }}>{timeLabel}</div>
      <div style={{ width: "70vw" }}>
        <Progress percent={progress} />
      </div>
      <Button
        type="primary"
        disabled={busy}
        onClick={() => {
          setBusy(true);
          setTimeout(async () => {
            const { appWindow } = await import("@tauri-apps/api/window");
            await invoke("progress_tracker", {
              window: appWindow,
            });
            setBusy(false);
          }, 1000);
        }}
      >
        Start Progress
      </Button>
    </div>
  );
}

It's time to make the last stitch. Till we have progress functionality, we need to stop it somehow. The following modifications allow us to do it.

src-tauri/src/main.rs



#![cfg_attr(
  all(not(debug_assertions), target_os = "windows"),
  windows_subsystem = "windows"
)]
use tauri::Window;
use std::{thread, time};
use std::sync::{Arc, RwLock};

#[derive(Clone, serde::Serialize)]
struct Payload {
    progress: i16,
}

#[tauri::command]
async fn progress_tracker(window: Window){
  // New code
  let stop = Arc::new(RwLock::new(false));
  let stop_clone = Arc::clone(&stop);
  let handler = window.once("STOP", move |_| *stop_clone.write().unwrap() = true);
  // / New code

  let mut progress = 0;
  loop {
      // New code
      if *stop.read().unwrap() {
        break;
      }
      // / New code
      window.emit("PROGRESS", Payload { progress }).unwrap();
      let delay = time::Duration::from_millis(100);
      thread::sleep(delay);
      progress += 1;
      if progress > 100 {
        break;
      }
  }
  window.unlisten(handler); // New code
}

fn main() {
  tauri::Builder::default()
    .invoke_handler(tauri::generate_handler![progress_tracker])
    .run(tauri::generate_context!())
    .expect("error while running tauri application");
}

src/pages/index.tsx



import { invoke } from "@tauri-apps/api/tauri";
import { listen } from "@tauri-apps/api/event";
import { useEffect, useState } from "react";
import { Button, Progress } from "antd";

interface ProgressEventPayload {
  progress: number;
}

interface ProgressEventProps {
  payload: ProgressEventPayload;
}

export default function Home() {
  const [busy, setBusy] = useState<boolean>(false);
  const [progress, setProgress] = useState<number>(0);
  const [timeLabel, setTimeLabel] = useState<string>();

  useEffect(() => {
    const timeIntervalId = setInterval(() => {
      setTimeLabel(new Date().toLocaleTimeString());
    }, 1000);
    const unListen = listen("PROGRESS", (e: ProgressEventProps) => {
      setProgress(e.payload.progress);
    });

    return () => {
      clearInterval(timeIntervalId);
      unListen.then((f) => f());
    };
  }, []);

  return (
    <div>
      <div style={{ position: "fixed", top: 20, left: 20 }}>{timeLabel}</div>
      <div style={{ width: "70vw" }}>
        <Progress percent={progress} />
      </div>
      <Button
        type="primary"
        disabled={busy}
        onClick={() => {
          setBusy(true);
          setTimeout(async () => {
            const { appWindow } = await import("@tauri-apps/api/window");
            await invoke("progress_tracker", {
              window: appWindow,
            });
            setBusy(false);
          }, 1000);
        }}
      >
        Start Progress
      </Button>
      {/* New code */}
      <Button
        type="primary"
        disabled={!busy}
        onClick={async () => {
          const { appWindow } = await import("@tauri-apps/api/window");
          await appWindow.emit("STOP");
          setProgress(0);
          setBusy(false);
        }}
      >
        Stop Progress
      </Button>
      {/* / New code */}
    </div>
  );
}

Looks persuasive!

Frontend Backend Communication in Tauri: Implementing Progress Bars and Interrupt Button will tell you more regarding the technique above.

You can find the related source here.

The Fasts

Finally, I want to focus on build stuff. Let's build the app. BTW, I'm working under MacOS. Please, read this one if you want to get more about Tauri build. Let's build!



npm run tauri build

The next information will help you understand where and what you can find regarding the result of the build. You can find your build in /src-tauri/target/release/bundle.

In MacOS, you will find the standalone application /src-tauri/target/release/bundle/macos with the installer-based build /src-tauri/target/release/bundle/dmg.

The most exciting thing here is the 4.7Mb application and 2.3Mb installer. Can you believe it? 4.7Mb of Rust & NextJS & Ant Design!

Do you want to compare Tauri's result with Electron's one???

Honestly, when I got this result, my memories from my past returned. I remember 20mb hard disks and IBM PC XT.

I also thought about the following. Amazing! I can put an application from 2023 to my PC from 1990. Sounds like a time machine!

PS: Thanks to Eduardo Speroni for helpful notes that improve the article.

Zero-cost Way on React & D3.

Vyacheslav Chub — Wed, 26 Apr 2023 06:48:37 +0000

It's no secret that the rules on pure React solutions are pretty simple. We just need to properly use all React inventory like useState, useEffect, useMemo, and useCallback. There are many intelligent articles, guides, and examples on the topic. But let's answer the following question.

How many "pure" projects did you tackle?

A pure React (Angular, NodeJS, etc.) project could look like nonsense in real life. Customers expect complicated solutions, including different 3-rd party stuff like Payment Systems, Graphical Libraries, CRM integrations, Tracking Tools, etc. Obviously, not all of them are React-friendly, so we should count these libraries' features in most cases and try to perfect React code simultaneously.

Today I want to tell you some performance specifics across React and D3.

I wrote several articles on the D3 topics before, and I guess it will also be interesting for you. There are the following related articles.

But let's focus on the current topic.

D3.js is a JavaScript library for manipulating documents based on data. D3 helps you bring data to life using HTML, SVG, and CSS. D3’s emphasis on web standards gives you the full capabilities of modern browsers without tying yourself to a proprietary framework, combining powerful visualization components and a data-driven approach to DOM manipulation.

D3 is great! I'm fond of this beautiful library. But it lives its own life. That's why we need to remember this fact when we work with D3 outside Vanilla JS, say, in React.

The Objective

The goal is a simple D3 line chart implemented with dynamic guideline movement every second.

I'm pretty sure the best way to understand what's good is to explain what's wrong. That's why I will start my solutions from the worst example. I'm also going to explain why the example is so wrong, and after that, I'll propose to you the best way of implementation.

The Worst Solution

There is the following component represents a line chart.



import React, { useEffect, useRef } from "react";
import * as d3 from "d3";

const transform = "translate(50,50)";

export default function LineChart({ data, width, height, marker }) {
  const svgRef = useRef();

  const renderSvg = () => {
    const chartWidth = width - 200;
    const chartHeight = height - 200;

    const svg = d3.select(svgRef.current);

    svg.selectAll("*").remove();

    const xScale = d3.scaleLinear().domain([0, 100]).range([0, chartWidth]);
    const yScale = d3.scaleLinear().domain([0, 200]).range([chartHeight, 0]);

    const g = svg.append("g").attr("transform", transform);

    g.append("g")
      .attr("transform", "translate(0," + chartHeight + ")")
      .call(d3.axisBottom(xScale));

    g.append("g").call(d3.axisLeft(yScale));

    svg
      .append("g")
      .selectAll("dot")
      .data(data)
      .enter()
      .append("circle")
      .attr("cx", function (d) {
        return xScale(d[0]);
      })
      .attr("cy", function (d) {
        return yScale(d[1]);
      })
      .attr("r", 3)
      .attr("transform", transform)
      .style("fill", "#CC0000");

    const line = d3
      .line()
      .x(function (d) {
        return xScale(d[0]);
      })
      .y(function (d) {
        return yScale(d[1]);
      })
      .curve(d3.curveMonotoneX);

    svg
      .append("path")
      .datum(data)
      .attr("class", "line")
      .attr("transform", transform)
      .attr("d", line)
      .style("fill", "none")
      .style("stroke", "#CC0000")
      .style("stroke-width", "2");

    if (marker) {
      svg
        .append("svg:line")
        .attr("transform", transform)
        .attr("stroke", "#00ff00")
        .attr("stroke-linejoin", "round")
        .attr("stroke-linecap", "round")
        .attr("stroke-width", 2)
        .attr("x1", xScale(marker))
        .attr("y1", 200)
        .attr("x2", xScale(marker))
        .attr("y2", 0);
    }
  };

  useEffect(() => {
    renderSvg();
  }, [width, height, data, marker]);

  if (!width || !height || !data) {
    return <></>;
  }

  return <svg ref={svgRef} width={width} height={height} />;
}

This component takes the following props.

data - chart data as a two-dimensional array of x and y
width - with of the chart
height - height of the chart
marker - X axis of a guideline

And there is a related parent component.



import React, { useState, useEffect } from "react";
import LineChart from "./LineChart";
import "./style.css";

const data = [
  [1, 1],
  [12, 20],
  [24, 36],
  [32, 50],
  [40, 70],
  [50, 100],
  [55, 106],
  [65, 123],
  [73, 130],
  [78, 134],
  [83, 136],
  [89, 138],
  [100, 140],
];

export default function App() {
  const [marker, setMarker] = useState(10);

  useEffect(() => {
    const intervalId = setInterval(() => {
      setMarker((prevMarker) => (prevMarker + 10 > 100 ? 10 : prevMarker + 10));
    }, 1000);

    return () => {
      clearInterval(intervalId);
    };
  }, []);

  return (
    <div id="root-container">
      <LineChart data={data} width={500} height={400} marker={marker} />
    </div>
  );
}

There is an interval refresh a marker value every second and pass it as a chat's prop.

You can play with the complete example here.

It seems it's nothing foreshadowing the issue. I want to modify the code above. The aim is to show the issue eloquently.

The Number of Renders

First, I'll add a global renders and timeStart variables to public/index.html



<script>
  var renders = 0;
  var timeStart = new Date().toISOString();
</script>
<div id="root"></div>

Second, I increase renders every LineChart render.



export default function LineChart({ data, width, height, marker }) {
  // no changes here ...

  renders++;

  useEffect(() => {
    renderSvg();
  }, [width, height, data, marker]);

  if (!width || !height || !data) {
    return <></>;
  }

  return <svg ref={svgRef} width={width} height={height} />;
}

And finally, I changed the parent component the following way.



export default function App() {
  const [marker, setMarker] = useState(10);

  useEffect(() => {
    const intervalId = setInterval(() => {
      setMarker((prevMarker) => (prevMarker + 10 > 100 ? 10 : prevMarker + 10));
    }, 1000);

    return () => {
      clearInterval(intervalId);
    };
  }, []);

  const currentTime = new Date().toISOString();

  return (
    <div id="root-container">
      <div style={{ marginTop: 20, marginLeft: 20 }}>
        renders: {renders}
        <br />
        start: {timeStart}
        <br />
        now: {currentTime}
      </div>
      <LineChart data={data} width={500} height={400} marker={marker} />
    </div>
  );
}

The main goal is to display three metrics: the number of renderings, start time, and current time.

Let's run the modified example.

As far as we can see, each marker change causes LineChart component to render. If the result above doesn't persuade you, I have prepared the experiment below. I left the working example for a few minutes and drank coffee.

When I returned, I saw the following.

`948` render per cup of coffee! Looks awful...

Moreover, a bunch of D3 heavyweight operations covers each render!

The Best Solution

It's time to fix the issue above.

First, let me provide you the final LineChart version and explain what's changed there step by step.



import React, {
  useEffect,
  forwardRef,
  useImperativeHandle,
  useRef,
} from "react";
import * as d3 from "d3";

const transform = "translate(50,50)";

const LineChart = forwardRef(({ data, width, height }, ref) => {
  const svgRef = useRef();
  let svg;
  let xScale;

  useImperativeHandle(ref, () => ({
    setMarker: (value) => {
      if (isNaN(value)) {
        return;
      }
      svg.selectAll(".marker").remove();

      svg
        .append("svg:line")
        .attr("transform", transform)
        .attr("class", "marker")
        .attr("stroke", "#00ff00")
        .attr("stroke-linejoin", "round")
        .attr("stroke-linecap", "round")
        .attr("stroke-width", 2)
        .attr("x1", xScale(value))
        .attr("y1", 200)
        .attr("x2", xScale(value))
        .attr("y2", 0);
    },
  }));

  const renderSvg = () => {
    const chartWidth = width - 200;
    const chartHeight = height - 200;

    svg = d3.select(svgRef.current);

    svg.selectAll("*").remove();

    xScale = d3.scaleLinear().domain([0, 100]).range([0, chartWidth]);
    const yScale = d3.scaleLinear().domain([0, 200]).range([chartHeight, 0]);

    const g = svg.append("g").attr("transform", transform);

    g.append("g")
      .attr("transform", "translate(0," + chartHeight + ")")
      .call(d3.axisBottom(xScale));

    g.append("g").call(d3.axisLeft(yScale));

    svg
      .append("g")
      .selectAll("dot")
      .data(data)
      .enter()
      .append("circle")
      .attr("cx", function (d) {
        return xScale(d[0]);
      })
      .attr("cy", function (d) {
        return yScale(d[1]);
      })
      .attr("r", 3)
      .attr("transform", transform)
      .style("fill", "#CC0000");

    const line = d3
      .line()
      .x(function (d) {
        return xScale(d[0]);
      })
      .y(function (d) {
        return yScale(d[1]);
      })
      .curve(d3.curveMonotoneX);

    svg
      .append("path")
      .datum(data)
      .attr("class", "line")
      .attr("transform", transform)
      .attr("d", line)
      .style("fill", "none")
      .style("stroke", "#CC0000")
      .style("stroke-width", "2");
  };

  renders++;

  useEffect(() => {
    renderSvg();
  }, [width, height, data]);

  if (!width || !height || !data) {
    return <></>;
  }

  return <svg ref={svgRef} width={width} height={height} />;
});

export default LineChart;

forwardRef

Now LineChart's parent is able to work with the related component reference.



const LineChart = forwardRef(({ data, width, height }, ref) => {

useImperativeHandle

During some interviews, I ask my interviewees this question. I'm surprised because most of them can't answer it. In my opinion, this hook is as important as the basic like useState and useEffect because it makes your code more flexible and performative.

Here is the exposed code.



useImperativeHandle(ref, () => ({
  setMarker: (value) => {
    if (isNaN(value)) {
      return;
    }
    svg.selectAll(".marker").remove();

    svg
      .append("svg:line")
      .attr("transform", transform)
      .attr("class", "marker")
      .attr("stroke", "#00ff00")
      .attr("stroke-linejoin", "round")
      .attr("stroke-linecap", "round")
      .attr("stroke-width", 2)
      .attr("x1", xScale(value))
      .attr("y1", 200)
      .attr("x2", xScale(value))
      .attr("y2", 0);
  },
}));

I moved it from the end of renderSvg function. See the previous example.

Let's focus on the parent component. Please, read comments there.



import React, { useState, useEffect, useMemo, useRef } from 'react';
import LineChart from './LineChart';
import './style.css';

const data = [
  // no changes
];

export default function App() {
  const [marker, setMarker] = useState(10);
  // Provide a reference for LineChart
  const chartRef = useRef();

  useEffect(() => {
    // If the marker has been changed set it on LineChart directly, see useImperativeHandle
    chartRef.current.setMarker(marker);
  }, [marker]);

  useEffect(() => {
    const intervalId = setInterval(() => {
      setMarker((prevMarker) => (prevMarker + 10 > 100 ? 10 : prevMarker + 10));
    }, 1000);

    return () => {
      clearInterval(intervalId);
    };
  }, []);

  const currentTime = new Date().toISOString();

  // There is a trick because we don't need to render LineChart after every App state variable change
  // As you can see we don't pass the marker here.
  const chart = useMemo(() => {
    return <LineChart ref={chartRef} data={data} width={500} height={400} />;
  }, [data]);

  return (
    <div id="root-container">
      <div style={{ marginTop: 20, marginLeft: 20 }}>
        renders: {renders}
        <br />
        start: {timeStart}
        <br />
        now: {currentTime}
      </div>
      {chart}
    </div>
  );
}

According to the comments above, there are three points of change.

Provide a reference for LineChart
Marker direct setting via useImperativeHandle. Pay attention to the fact that every useImperativeHandle-based call doesn't cause the component to render. It's super important!
Memoise the LineChart component. We don't need to refresh it with each App state change.

Finally, the most tricky stuff has remained.

After attentional looks at the code above, you could ask a question.

On the one hand, now the component shouldn't be re-rendered. On the other hand, the guideline moves from point A to point B. Of course, chartRef.current.setMarker(marker); direct call allows us to set the guideline in the new position. But what approach allows us to remove the previous guideline from point A?

At the start of the article, I meant that we need to count D3 library features. In this case, we should know two facts below.

D3 objects are stateful, so we can operate them whenever needed. In this context, please look at the following code.



  let svg;

  const renderSvg = () => {
    // ...
    svg = d3.select(svgRef.current);
    //All futures results of modifications will be present persistently in SVG object
};

According to the feature above, we can change the D3 object every time without re-rendering. Moreover, we can manipulate different chart parts via fake CSS classes.

Look at the following code.



    setMarker: (value) => {
      if (isNaN(value)) {
        return;
      }
      svg.selectAll('.marker').remove();

      svg
        .append('svg:line')
        .attr('transform', transform)
        .attr('class', 'marker')
        .attr('stroke', '#00ff00')
        .attr('stroke-linejoin', 'round')
        .attr('stroke-linecap', 'round')
        .attr('stroke-width', 2)
        .attr('x1', xScale(value))
        .attr('y1', 200)
        .attr('x2', xScale(value))
        .attr('y2', 0);
    },
  }));

When we add a guideline, we add a special fake class into it:



.attr('class', 'marker')

But before we remove the previous guideline via



 svg.selectAll('.marker').remove();

That's all for today about the secrets of D3.

It's time to run the final example! You can play with the complete final example here.

Only two renders per all time. Looks cool!

That’s like music to the ears of React developer!

Happy coding!

PS: If you are wondering why two renders, please read about React Strict Mode.

DEV Community: Vyacheslav Chub

The secrets of efficient CV analyzing. The E-pattern. Tips & Tricks.

The goal

The CV-related antipatterns

Technological Zoo

"Water" Explanations in Job Descriptions.

Third-person narration

An inconsistent set of Job positions

The patterns of CV scanning

The F-pattern

The Z-pattern

The Psychology of Reading a CV / Resume - F & Z Patterns

Meet the E-pattern!

Step-by-Step Process

Why Scan from the Bottom Up?

E = F + L is quite simple ;)

Why This Approach Saves Time

Step 1: Apply the F-Pattern

Step 2: Apply the L-Pattern

Final Decision

Step 1: Apply the F-Pattern

Step 2: Apply the L-Pattern

Tauri CRUD Boilerplate

Data

DB connect

Persons

Todos

How to use

Components refreshing

The App component

The recommendations

Painless CLI integration testing

Introduction

The original solution

Make the solution test-friendly

Testing

Geeks' Post Scriptum

Google Translate customization#2 under NextJS.

src/components/lang-switcher.tsx

src/pages/_document.tsx

May the Google Translate, NextJS, and Force be with you!

Google Translate customization under NextJS

Bootstrapping

The main part

The scripts

The LanguageSwitcher component

Working principles

The start point is placed in src/pages/_document.tsx

There are three scripts there

What happens if the user presses a language on LanguageSwitcher?

Conclusion

May the Google Translate, NextJS, and Force be with you!

The Interview Under the Hood

The 10 Commandments of Technical Interviewing

The NodeJS Scratch

Scenario 1.

Scenario 2.

The Golang Scratch

Conclusion

The 10 Commandments of Technical Interviewing

PS: This topic is one of my favorites. I'm fond of interviewing activities and always want to share my knowledge with my colleagues. In my strong opinion, proper staff selection makes our world much much and much better;) That's why I want to proceed with this topic. See you!

Game-n-Qwik. The Final Episode.

The Final Stitches.

Gameplay changes

An important note regarding Qwik!

The Footer

It's time to summarize our decisions!

PS: During the game implementation, I got pleasure every moment I faced Qwik functionality and documentation. That's why I want to thank Builder.io for the perfect solution!

Game-n-Qwik. Episode 03.

Make it a pure game! The main changes.

The Screen Management

The Phase

The Actor

The Main Definition

Exports

The store

Gameplay utilization functions

The heart of the game.

What's next?

Game-n-Qwik. Episode 02.

Step 2: Apply the `L-Pattern`

What happens if the user presses a language on `LanguageSwitcher`?

`948` render per cup of coffee! Looks awful...