DEV Community: Meditator Gu

Null>=0 And Undefined>=0 Have Opposite Result Values

Meditator Gu — Wed, 19 Mar 2025 14:12:19 +0000

Recently, I unified the use of null and undefined in the project according to a technical specification of the company. The variables in some scenarios, whose initial values were undefined, are now changed to null.

After the modification, I found a strange bug that I couldn't find no matter how hard I tried. The logic of the code from top to bottom was normal, but at the end it threw an exception that shouldn't have been thrown.

So I cloned the code again and restored it to the state before the modification. Then I ran the code before and after the modification at the same time. I found that when the code came to an if branch, one of them entered the if branch and the other jumped over it. The if branch looked like this:

const count = pageKidsCountCache.get(currentNode);
// Skip nodes where the page can't be.
if (count >= 0 && currentPageIndex + count <= pageIndex) {
  currentPageIndex += count;
  continue;
}

The value count retrieved from the Map is sometimes empty, that is, undefined. In this case, I changed it to null. Then something went wrong. When the count value was undefined, count>=0 was false. But after changing it to null, it became true. This caused a strange problem.

I entered it twice in the Chrome console and found that JavaScript is indeed like this.
The result value of null>=0 is true, while the result value of undefined>=0 is false.

To further alleviate my confusion, I consulted some documents. The data shows that:
When using relational operators, JavaScript converts non-numeric operands to numbers. By default, null is converted to 0, and undefined is converted to NaN. Because 0>=0, null>=0 is true, and NaN is false when compared to any number, so the value of undefined>=0 is false.

TypeScript From The Perspective Of A Java Programmer (I)

Meditator Gu — Wed, 19 Mar 2025 13:31:12 +0000

A while ago, I used TypeScript to refactor a JavaScript project. But before that, I was a developer specializing in Java. In the field of business system development, I mainly study SpringBoot, MyBatis, Tomcat, microservice technology, databases, etc. I have also basically learned some big data-related technologies, such as Hadoop, HBase, and Hive, and developed a big data system for a year. For other languages and related technologies, whether for development or for writing scripts, I have more or less dabbled in some of them. For example, writing bash scripts in Linux, writing Powershell scripts under Windows, using Python to build a simple server that provides algorithm functions, and using jQuery to write some simple web pages. Because of different usage scenarios and different problems faced, the related development modes, code writing methods, component ecology, and even the way programmers think about problems are very different.

Before I learned TypeScript systematically, I occasionally wrote some TypeScript code as an amateur front-end developer. I copied other people's code, modified it, and met some less complex requirements. Some of these copied codes were from netizens, some were official website examples, and some were already written by my colleagues. When I just graduated, I used WebStorm to write front-end code, but in recent years I have gradually changed to VSCode. Compared with the front-end, the development environment IDEA mainly used by back-end development has a higher degree of tool integration. If the project and tools are configured correctly, then developers actually do not need to open the command line, and many things can be done very well by clicking buttons. For example, developers can import dependencies, run code, compile jar packages, etc. by clicking menus and buttons. IDEA will execute related commands on behalf of developers. It is relatively convenient and fast. However, for the front-end, if you want to develop a project well or manage a project well, the understanding of the tool chain is much higher than that of the back-end. This is the first big difference between them.

When I decided to use TypeScript to develop some programs systematically, I first had to choose a suitable project creation tool. The competition for project creation tools in the front-end is more intense than that in the back-end. The back-end is basically Maven. Although there are some other competitors in this regard, such as Gradle. But the developers I know will choose Maven. On the back-end, you only need to click on the interface to create a project through IDEA and Spring Initializer. The front-end requires some commands to do these things. For me, the first is npm, then pnpm, and finally vite. After doing these, I still need to spend some time on some configuration files, such as tsconfig.json, vite.config.js, package.json, etc. Make sure that the project built by these files meets my expectations.

JavaScript's flexibility allows it to run not only in the browser, but also in node. Once it runs in node, it can be an http-server or a scripting language like bash. When I first started learning TypeScript, I was quite confused about this. The same JavaScript code will be subject to different constraints due to the different running environments. In the browser, I can use window to get global variables and use document to create DOM elements, but I can't do that in the node environment. Similarly, in the node environment, I can use the path library to read and write local files, but I can't do that in the browser. Even the debugging methods are quite different. If it is node code, then the debugging method is similar to Java. Just start the code in debug mode. But if it is for the browser, it is relatively troublesome. You need to configure the browser to open it in debug mode first, and then connect to the browser's remote debugging port through socket. Finally, you must ensure that the mapping of the execution code to the source code is correct.

After solving the problems of project creation and configuration, it is time to officially start writing code. Java and TypeScript are very similar in terms of code writing. They are both descendants of the C language family and are both object-oriented. However, the historical burden of TypeScript is much heavier than that of Java. TypeScript has to be as compatible with JavaScript as possible and take on the responsibility of object-oriented, which faces great challenges. The only historical burden of Java that I know is that it is a generic erasure. JavaScript itself is flexible to write, and it was quite practical in the past when the source code of several web pages on a website was independent of each other. But now I have to develop more complex code. What I developed is a library containing more than 100,000 lines of code. JavaScript is a bit overwhelmed. The lack of clear calling relationships, unclear parameter types, and lack of support for polymorphism are quite fatal. Unfortunately, as a front-end language, TypeScript will eventually be compiled into JavaScript, and it is still limited by some designs and defects of JavaScript.

When I tried to write code in an object-oriented way, the first limitation I encountered was that the interface in TypeScript would be erased after compilation. The interface in TypeScript is more like an upgraded version of JSDoc than a specific type. It is deeply involved in the code development process, providing developers with important type information, while also restricting developers from writing non-standard code, but it disappears quietly after compilation. Its quiet disappearance makes it impossible for me to use instanceof to determine whether an object implements this interface during the development process. This is a pity.

The status of the interface in the object-oriented code development process needs no further explanation. Many specifications emphasize the importance of interfaces. For example, the Dependency Inversion Principle in the six principles of design patterns emphasizes programming for interfaces rather than specific classes. By reading the definitions of the relevant methods in the interface, we can understand the capabilities of this interface at a glance without having to go back and forth to the specific implementation code. If the type declared for the variable is an interface rather than a specific class, it will be easy to replace or rewrite the class in the future. In the interaction between components, all APIs of a component are declared in the form of interfaces, and an independent module is extracted. The caller calls the interface through this interface module, and the implementer makes a specific implementation in another module. This is a very good way to decouple. In general, the interface in TypeScript does have some shortcomings due to the problem of interface erasure. However, it also provides most of the capabilities required by the interface feature. Interfaces in TypeScript support polymorphism, which surprised me because JavaScript does not support polymorphism. However, TypeScript interfaces can declare methods with the same name but different parameters. However, in the implementation process, there can only be one function to implement all interfaces with the same name.

Null and undefined in TypeScript is another confusing problem I encountered. If we consider the equality symbol "===" together, it will be even more confusing. In Java, there is only one kind of null, that is null. Although some reports claim that the problems caused by null pointers have caused a lot of loss of business value. In the actual development process, null pointers are indeed very common. But there has been no good way to deal with this problem. I have written some C# before. In C#, the type must be separately declared whether it is null or not, which surprised me at the time. But what surprised me more was that TypeScript not only has null, but also undefined. These things are mixed together, and it is indeed more difficult to deal with. Although there are some related switches in tsconfig that can turn off the detection of null or not distinguish between null and undefined, in fact, for higher code quality, I cannot turn them off. In the process of declaring a variable, both null and undefined must be reflected. This will make the code very lengthy. For example, the following example:

class Person{
  name: string | null | undefined
}

In a simple name declaration, null and undefined occupy half of the space, but only provide a little useful information. If they appear in large numbers in the code, the proportion of code with business meaning will be much less. Mixing them will also cause some problems. I can give two examples that I have actually encountered.

The first example is when using the strict equality check, null !== undefined. That is, null and undefined are not strictly equal. If you want to clearly check that person.name is not null, you need to write more code and do more work. Write it like this:

if(person.name !== null && person.name !== undefined){
  ...
}

This is actually unnecessary. Spending more time and energy on the matter of judging null will reduce the time and energy spent on specific function development. Tools serve developers, and developers need to understand tools, but they should not always deal with some special problems of tools.

The second example is a bug I encountered. After a long time of locating, I found that it was caused by the different truth and falsehood of null >= 0 and undefined >= 0. The value of null >= 0 is true, while the value of undefined >= 0 is false. If a variable x of type number can be null or undefined, then the writing of x >= 0 may cause some strange problems in some special scenarios.

In the TypeScript project I'm responsible for, I choose to use null extensively and use undefined cautiously. When necessary, I need to set the variable with the value of undefined to null in time. After all, the specific semantics and functions of undefined and null are different. You can't generalize them or simply use only one of them.

In addition to the two issues mentioned above, in the process of systematically learning and using TypeScript extensively, I also found that TypeScript has made a lot of efforts to make up for the shortcomings of JavaScript in object-oriented development. As a Java developer, I know the role of these syntaxes very well. For example, the return type of a function is never, assert crond, arg is number. JavaScript is not object-oriented at all. TypeScript wants to be more thorough in object-oriented. Therefore, we have to use something like an adapter to ease the contradiction between the two languages.

I will share my views on these issues in detail in subsequent blogs. Welcome to leave a message or send a private message to discuss with me.

Share A Open Source Web Image Editing Library -- Based On Fabric

Meditator Gu — Tue, 18 Mar 2025 10:36:14 +0000

A while ago, I helped a client solve a picture editing problem that their product was facing. After taking photos, their users needed to annotate them and then upload them to the system. In order to simplify this process, I developed a picture editing library for their system and completed the integration work with the client. In this way, they can directly edit pictures and upload them directly, saving their users a lot of unnecessary operations. This library is now officially providing services to their users.

The main technologies of this project are TypeScript and FabricJS (version 6.4.3).

To show you this web image editing library, I have provided two online examples using Github Pages. Click to experience:

Example 1: Edit An Image Directly

https://xingshen24.github.io/online-image-editor/index.html

Example 2: Select An Image To Edit

https://xingshen24.github.io/online-image-editor/example.html

The source code of this project has been hosted on Github:
https://github.com/xingshen24/online-image-editor

This library already has the basic functions that an online image editor should have. These functions are mainly divided into three categories.

The first category of functions is to add some annotations to the picture. This category of functions includes six basic annotation drawing operations, namely rectangle, circle, arrow, brush, text, mosaic drawing, in addition to this, there is also a base map dragging function.

The second category of functions is the operation of the image itself, including zooming in, zooming out, extending and shrinking blank areas, rotating, flipping, and cropping.

The third category mainly includes functions that editors should have, rather than the image itself. From the operator's perspective, there are forward and backward operations, editor reset, confirmation and cancellation of the current image edit. From the developer's perspective, it is the integration of the image editor with the business code and the related APIs and callbacks.

The main functions of concern from the operator's perspective are: forward, backward, and reset.

The main functions of concern from the developer's perspective are: confirmation and cancellation.

The three categories of functions mentioned above have been bound to the commonly used shortcut keys "ctrl+z" and "ctrl+y" to make it easier for users to operate.

This library is created for developers. Therefore, developers can use simple code to open an image editor and configure the confirmation and cancellation callback functions to complete the integration of the project. As shown in the following code:

ImageEditorHelper.createImageEditor(imageDisplay.src, '.', (base64Image) => {
  imageDisplay.src = base64Image;
  if (imageDisplay.classList.contains('hidden')) {
    imageDisplay.classList.remove('hidden'); // 显示图片
  }
});

The above code uses createImageEditor to create an image editor. It contains three parameters. The parameter 'imageDisplay.src' is the address of the image, '.' is the relative path of a series of icons to be used by the image editor, and the third parameter is the callback executed after a single image edit is confirmed. There is also a fourth parameter, which is the callback executed after a single image edit is canceled. Because no special processing is required, the default value is used.

I will write a series of blogs in detail later to share with readers how to use FabricJS step by step to develop such an image editor. It contains some tricky points, such as cropping screenshots. In order to overcome these problems, I also conducted an in-depth study of the source code of FabricJS.

One hundred days!I Refactored The 50000 Star JavaScript Project with TypeScript！

Meditator Gu — Tue, 18 Mar 2025 03:53:54 +0000

Displaying PDF on the Web is a common requirement. However, the community has long lacked a suitable library to help developers do this. Pdf.js can meet the needs of displaying PDF, but it seems to be a bit powerless when it comes to integrating it into business systems. The latter is a fairly common requirement in China, whether it is a government-customized system or a commercial company's application system.

Here are some common problems when using pdf.js in application systems:

It is easy to integrate pdf.js into the web, but it is not very convenient to make pdf.js interact with the backend.
The basic functions of the PDF reader are available, but it is difficult for developers to control these functions through code.
The source code is relatively complex and difficult to read, modify and extend, and customization based on the source code is even more difficult.
Lack of strong documentation support, the official documentation is not clear enough, and the community documentation is not deep and wide enough (at least in the Chinese network).

As the times continue to move forward, it is increasingly necessary to solve some of these problems. I have helped several customers solve their needs for customizing pdf.js, such as loading PDF fragments, reading and storing annotations through a database, customizing specific special annotations, and solving bugs they encountered during the integration process.

Over a long period of time, I have communicated with many of my clients. I realized that most of the problems they face are common problems with certain commonalities. From a technical point of view, they can be solved through code reuse. As for the remaining small number of individual problems, they can be solved through plug-ins and custom codes.

So I decided to develop an advanced version based on pdf.js. And set two basic goals. The first goal is to strengthen the API and documentation so that developers can smoothly integrate pdf.js into the system they are developing. Front-end developers can use the API to operate the PDF reader, and back-end developers can persist various information in the PDF reader and return it to them when the front-end requests this data. The second goal is to develop some functions that are needed by the market but have not yet been developed or are not perfect, such as a richer annotation system, PDF permission management, image and text extraction, customized watermarks, etc.

But when I tried to do this, I found that it was not only very difficult, but also very ineffective. I used a tool to scan the source code of pdf.js and found that its code volume was actually more than I thought. If blank lines and comments are counted, its total code volume is about 200,000 lines. Even if blank lines and comments are removed, the total code volume is more than 100,000 lines. At first, I developed it for two to three weeks on this basis, and encountered many more problems than I expected at the beginning. On the basis of the existing code, even if it is just to achieve some basic goals, it is very difficult. For example, when I tried to change the PDF reader from the up and down sliding style to the page turning style, I found that not only a lot of code needs to be modified, but such changes will also affect other parts and bring potential bugs. And even if I spent a long time developing the functions I wanted, I might not be able to provide freely customized interfaces and APIs to developers, and even the information about function parameters in the source code is difficult to inform people who are willing to read the code in a convenient way.

After a short attempt, I found that I could not solve the seemingly simple problems mentioned above with simple methods. In fact, if minor improvements could solve all these problems, I believe this job would have been done long ago. Even if it is not the pdf.js team itself, there will be other developers active in the community to complete this task.

So I prepared to make some major changes. I planned to refactor pdf.js directly with TypeScript, retaining its core logic for PDF document processing, and refactoring its code related to displaying PDF on the web. The relevant tool chain and development style should also keep up with the times. I decided to abandon npm, remove gulp, and replace them with pnpm and vite. The traditional single module style is no longer used, and the multi-module approach of monorepo is a better choice.

I used to focus on the backend, and only occasionally wrote front-end, so I didn't have a deep understanding of front-end development, and I knew very little about the front-end technology ecosystem. But I still have a lot of experience in refactoring medium and large projects. I have refactored business systems such as warehouse management systems, and big data systems such as knowledge graph systems. In general, there are challenges in refactoring, and there is a period of pain, and this period of pain can even be said to be not short, nor easy. From the beginning of the reconstruction of a system to the smooth operation of this system, for a long period of time, there is almost no output of new functions, bugs may be strange, and difficulties are one after another. But when this period of pain is over, the whole project begins to see the light. Bugs that could not be located before can now be located. Functions that could not be developed before can now be developed. The low development efficiency has now been greatly improved. Various mainstream components that could not be connected before can now be easily connected. Therefore, if we want to fully tap the potential of pdf.js and allow developers to perfectly integrate it into their daily development, a thorough reconstruction is inevitable.

I think pdf.js does not perform well in the aspect of accessing business systems, mainly because it is not designed for the Chinese market alone. From a product perspective, its positioning is not a library for developers to call, but a tool for users to view PDF. pdf.js does a very good job in being a PDF viewing tool. It has also been integrated into many tools, such as VSCode, IDEA, chrome, etc. This allows users of these tools to easily view PDF on these tools. For ordinary computer users, they can also use chrome to view PDF directly without installing any other viewing tools. In contrast, every tool has its own strengths and weaknesses, and pdf.js cannot perfectly take into account both developers and users. For developers, it is only a little aggrieved. It is possible to integrate pdf.js, but the effect after integration is not so good.

When I refactored pdf.js, the first thing I had to do was to re-establish its positioning and goals - it does not directly serve users, but developers. Developers should be able to open a PDF with simple code as shown below, and customize their PDF reader through a series of configurations, rather than having to embed it through an iframe.

const viewer = WebSerenViewer.init('app', {
  viewerScale: 0.7
});

viewer.open({
  url: 'compressed.tracemonkey-pldi-09.pdf',
  verbosity: VerbosityLevel.WARNINGS
}).then(() => {
  const controller = viewer.getViewController();
  bindEvents(controller);
})

function bindEvents(controller: WebViewerController) {
  document.getElementById("pdf-page-up")?.addEventListener("click", () => {
    controller.pageUp();
  })
  document.getElementById("pdf-page-down")?.addEventListener("click", () => {
    controller.pageDown();
  })
}

For a single function, what I want to provide is not a specific button or icon, but the API, callbacks and various events that developers can operate.

For developers who want to debug, customize, and contribute source code, I should provide mainstream tool chains, clear parameters, clear calling relationships, etc. I should ensure that they can understand, debug, and modify relevant code at a low cost.

After spending more than 100 days on this, I have made several key steps in these matters. The main languages and tools used in the code have changed to TypeScript, pnpm, and vite. The code development style has changed to a multi-module monorepo:

The parameter types of all functions are clear, and hard coding has been eliminated one after another. The overall code quality has been improved to a certain extent. And the most basic demo has also run through:

In this example, I used the initialization method in the previous code to create a PDF reader with the 'init' method, opened a PDF file with the 'open' method, and bound the previous page and next page APIs to the relevant buttons.

The whole process was full of challenges. When I wrote a bash script to simply and roughly change the suffix of all files ending with js to ts, there were more than 20,000 direct errors. For nearly two months, I kept fixing these errors one by one like Yugong moving mountains. After I fixed an error, several new errors might pop up. For example, after I clarified the parameters of a function, the previously hidden errors such as "The object has no xx attribute" and "The object may be null" also appeared. Therefore, the actual number of errors fixed is more than 20,000.

In the process of fixing the error, I also found many problems such as irregular writing and coupling. For example, a certain section of code arbitrarily passed parameter types that did not conform to the JSDoc description just for convenience; the reflection was used arbitrarily, resulting in a broken reference chain between codes; hard coding; confusing call relationships, etc. I changed them all. For the process-oriented writing, I also changed it to object-oriented. The following is a comparison of the code before and after the rewrite, before the rewrite:

handler.on("GetPage", function (data) {
  return pdfManager.getPage(data.pageIndex).then(function (page) {
    return Promise.all([
      pdfManager.ensure(page, "rotate"),
      pdfManager.ensure(page, "ref"),
      pdfManager.ensure(page, "userUnit"),
      pdfManager.ensure(page, "view"),
    ]).then(function ([rotate, ref, userUnit, view]) {
      return {
        rotate,
        ref,
        refStr: ref?.toString() ?? null,
        userUnit,
        view,
      };
    });
  });
});

This code listens to the "GetPage" event, but the parameter type of this event is unknown (the type of the parameter data in function(data)), and it takes a long time to analyze. After listening to this code, pdfManager calls the get method of rotate in page, and directly uses such a hard-coded + reflection method to do it. Such code is not easy to modify and is prone to problems. For example, when someone accidentally changes the name of rotate in page, the code at this place may become a missed point and cause errors.

After the adjustment of TypeScript, all parameters are clear, the call is obvious, and the association between page and rotate has become a strong association:

handler.onGetPage(async data => {
  return pdfManager!.getPage(data.pageIndex).then(async page => {
    return Promise.all([
      pdfManager!.ensure(page, page => page.rotate),
      pdfManager!.ensure(page, page => page.ref),
      pdfManager!.ensure(page, page => page.userUnit),
      pdfManager!.ensure(page, page => page.view),
    ]).then(([rotate, ref, userUnit, view]) => {
      return { rotate, ref, refStr: ref?.toString() ?? null, userUnit, view };
    });
  });
});

There are many more changes like this, and I will discuss these issues in detail and share my experiences in subsequent blogs.

After I completed the basic refactoring, the code could not be run directly. Once it was run, many runtime errors would be reported. At this time, the code base had been compiled. My previous work included refactoring some large files and methods, modifying Record to Map in large quantities, and unifying null and undefined in the project. These works brought a lot of bugs. It took more than a day to locate and solve several of the bugs. After fixing these bugs, my refactored code finally ran through. But this is not enough. In order to show readers a most basic case, which is the page turning case mentioned earlier. I did a lot of work to extract the parameters and APIs to ensure that if a developer wants to use this library, it can directly control the created PDF reader through configuration and API.

Although the code has been run, it is still a long way from being truly usable in production. I will continue to spend some time to conduct a rich test on the new code to ensure that all PDFs in pdf.js perform consistently on the old and new codes. The rewrite of APIs and callback events is not yet complete, which is also very important for developers to control the readers created with this library. Maybe I won't develop all the points at once. But it is still necessary to develop those key points well. After all this work is completed, I will release the first version with supporting cases, codes, and documents. Make sure this library is efficient and easy to use.

I have hosted the code for this project on Github:
https://github.com/xingshen24/seren-pdf

Debugging this library is relatively simple. Just use pnpm recursive install to install the dependencies, then go to the packages-private/seren-viewer-develop/ directory and run it with pnpm run dev.