QueryPie Development #4: Starting with Front-end Development

I’ve had an idea stuck in my head for the past year.

That idea was to create a new web application - a new web application that can run precise database queries on Windows, Mac and Linux. It would be a beautiful application developed with the latest web technology.

As a front-end developer for the better half of my life, I’ve always been a firm believer that HTML/CSS/ES would be the most extended survival core technology. Nowadays, we use web technology so much with applications that I knew pursuing that path was the right way to go.

Apps made using Electron (source: https://electronjs.org/)

To begin my journey with web technology and application development, I started using the popular open-source framework Electron. In this framework, I used Webview as a renderer and bundled components made from React into a Webpack to create a Single Page Application (SPA).

The new application was named QueryPie.

The QueryPie development team decided to plan the issues needed for application development and manage them on a Sprint basis, bundling up tasks into two-week segments. At the end of each Sprint, we decided to write a review of our experiences during the Sprint.

Today, I want to talk about how the most basic layout of QueryPie was born.

Process of QueryPie Layout development:

First Layout: Slack Style

Our first design was very similar to the Slack layout

The above image is the layout we decided on when the new application was first proposed. When I drew this first layout, I thought it would be better to arrange windows from left to right to access information, database and object information, Query editor, and finally, execution results. As you can see, this design has a simple structure that has components to enable smooth writing of SQL queries and easy viewing of the results.

But after I made it, I realized that it felt a lot like Slack. Then, Slack was one of the most successful applications on Electron. I admired the design so much that I had unknowingly followed it. And although I liked the simple style, I felt a lack of space to check important object information for a database tool, like tables, views, triggers, and functions. So it was time for some revisions.

Second Layout: Sequel Pro Style

Second Layout Reference: Sequel Pro

The second layout we considered was the Sequel Pro style. Our CEO, Brant Hwang, favored this style the most. Choosing this type of layout had the advantage of intuitive viewing structures, content, relationships, triggers, and information in terms of tables (objects).

To maximize this intuition, the list of objects on the left is presented in a list rather than in a tree. A large icon on the top bar is placed so that the desired information in the selection table can be viewed like a menu on a website.

The first impression I got from this layout was that it was awkward. This configuration seemed strangely offbeat, perhaps because I was so accustomed to the UX in Windows software. But the more I looked at it, the more it grew on me.

Database management programs are also adopting increasingly simple designs. While there may be differences between the jobs that require accessing and working on databases, the most significant common factor is the need to access data in a table or object. Writing a complicated or long SQL query appears to be a relatively smaller percentage of the work.

This is because, for complex applications, Object-Relational Mapping (ORM) is less likely to be used to create long or complicated SQL sentences. For simple application development, there is often little relationship between tables.

However, there are still disadvantages to this design. It is challenging to verify object information while writing SQL sentences, and it's inconvenient because multiple queries cannot be written at the same time. The top bar's size was also so large that I couldn't help but feel like it was taking up a lot of space. So we moved onto the next idea.

Third Layout: QueryPie Style

Third Layout: QueryPie

After considering all the positive and negative points of the previous designs, the third layout was created. Numerous versions of this layout had to be bench-marked and re-painted dozens of times. We went through so many variants until we settled on this one. And although it is not yet fully established, it is much more robust than the previous proposals.

In this layout, the SQL editor was placed in the middle and managed as a tab to make writing SQL easier. Object information is collected and easily viewable in the window on the right side. Many of the front-end work had to be reworked because it was already underway before the third plan was determined. Thankfully, the changes didn’t take much time because only the React components needed to be reconstructed.

I can’t pinpoint the disadvantages of the third layout. That doesn’t mean that it’s perfect, but we need to believe that the design we chose is the best one in the galaxy to enjoy the development period. So we do: it’s the best!

However, I am confident that I will continue to make the best efforts for better UI/UX. The planning/design team is experimenting a lot to find the correct balance for QueryPie. And CHEQUER’s powerful front-end development team is ready to accommodate changes and develop any layout conveniently and beautifully flexibly.

Ant Design Customizing: Modal and Form Item Validation

A well-planned UI framework is essential for efficient front-end development. Especially for the React Developer, there is no need to reiterate the importance of Framework. But there are so many UI frameworks in the world.

I also dream of creating a perfect and ubiquitous UI framework that can someday be used by people all over the world.

Our Framework mainly utilizes Ant Design. I’ve mentioned in a previous posting why we chose Ant Design, which you can check out here.

So naturally, I started our project with $ npm i antd.

For a while, there were no major problems because I prepared everything in earnest, better than I ever had before. But it didn’t go as planned. Some parts had to be changed in detail, and we needed a lot of modifications to solve the problems.

Among the various problems I experienced, I want to share the contents related to AntD Modal and Form Item Validation.

AntD Modal Animation; Slidedown

AntD Modal Animation is a way to view where a user’s action occurs and how it gradually finds its place to the final destination. This animation takes a lot of work to implement, but it has been used without any complaints since it is already a well-made animation. This project gave me a different idea.

AntD Modal Animation

I was inspired when I started using the Visual Studio Code (VSCode). Many UI elements were sliding down from top to bottom in VSCode, even when there was no actual modal. It was then that I thought to myself, “Can’t we change it to sliding mode?” From the UI/UX perspective, it would be much more comfortable for users to see windows that function the same in an application that would always fall from the same location.

Another reason for this thought was that the most detailed UI Framework could not have given this level of consideration to its users as far as I know.

Was there an animation setting somewhere in AntD?

Eager to find some answers, I read AntD Modal’s API document. Although I have been developing software for more than 16 years, it is still difficult for me to read APIs carefully. And no matter how hard I looked, there was no information about Animation.

I had to find a hint. So I searched for the AntDesign store first for answers.

While looking at the AntD annotations for better understanding, I found myself frustrated because most of the comments were written in Chinese. So when I wrote my own annotations for QueryPie I was determined not to write them in Korean. I didn’t want another developer to become frustrated like I had been. But… Korean is easy for me while English can be a struggle, so I finally understood where they were coming from! :(import Dialog from 'rc-dialog';

As a result, I found that the AntD Modal has characteristics like ‘transitionName’ which you can find by using rc-dialog.

But soon, I realized that what I found was just the tip of the iceberg. To use animations to React, we need to be able to manage the state of animations. There are many ways to go to this. If you search ‘React Animation’ in any search engine, you will find tons of helpful articles and libraries.

Among them, the rc-dialog library we found had developed a similar operating principle as ‘react-transition-group’ (developed by the React Development team) so we figured we could implement the class of enter, appear, and leave in CSS.

Thankfully, it was easy to find. The Modal transitionName value is set to slidedown and the code above is added to the less file. When we redefined the CSS classes for each condition, starting with transitionName, the Modal appearance animation was changed, as shown in the image below.

When I look back this process, I think to myself: “Oh, it’s not a big deal. I really overthought such a simple process.” But I also feel that I need to continue studying to add a variety of animation elements in the future.

AntD Form Item Validation

My next challenge was file selection and validation. To create a form in AntD and check the input of the FormItem Value, fileDecorator can be used. If you add the rules option here, the rule automatically checks if the added FormItem value is empty and conveniently outputs the message.

However, the problem was that the input tools to be checked were not normal Input or Select. Here you have to select a file and then transfer the selected file, but the file input did not like the design.

So we decided to create a separate FileSelect input tool component.

When the Button is clicked, the FileSelect component generates an event in the referenced input file element. The change event in the input file element is detected and develops a user-selected file in a new form.

We left this created FileSelector under FormItem and received an onChange event. Using setFieldsValue, we passed the value from FileSelector to the FormItem value to solve the problem. The file selection is handled by the FileSelector component, and the existence of the input value is handled by the fieldDecorator. The fileSelector is responsible for printing it as if it were one body.

Closing Remarks:

From this initial process of developing the layout of QueryPie, we looked at how we implemented Modal and FormItem Validation using Ant Design.

After many difficulties and decision-making processes, we are now embarking on new application development. We are delighted to end our first Sprint and write a review. In the future, we will continue to solve many Sprints without a break and achieve our goals.

Tackling new challenges and new fields is always exciting for me. I find challenging myself enjoyable. Of course, there are many difficulties in the process. Still, the resulting sense of accomplishment is so addictive that all the hard times are usually lost beneath the memories of success.

Even now, I’m focusing on that thought. I want to wrap up this development log by imaging a day when I can finish the QueryPie project and see it succeed.

📃 Our next developer’s log will look at past and current trends to discuss how to implement in-application Resizing and Drag & Drop.