How to write a drag calendar component

Kid Ant Financial · Data Experience Technology team

This article will introduce how to write a drag-and-drop calendar component, focusing on the calendar component function mining and some thinking about the development process, coding part will introduce the implementation of the core part. The code will also be out for you at the end.

Results demonstrate

Let’s take a look at the final implementation effect of the project:

The early stage of the research

To make a drag-and-drop calendar component, you have to look around the market to see what the existing calendar component looks like. The main purpose is to collect features and avoid reinventing the wheel. I investigated the calendar controls of Google calendar, tower, fullcalendar, teambition, webmail and so on. Among them, Google Calendar and FullCalendar are relatively good users. The following is a GIF of their usage:

Google calendar

fullcalendar

Functional comparison

Here’s a comparison list of feature details:

From the comparison of the table, it can be seen that the functions of these relatively good calendar components are not fully implemented, and some details are not well done. The only open source calendar I can find is FullCalendar, but it is the jquery version, and the function implementation is not good, and there are many mistakes in the details, so I decided to write one myself (finally found the reason for repeating the wheel ~).

function

According to the previous research, a good drag-and-drop calendar control needs to achieve the following functions:

• Drag and drop existing events
• Double click to add event
• Drag events left and right
• Drag a blank area to create a new event

In addition to functionality, there are user usability details to polish:

• Drag shadow effect of an existing event
• Drag Existing events are hidden by drag
• Drag left and right preview and shadow effects
• Intelligent layout of events, including stacking and redundant cleaning after line feeds
• Drag state processing (offset calculation and dragLayer rewriting)

coding

After the demand survey, the project entered the coding process, and was mainly based on REACT and React-DND. The overall steps of coding include:

• Draw a calendar
• Draws events based on the event list
• Event layout, stack effects, and line feed cleanup
• Make events draggable
• Make events drag left and right
• Make blank areas draggable
• Drag and drop shadow processing is too long to elaborate, we look tired, LET me talk about the key implementation points.

Draggable area

The react-DND drag-and-drop capability is mainly used. The four colored circles in the figure correspond to four drag-and-drop component sources respectively.

• Purple is the event itself
• Red is the drag area to the left
• Black is the drag area to the right
• Green is the area of drag and drop (this is the most interesting design, using drag and drop behavior to simulate the selection ~)

The corresponding drag events are processed for these four sources. The hover events defined for each source can handle different shadow effects. Define layer to handle mouse preview effects when dragging and dropping.

Intelligent event layout

Event classification

Is to divide the day’s events into five categories as shown in the picture:

• 1 is the day before, and the day after
• 2 is the day before and the day after
• The day before, the day without
• Four is no day before, no day after
• 5 is a blank fill event

When rendering a day, first render 1 and 3 with the previous day because they have a stable index, then render event 2 according to priority, then render event 4 with no space left. The index of 1 and 2 is then passed to the next day. This will give you a better layout.

New week event cleanup

As shown in the picture, WHEN I detect the beginning of a new week, I will first clear the space in the middle. The events are then sorted by priority.

After the whole happy coding process, I found myself rejecting the code. Why don’t you look back after you’ve written your code and debugged it? Oh, because it’s really not pretty! In other words, the code is inherently poor quality.

The quality of

Software quality can be divided into external and internal. External qualities include:

• availability
• correctness
• Robustness,
• .

External quality is the only software feature that users care about, and what I have been pursuing and polishing above is actually external quality of software. Users are cool ~

But part of me rejected the code I just wrote because there was something wrong with the inherent quality of the software, which included:

• Readability (probably the most important)
• maintainability
• Accessibility (now supports custom forms and feels good)
• .

Writing found that the code is not easy to understand, bear a closer look found:

• The code is redundant
• The subroutine was not named properly
• Bad code structure
• Undefined CSS name
• .

What do you want to do? Let’s refactor

• Clean up the code structure and make the whole process clear
• Rethink subroutine naming, write comments
• Consider external interfaces to enhance accessibility
• .

After a wave of refactoring, why is there a problem with internal quality?

The pursuit of quality is endless, both internal and external. Many techniques can improve quality: complementary test cases, good programming style, sound annotations, layered abstractions, sound interfaces… It’s impossible to have all the features behave perfectly. Finding a solution based on a set of competing goals is what makes software a true engineering discipline

design

Why is the quality bad? Of course, because of the design problems, the design is found in the development of the design does not conform and constantly adjust the design, resulting in the destruction of the very important “system integrity” in software (the myth of the man-month is much admired emphasis). And that ultimately leads to poor quality.

So why isn’t it well designed? I guess it was because I couldn’t resist the temptation to start coding! After thinking about how to drag and drop existing events, I couldn’t wait to start coding. No more detailed design was carried out. In fact, at this stage, MY brain is already closed off from subsequent needs (for the sake of the intellectually manageable self-protection). After the implementation of dragging and dropping the existing events, I began to think about how to drag and drop the blank area to create a new one, and found that the existing design needed to be adjusted. And then I had a good idea and started coding again. Incomplete design cycles lead to a decline in quality.

In fact, the generation of software and the real food chain, demand -> design -> code. One ring after the other, the closer you get to the upstream, the bigger the impact. Generalization is that every design I do is based on incomplete requirements.

What should you do? You should design as versatile as possible from the very beginning. The design time invested in the initial stage should be increased.

Iterative development

Some of you may look at this and think, no, design is inherently a “sinister problem” (that is, a problem that must be solved or partially solved to be defined). So iterative development is fine. The advantage of iteration is risk aversion. Constantly try at a fraction of the cost to reduce the risk of failure. So iterative development must be accompanied by constant refactoring to ensure quality.

For this question. I think it depends on the scale of the project. Look at the manageable complexity that we have in mind. It might be better to prototype and experiment, and then redesign the whole thing immediately, and then code it, which would be cheaper.

After the verification of some difficult points in the first iteration, the overall design can be carried out, which can reduce the necessary reconstruction links after iterative development, reduce the overall development cost, and improve the quality of the project.

conclusion

This article shared the implementation process of the drag-and-drop calendar component, the coding details, and thoughts on the overall development. The reason for thinking about development is that methodologies are applied to projects of different sizes, and for small projects, the application of methodologies can be casual and instinctive. There are methodologies that can be used selectively to reduce development time and improve product quality. Finally, the attached code portal, specific access to use can see the project README, or quite a number of defects, welcome to mention PR~

If you are interested in our team, you can follow our column, follow Github or send your resume to ‘tao.qit####alibaba-inc.com’.replace(‘####’, ‘@’)

Original address: github.com/ProtoTeam/b…