Как написать компонент календаря с перетаскиванием (с исходным кодом)

Об авторе Kid Ant Financial Data Experience Технологическая команда

В этой статье будет рассказано, как написать перетаскиваемый компонент календаря, с акцентом на интеллектуальный анализ функций компонента календаря и некоторые мысли о процессе разработки.Часть кодирования познакомит с реализацией основной части. Код будет выпущен для всех в конце.

Демонстрация эффекта

Давайте посмотрим на окончательную реализацию проекта:

Предварительное расследование

Чтобы создать перетаскиваемый компонент календаря, вы должны сначала посмотреть, из чего сделаны существующие на рынке компоненты календаря. В основном, чтобы собрать функции и не изобретать велосипед. Я исследовал элементы управления календарем для календаря Google, башни, полного календаря, teambition, веб-почты и т. д. Среди них Google Calendar и fullcalendar считаются лучшими для использования, ниже показана анимация их использования:

гугл календарь

fullcalendar

Сравнение функций

Вот сравнительный список функциональных деталей:

Из сравнения таблицы видно, что функции компонентов календаря, которые реализовали эти компании, реализованы не полностью, и в некоторых деталях они не справились. Можно найти только в открытом доступеfullcalendar, но он jquery версии, и функция реализована не очень хорошо, и в деталях много ошибок, так что планирую написать сам (наконец-то нашел причину повторения колеса~).

Функция

Согласно предыдущим исследованиям, функции, которые должен реализовать хороший перетаскиваемый элемент управления календарем:

• Перетащите существующее событие
• Дважды щелкните, чтобы добавить событие
• событие перетаскивания
• Перетащите пустую область, чтобы создать новое событие

Помимо функций есть детали по полировке юзабилити:

• Перетащите эффект тени существующего события
• Перетащите существующее событие Скрыть при перетаскивании
• Предварительный просмотр левого и правого перетаскивания и эффект тени
• Интеллектуальный макет событий, включая избыточную очистку после укладки и упаковки
• Обработка состояния перетаскивания (вычисление смещения и перезапись dragLayer)

кодирование

Спрос на исследования в процессе кодирования окончен, проект в основном основан на основе реагирования и реагирования. Общий этап кодирования содержит:

• нарисовать календарь
• Рисовать события из списка событий
• Приведение в порядок макета события, эффекты наложения и очистка упаковки
• Сделать событие перетаскиваемым
• Сделайте событие перетаскиваемым влево и вправо
• Сделать пустое пространство перетаскиваемым галочкой
• Перетаскивание теней Если говорить подробно, то статья слишком длинная, и все устали, я расскажу о ключевых моментах реализации.

перетаскиваемая область

Он в основном использует возможность перетаскивания react-dnd.Четыре цветных кружка на картинке соответствуют источникам четырех перетаскиваемых компонентов.

• Фиолетовый — само событие
• Красный — область перетаскивания слева
• Черный — область перетаскивания справа
• Зеленый — это пустая область для перетаскивания (этот дизайн наиболее интересен, поскольку он использует поведение перетаскивания для имитации выбора~)

Обработайте соответствующие события перетаскивания для этих четырех источников соответственно. Определение собственного события наведения для каждого источника может обрабатывать различные эффекты теней. Определенный слой может обрабатывать эффект предварительного просмотра мыши при перетаскивании.

Умный макет событий

классификация событий

Он состоит в том, чтобы разделить события дня на 5 типов, как показано на рисунке:

• 1 - день до и день после
• 2 нет предыдущего дня, есть следующий день
• 3 есть за день до, нет дня после
• 4 не предыдущий день, не следующий день
• 5 - пустое событие заполнения

При рендеринге определенного дня сначала рендерите 1 и 3, которые имеют предыдущий день, потому что у них стабильный индекс, а затем рендерите событие 2 в соответствии с приоритетом, затем 4, и рендерите событие 5, которое не может заполнить пробел. Затем передайте индекс 1 и 2 на следующий день. Это позволит улучшить планировку.

Уборка событий новой недели

Как показано на рисунке, когда обнаруживается, что начинается новая неделя, я сначала очищаю пробел в середине. Затем события сортируются по приоритету.

После всего счастливого процесса кодирования я действительно обнаружил, что отверг этот код в своем сердце.Почему я не хотел оглянуться назад после написания кода и его отладки. О, это потому, что это действительно плохо написано! Другими словами, плохой внешний вид — это неотъемлемое низкое качество кода.

качественный

Качество программного обеспечения можно разделить на внешнее и внутреннее. К внешним качествам относятся:

• Доступность
• правильность
• прочность
• ....

Внешнее качество — это единственная функция программного обеспечения, которая волнует пользователей. Пользователь классный~

Но причина, по которой я отверг код, который я только что написал, заключалась в том, что в моем сердце была проблема с внутренним качеством программного обеспечения.Внутреннее качество включает в себя:

• Читабельность (наверное, самое главное)
• ремонтопригодность
• Доступность (теперь поддерживает пользовательские формы, это приятно~)
• ....

Я написал и обнаружил, что код не прост для понимания, поэтому я присмотрелся и нашел:

• код лишний
• Именование подпрограмм не является хорошим
• Структура кода испорчена
• Вслепую определить имя css
• ....

Что делать дальше, сначала рефакторинг~

• Разберитесь со структурой кода, прокачивайте и рисуйте, и сделайте общий процесс понятным
• Переосмыслить имена подпрограмм, написать комментарии
• Подумайте об интерфейсе, предоставляемом внешнему миру для повышения доступности
• .....

Завершив волну реконструкции, подумайте, почему возникла проблема с внутренним качеством?

Стремление к качеству бесконечно, как внутреннее, так и внешнее. Многие методы могут улучшить качество: дополнительные тестовые примеры, хороший стиль программирования, разумные аннотации, многоуровневые абстракции, разумные интерфейсы... Невозможно сделать так, чтобы все функции выглядели идеально. Поиск решения, основанного на наборе конкурирующих целей, делает программное обеспечение настоящей инженерной дисциплиной.

дизайн

Почему качество плохое? Конечно, именно из-за проблем проектирования дизайн оказывается несогласованным в процессе разработки и дизайн постоянно корректируется, что приводит к разрушению очень важной «целостности системы» в программном обеспечении (ключевой момент человеческого миф о месяце). В итоге получается некачественно.

Так почему же он плохо спроектирован? Думаю, это потому, что я не устоял перед искушением «начать программировать прямо сейчас»! Подумав о том, как перетаскивать существующие события, я не мог дождаться начала кодирования. Более детальное проектирование не проводилось. На самом деле, на этом этапе я выделил в своем мозгу последующие потребности (самозащита для интеллектуально управляемых~). После реализации перетаскивания существующих событий я начал думать, как перетащить пустую область, чтобы создать новую, и обнаружил, что существующий дизайн нуждается в корректировке. Затем я снова начал кодировать после того, как у меня появилась хорошая идея. Неправильно спроектированные петли приводят к падению качества.

По сути, производство программного обеспечения — это то же самое, что пищевая цепочка в реальности: спрос -> дизайн -> программирование. Одна связь с другой, чем ближе к восходящему потоку возникает проблема, тем сильнее ее влияние. Вывод таков: каждый дизайн, который я делаю, основан на неполных требованиях.

Что нужно сделать, это должно быть максимально продумано с самого начала. Время проектирования, затрачиваемое на начальном этапе, должно быть увеличено.

итеративное развитие

Некоторые друзья могут увидеть это и подумать, что нет, дизайн по своей сути является «зловещей проблемой» (то есть проблемой, которую нужно решить или частично решить, чтобы определить). Так что не проблема использовать итеративную разработку в процессе разработки. Преимущество итеративности в том, что она способствует неприятию риска. Продолжайте пытаться с низкими затратами, чтобы снизить риск неудачи. Следовательно, итеративная разработка должна сопровождаться непрерывным рефакторингом для обеспечения качества.

По этому вопросу. Думаю, стоит смотреть на масштаб проекта. Посмотрите на контролируемую сложность нашего разума. Возможно, лучший способ — разработать прототип для тестирования, а тест можно сразу же перепроектировать, а затем закодировать, что обойдется дешевле.

Именно после проверки некоторых сложностей в первой итерации осуществляется общий дизайн, что позволяет сократить необходимые рефакторинговые звенья после итеративной разработки, снизить общую стоимость разработки, повысить качество проекта.

Суммировать

В этой статье рассказывается о процессе реализации, деталях кодирования и общих представлениях о разработке перетаскиваемого компонента календаря. Причина, по которой я обсуждаю размышления о разработке, заключается в том, что для проектов разного размера используются разные методологии, а для небольших проектов применение методологий очень случайно и имеет тенденцию быть инстинктивным. Если мы выборочно используем некоторые методологии, мы можем сократить время разработки и улучшить качество продукта. Наконец прикрепленкодовый портал, конкретный доступ и использование можно увидеть в README проекта, есть еще довольно много дефектов, добро пожаловать, чтобы отправить PR ~

Если вам интересна наша команда, вы можете подписаться на рубрику и подписатьсяgithubИли отправьте свое резюме на 'tao.qit####alibaba-inc.com'.replace('####', '@'), люди с высокими идеалами могут присоединиться~

Оригинальный адрес:Github.com/proto Team / No ...