QueryPie development #8: Background on Front-end Developing

The fastest thing in the world is time. It feels like just yesterday when I started my first Sprint. I was so excited about what was going to happen in the future!

And the third sprint is already over.

After wrapping up my second blog, it suddenly occurred to me that the start of the development subject was wrong.

Version Report of the QueryPie Development Team, which is working incredibly hard

“Why did I write this before the launch? Shouldn’t I have written about the background of how I developed this application?”

Developing QueryPie was a job that could not be planned, designed, and developed as quickly as creating a customer’s homepage or ERP (Outsourcing service or SI) that I have made in the past. So I thought it would be nice to write down the difficult problems and discoveries I experienced while developing. I also want to talk about the development background.

So today, I want to go back in time and tell you where all this started.

Start of Open Source Activity

AXISJ Project

I started doing open source and outside activities with my JavaScript UI Component, which I created in 2013. It was an open-source project named AXISJ. I’d never before worked so hard on something that didn’t make me money. I even had to spend more of my own money!

  • The AXISJ project has been renewed and reborn as a project called AX5UI.

“I wanted to work hard on open source and become famous.”

I don’t know why I wanted to be famous. But it was probably because I wanted to get attention from the people in my life. I was never a genius, but I was able to continue to achieve results because I was confident in my ability to work harder than anyone else. So I joined several developer contests and finally felt like a very useful person after winning some awards.

Competition Award Certificates in the office

But there were more struggles than enjoyment. The distance between doing what I enjoyed and making money from it didn’t get shorter, and it wasn’t easy to maintain a positive outlook. Of course, I never regretted my choice, and being able to meet amazing people through my experience with open source made it all worth it.

In fact, I want to briefly talk about the people I met and how we came together.

New Partners and the beginning of CHEQUER:

From the left: Benjamin, Brant, Woo

When I had just started working with open source, it was Benjamin who first connected with me. He was a developer and the CEO of a database management tool called SQLGate. His affinity was beyond my imagination. Due to his openness, I felt more inclined to encourage everyone who sponsored the AXISJ project. Thanks to Benjamin, I had many opportunities to meet good people.

Next came Brant. I had never met someone like him before. He was interested in computer programming since he was an elementary school student. But he dropped out of high school to continue studying on his own. He was a gifted programmer that joined KAKAO(a very well-known software company in South Korea) as a software engineer and later got his Master’s Degree at KAIST (a prestigious college in South Korea). After working with KAKAO for a few years, he left the company to start his own. I joined him, and together the two of us created CHEQUER.

Because the 2 CHEQUER founders were developers, we were more focused on how we would develop rather than what we would develop. Shortly after the company was created, Benjamin offered to join us. He was ready to stake everything on this new company and brought SQLGate with him. The three of us became the founders of a company that planned to make SQLGate the number one software used by developers and data analysts worldwide.

Then came Woo, who played a crucial role in our development with React and TypeScript. Before I met him, I always thought about learning new development languages such as React, VueJS, and AngularJS due to the limitations I experienced when developing. Woo was also an open-source developer, and his advice was of great help to me. He was like an encyclopedia! He helped me find my footing and showed me that React was better for my style of development. Encouraged by him, I studied React tutorials and made DataGrid.

“Our background story is pretty long, but I tried my best to make it short. As I write this and think back on my experiences, I wonder, ‘What was the purpose of all that alcohol we drank together?’“

Making a prototype for SQLGate 5

SQLGate was a software that only worked on Windows. But in my mind, it should have been a cross-platform application to become software used world-wide. So I had to think about how to create new software that worked on any OS.

SQLGate (http://www.sqlgate.com)

I thought that by using NodeWebkit or JXBrowser we could make the software we wanted. We used WebView as a Render, which frees the View portion of the application from OS dependency and can be developed by utilizing the experience of Web technology. Such a method of development is not hard to find today. Softwares such as Slack, such as Slack, VSCode, Atom, and GitKraken use this method to support multiple Operating Systems.

“In the past, these hybrid types of applications did not receive much attention because they were slow to respond to UI and did not effectively handle OS resources. But these days, they are overcoming performance issues since hardware performance has accelerated.”

Even if we used WebView to develop, we knew it was impossible to replicate the capabilities of the existing SQLGate functions in our newly created software with the resources available to us. For me, it was also a priority to see how efficient it was to develop in this manner.

So I decided to make a prototype under the name of SQLGate 5:

I wanted to create a prototype for two months and see how we could orient ourselves. I needed to check if we had the right idea. With the back-end developed using JAVA as the base, front-end used jQuery and my AX5UI. In this way, I created an application compatible with JAVA using JXBrowser.

SQLGate 5 Demo

After finishing the prototype, the result was rather good. But as a front-end developer, I was worried. If I lived as an application developer, I would worry about it until I died. But I have concluded that the current application has some goals to achieve, and these top-three concerns have caused me some sleepless nights:

  1. Can you make changes to the application as quickly as desired at any time?
  2. Can we make DOM controls more convenient and secure?
  3. Can we check if there is a problem in real-time?

Problem 1. Complexity of Adding and Changing Features

Process flow for simple applications

It is often useful for simple applications to create components (like Search Toolbar and Contents, as shown in the image above). If the component is bundled with features that are expected to be user actions, it can easily configure a high-completion screen when making a new screen in the application or making a new application. This can be done by pasting the code, transferring or importing inputs to the component, and aligning the event handler within the component.

Although this method of component-focused screen development was familiar and comfortable, the situation was different with our prototype.

Process flow of complex applications

The types and number of components were different from the websites and web-admin systems that we used to create, and so was the function of processing the actions of the components.

The problem of large numbers was overcome with honed and experienced development skills. But it became like a web of interaction between functions and components, and I was afraid that side effects would occur whenever I added or changed functions.

“The side effect problem can be overcome by using the test code.. but correcting the error was so complicated and difficult that I felt like I was trying to re-draw the Tokyo subway map in my head every time.”

Tokyo Subway Map

Problem 2. Poor DOM Control

Since the software we create is a tool that can look up various information in the database and send queries to view results that users want, we naturally have to do a lot of work to change the DOM.

That’s a lot of data being printed out.

The quickest way to add/change/delete DOM Nodes is by using VanillaJS (developer slang for using Standard APIs without Framework or libraries). But this way is rather unproductive in a real development environment. The best way to use standard APIs without frameworks or libraries is to create screens without the help of template engines in the actual development environment.

Framework DOM Operation Performance (https://krausest.github.io/js-framework-benchmark/current.html)

We had to find an excellent and easy-to-handle template engine and manage it so that the template codes needed for each screen were not wasted. Unfortunately, getting a list of templates in a design document and keeping them in your head has limits.

And the bigger problem was that after converting the template code into a template engine, there was a flickering phenomenon in DOM Node. Also, the events bound to the DOM Node had a problem of unbinding before the screen was re-drawn and then binding again.

Template Engine Process

In the meantime, we worried about whether Garbage collection was doing well and if there was a memory leak, but it was impossible to check every single aspect in a short time.

I thought I could overcome this problem if I split and managed as many targets as possible, but I couldn’t find the perfect balance.

Problem 3. Lack of Error Reports

If the owner of a newly opened restaurant knows and understands everything the customer feels, then that restaurant will be a huge success. But it is not easy to gauge customers' satisfaction level from different backgrounds when it comes to aspects like the taste of food, enjoyment of atmosphere, cleanliness, music, and service.

But I wanted to make it possible to know as much as possible in the applications that we created. And as a creator, I wanted to know whether there were any errors or inconveniences during usage. But since I couldn't ask users directly, I had to rely on the errors delivered to the server using the window.onerror handler.

After running into these problems, we considered a new development environment. That’s how QueryPie was born.

Switching to React & Typescript

jQuery: developed for 10 years

I have used jQuery since 2009. Because web browser fragmentation was so severe at that time, jQuery was used by many people.

It was really hard to conclude that we should stop using jQuery, which has been around for nearly a decade. In my case, I made AX5UI alone for about a year by using jQuery! So I was anxious about leaving my comfort zone to switch to a new environment.

But after talking to Woo about the problems while making the prototype, I realized that it was time for some kind of change.

AX5UI Commit Graph

So I began to consider using React to develop. At first, I used the existing UI components to operate in React, but that meant that I would have to use jQuery in the React code (which is just unbearable as a developer), or I had to recreate all the existing UI components.

Of course, the necessary UI components needed to configure the application could be resolved by choosing a well-crafted UI Framework for React. But I wanted to make DataGrid myself personally.

DataGrid after Refactoring Three Times

axui-datagrid (https://axui-datagrid.jsdev.kr/)

DataGrid has had a total of three refactoring sessions. I re-created all the codes for the first time with the TypeScript introduction. For the second time, I removed Redux and turned it into a dependent component using ContextAPI. And finally, for the third time, I organized the internal state and the external props.

Making QueryPie with React & Typescript

QueryPie Prototype

Let’s move on to the main topic and look at how the three concerns I encountered before can be resolved using React.

Solution 1. The Flexibility of Adding and Changing Functions

Let’s consider the situation of adding functionality to applications while developing with React and TypeScript. Suppose that with a particular screen created, the requirements change and that you need to add search criteria to the list.

Screen with a List

In this case, you can add a separate Filter component without adding a search UI to the existing List component, and then use a combination of List and Filter. The code in the picture above is a simple form that is only a few lines, but the components we meet can be vast and tricky.

So you have to modify Filter to receive Filter Props from the List component and create a new filter component so that the filter value entered in the Filter is transmitted to the List component. In List, you can output the List according to the Filter without considering what happens outside the List.

This method of development can minimize the dependence of the component. And when adding or changing the function, you can create more flexible and less ‘side-effect’ code.

With the addition of new features, changes in the existing code List component are minimized. They are not dependent on the newly added Filter component, so even if the future List is combined with other components (in most cases), it can be reused without significant problems.

The benefits of module coding from using Reacts are even more significant with the use of ES6 and TypeScript. The destructuring assignment and arrow function added from ES6 allow the JSX code to be concise. TypeScript allows the specifications of the Props and Arguments used by the components and functions to be used without having to study them separately.

The QueryPie development team uses Mobx and MST. If the model and component are separated, the model and API communicate to change the Store of the model, and the component can proceed with development only by looking at the data contained in the model.

For more information, check out Woo’s article here.

Solution 2. Convenient and Secure DOM Control

As we can see from the Framework DOM operation performance mentioned above, controlling the rendering using React is not the only way to increase the rendering speed.

But the difference in speed is much smaller than the blink rate (100~150ms on average), and I think the UX experience is more critical than the arithmetic value.

I’m sure everyone has heard how React Virtual DOM is useful because of its fast rendering. It’s hard to explain in detail because I didn’t create Virtual DOM, and I don’t know much about the internal principles and structures (though I hope one day I’ll be able to). So I’ll discuss the difference between using React to develop versus my old method.

AX5UI-grid created with jQuery

As you can see in the video above, scrolling shows that the printed element is being rebuilt in the table. There is also a flickering phenomenon when scrolling quickly. This is because browsers such as IE do not direct the landing as the wheel is scrolled, but instead perform a throttled process to solve the slow scrolling issue.

So how is the DataGrid made in React any different?

React finds and changes each part of the DOM to be replaced every time it scrolls. Developing with React allows the user to feel that the data is changing naturally and smoothly since the structure of the DOM doesn’t change, and only the contents or attributes change.

Since the developer does not directly control the speed of which React’s render function runs, there is no need to worry about frequent changes in the data.

React is already being used in many global services, so many people around the world have been testing it. Even though we haven’t met them personally, we are sure that the react development teams are using so many resources.

Solution 3. Improving Error Reports

Before we discuss error reports, let’s talk about when and what error is generated by the developer.

“Actually, we’re still working on our error reports, so it’s hard to go into too much detail. Sorry. :( ”

Most of the errors that pop up during development are due to simple mistakes. You might stumble on many errors in one day, and find out eventually that most are due to small typos.

We could save a lot of time if typos didn’t exist. And using TypeScript was the most satisfying method I’ve ever tried that prevents typos.

(1) VSCode + TypeScript

Six months ago, I was an IntelliJ user. IntelliJ is a powerful tool still used by many developers, but it is considered an inconvenient tool for front-end developers who use React and TypeScript.

When developing with VScode, components used for JSX tags, component properties, functions, and factors of functions can be developed as pop-ups.

AntD Tree Component Information Check

When using UI Framework such as AntD, the most challenging aspect is memorizing which attributes you have and how to use them, because you don’t use your code. (*I‘m not sure if there are different methods these days, but the older adults memorized it all…)

This method can be convenient because VSCode is easy to identify and helps reduce errors.

AntD Tree component auto completion

(2) Shared code: All variables and functions can be defined

Many people have successfully developed with JavaScript for a long time, and what sets those people apart is their excellent application. It’s a key factor in developing JavaScript by ES5.

Though there are many ways to make Class, and other styles of coding are different for each developer.

But the era of craftsmen where outstanding individuals produced everything is over. Teamwork is more important now. In the future, the software will become more complex and capable of doing more, so the method to code must be understood and created by a group. This is easy to do if we can export the code we build into a module and let other developers use it.

The code above is part of the type definition file of axui-datagrid. When this definition and build are given the criteria declaration:true, a d.ts file is created.

Developing this way leads to less need to organize documents separately for the developed work. Ninety percent of development documents record which factors the function uses and which results in its returns. Though if the documents are not updated properly, they will be useless.

(3) Error Tracking


In fact, after a certain understanding of how React works, I believed error tracking would be possible to any extent. I thought this way because all Rendering is happening in React.Component Class(but I’ve never attached it).

Rather than going further into detail about error tracking here, I’ll wrap up my loose ends by sharing a link recommended by Woo.

Wrap-up: Let’s be flexible with changes

It’s tough and painful to change old familiar habits and explore new methods. But there is no such thing as permanent in the field of software where new technology always replaces old technology.

What we like and are familiar with now will one day be replaced with a new and more convenient way. So what should we do? Go with the flow! Don’t stop just because your favorite trendy rhythm has changed. Accept the change as a new joy to explore instead of a burdensome procedure to learn.

SQLGate is now trying to start a new journey with QueryPie. I am happy to be able to contribute a little bit in the beginning stages, and I sincerely hope that more people will use our work.