Schedulr: Github Frontend, Github Backend | Живая демонстрация

Недавно я собрал свое первое индивидуальное полнофункциональное веб-приложение Schedulr. Schedulr - это приложение для планирования дня, разработанное специально для того, чтобы я планировал свои дни. Когда я просыпаюсь, я составляю список того, что мне нужно сделать, и количество времени, которое, как мне кажется, они займут, а затем я размещаю их на временной шкале. Это сложно сделать с наклейками, но легко сделать с помощью веб-приложения.

Идея

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

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

React DnD построен на Redux и может показаться знакомым тем, кто уже использует Redux. К этому моменту я только что закончил изучать React, и попытки втиснуть в свой мозг Redux и React DnD, в то время как одновременная работа над моим первым проектом на основе React оказалась слишком сложной.

После полутора дней безуспешной работы с React DnD я решил, что пора двигаться дальше. Я рассмотрел свои варианты, переоценил ситуацию и решил, что React Draggable - это то, что мне нужно в дальнейшем. Как оказалось, Draggable идеально подошел моему дизайну.

Я извлек много уроков о работе с Draggable, работе с элементами прокрутки и сохранении данных - достаточно, чтобы это была отдельная история.

Поскольку это был мой первый сольный проект и мой первый проект с React, работа начиналась медленно. Как в самом программировании, так и в планировании проекта для одного программиста требовалось немного обучения. Я обнаружил, что если бы я использовал доску Trello, разветвляясь и вкладывая в нее столько же, сколько и в групповой проект, я мог бы организовать свой ход мыслей. У меня также был рабочий документ, объясняющий функциональность приложения.

Бэкэнд

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

Единственное, что меня здесь действительно сбило с толку, так это то, что мне нужно было где-то спрятать свой секрет JWT, чтобы обеспечить безопасность. Это было достаточно просто при локальном размещении - просто используйте Фигаро, чтобы создать переменную окружения в файле, игнорируемом Git, и назначить эту переменную вашему секрету.

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

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

heroku config:set secret=itsmysecret

Фронтенд

Хотя бэкэнд был на удивление прост, он не доставлял мне никаких проблем. С Draggable можно было связываться само по себе, но это была не единственная часть моей программы, с которой я боролся.

Я намеревался делать стили полностью с помощью Semantic React, но, как оказалось, реализация Semantic в React лишь немного неполна. Поскольку у меня был очень ограниченный график (всего полторы недели), в итоге я получил мешанину из Semantic React и традиционного Semantic UI. Код не всегда красив или единообразен, но в конце концов все работает.

Выпадающие списки в Semantic действительно меня разочаровали. Я попытался скормить им свою обычную функцию handleChange, но они мне ничего не вернули. Как оказалось, раскрывающееся значение event.value вернулось как null, а значение, которое я искал, появилось как второй аргумент.

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

В худшем случае я передавал информацию из приложения в DayContainer, в DayGrid, в AppointmentList, в AppointmentContainer, в Appointment в EditModal. Это шесть уровней разочарования каждый раз, когда мне нужно изменить, удалить или добавить функцию. Сейчас я нахожусь на начальной стадии изучения Redux, и мне сказали, что многие из этих проблем будут решены. Я с нетерпением жду этого.

Другое разочарование, связанное с реквизитом, - это количество, которое мне нужно было передать. В лучшем случае у меня было 19 различных пропсов, передаваемых от AppointmentContainer к Appointment. Большая часть этого - координаты для Draggable, а также некоторые формулы, чтобы убедиться, что встреча останется в его границах. Я уверен, что мог бы провести рефакторинг, если бы у меня было больше времени, но главным приоритетом было наладить все и запустить.

Готовый продукт: хорошее

В конце концов, я невероятно горжусь тем, чего мне удалось добиться. За полторы недели мне удалось выпустить то, что я считаю своей лучшей работой. Он более совершенный, чем все, что я когда-либо делал, он работает по своему прямому назначению, он доступен на Heroku, чтобы люди могли его использовать, и он даже выглядит красиво.

Мне также удалось использовать Draggable, который довольно хорошо документирован для того, что это такое, но не для того, для чего я хотел его использовать. Выполняя поиск в Интернете, я не смог найти никаких прямых источников того, с чем я столкнулся. Я нашел много вещей, косвенно связанных с моей проблемой, из которых я мог бы вытащить, но не нашел прямых решений. Это первый раз, когда я действительно отважился на такую ​​неизведанную территорию.

Плохое и уродливое

Я бы не назвал что-либо особенно плохим, но определенно есть что-то уродливое, особенно если сайт открывается на мобильном устройстве или в окне, размер которого меньше 500 пикселей. Я был гораздо больше увлечен созданием каждого отдельного компонента, чем планированием его с самого начала, поэтому, наконец, собрать все воедино было немного хаосом.

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

Вывод

Я многому научился в этом проекте и перестал чувствовать себя немного потерянным в первый день, а к концу почувствовал себя опытным ветеринаром React. Мне жаль, что я не отслеживал время, которое я вкладываю в каждый раздел, но я знаю, что в целом я вложил в проект более 50 часов своей собственной работы. Я также довольно уверен, что использовал Draggable так, как другие не использовали или, по крайней мере, не писали. Я также на собственном горьком опыте узнал, почему люди занимаются дизайном, прежде чем начать писать код. Я сомневаюсь, что совершу ошибку снова.

Скоро я напишу сообщение о React Draggable, о том, как я его реализовал, и о безумных вещах, которые мне пришлось сделать, чтобы заставить его работать так, как я хотел.