Why did we choose React and TypeScript for QueryPie?
QueryPie development #8: Background on Front-end Developing
📑한국어(Korean Version)- https://medium.com/p/111d03597510/
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 now 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.
“Why did I write this before the launch? Shouldn’t I have written about the background of how I developed this application?”
In fact, 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 new 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 own 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!
“I wanted to work hard on open source and become famous.”
I don’t know why I wanted to be famous. 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.
But there were more struggles than enjoyment. The distance between doing what I enjoyed and making money from it didn’t get any 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:
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 to help me. 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 around the world.
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 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 developing. 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.
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. In fact, such a method of development is not hard to find today. Several software 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 in the future. 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 own AX5UI. In this way, I created an application compatible with JAVA using JXBrowser.
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 come to the conclusion that the current application has some goals to achieve, and these top-three concerns have caused me some sleepless nights:
- Can you make changes to the application as quickly as desired at any time?
- Can we make DOM controls more convenient and secure?
- Can we check if there is a problem in real time?
Problem 1. Complexity of Adding and Changing Features
For simple applications, it is often effective 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 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 that occurs within the component.
Although this method of component-focused screen development was familiar and comfortable, the situation was different with our prototype.
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.”
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 real development environment.
So we had to find a good 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 template engine, there was a flickering phenomenon in DOM Node. In addition, the events bound to DOM Node had a problem of unbinding before the screen was re-drawn and then binding again.
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 I could, but I couldn’t find the perfect balance.
Problem 3. Lack of Error Reports
If the owner of a newly opened restaurant is able to know and understand everything the customer feels, then that restaurant will be a huge success. But it is not easy to gauge the satisfaction level of customers 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.
window.onerror function usedAfter 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 due to the problems encountered while making the prototype, and after some discussion with Woo, I realized there was need for a change.
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 basic UI components needed to configure the application could be resolved by choosing a well-crafted UI Framework for React. But I wanted to personally make DataGrid myself.
DataGrid after Refactoring Three Times
DataGrid has undergone a total of three refactoring sessions. The first time, I recreated all the codes with the introduction of TypeScript. The second time, I removed the Redux and turned it into a dependent component using ContextAPI. And finally the third time, I organized the internal state and external props.
Making QueryPie with React & Typescript
So let’s move on to the main topic, and look at how the three concerns that I encountered before can be resolved by using React.
Solution 1. 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.
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 actually meet can be huge 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 as shown below and 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 major problems.
The benefits of module coding from using Reacts are even greater 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 important than the arithmetic value.
I’m sure everyone has heard how React Virtual DOM is effective 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.
As you can see in the video above, scrolling shows that the element to be printed is being rebuilt in the table. There are also 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 changed every time it scrolls. Developing with React allows the user to feel that the data is changing more 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 for their project.
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 developing 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 definitely 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 as an inconvenient tool at least 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.
When using UI Framework such as AntD, the most difficult aspect is memorizing which attributes you have and how to use them, because you don’t use your own code. (*I‘m not sure if there are different methods these days, but the old people memorized it all…)
This method can be convenient because VSCode is easy to identify and helps reduce errors.
(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 all different for each developer.
But the era of craftsmen where outstanding individuals produced everything is over. Teamwork is more important now. In the future, software will become more complex and capable of doing more, so the method to a code must be understood and created by a group. This is easy to do if we can export the code we create 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 is 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. In fact, 90 percent of development documents record which factors the function uses and which results it 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 own loose ends by sharing a link recommended by Woo.
Wrap-up: Let’s be flexible with changes
It’s really difficult 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 at the beginning, and I sincerely hope that more people will use our work.
