Последние пару недель я работал над небольшим проектом под названием Knave App. Это приложение еще не закончено, но оно находится в рабочем состоянии, и я хотел рассказать о своем опыте его разработки и написания кода, а также о том, что я узнал.

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

Почему я сделал это приложение

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

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

Как я сделал это приложение

Я скопировал набор правил слово в слово, потратил некоторое время на форматирование его в HTML и потратил много времени на его стилизацию, чтобы сделать его идеальным. В выдвижном ящике есть ссылки на основные разделы набора правил. Я выбрал кремовый фон с темно-серым шрифтом для облегчения чтения (да и ночной режим не займет много времени). Я использовал значок SVG для значка меню в верхнем левом углу. Думаю, с этого момента я буду использовать иконки SVG. Их легко стилизовать, и с ними легче работать, чем с текстом в Юникоде (который я изначально использовал для значка меню). Они также выглядят одинаково во всех браузерах. Я добавил пару дополнительных функций - одну для катания реакции монстра, а другую для броска случайного заклинания.

Изначально я написал функции открытия и закрытия ящика, используя собственные сенсорные события JavaScript, прежде чем в конечном итоге переключиться на HammerJS. Я добавил прослушиватели событий для событий «touchstart» и «touchend» в текст моего документа. Это событие «touchstart» устанавливает начальные координаты x и y касания с помощью

x1 = event.changedTouches [0] .clientX

y1 = event.changedTouches [0] .clientY

И "touchend" устанавливает окончательные координаты x и y касания с помощью

пусть x2 = event.changedTouches [0] .clientX;

пусть y2 = event.changedTouches [0] .clientY;

Затем я вычислил разницу начальных и конечных координат x. Если разница превышала пороговое значение в 60 пикселей (пользователь смахнул вправо), ящик открывался. Если разница была меньше отрицательного значения этого порога (пользователь смахнул влево), ящик закрывался.

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

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

Боковое примечание: переход на HammerJS вызвал проблему, которую я не могу исправить. На мобильном устройстве Chrome при открытии выдвижного ящика кажется, что прослушиватель событий «щелчок» удаляется из пунктов меню примерно на полсекунды, или по какой-то причине для регистрации события требуется 2 клика. Это происходит только на мобильном устройстве Chrome, но не в Firefox. Таким образом я обменял одну проблему на другую, но я думаю, что это меньшая проблема, которую можно исправить.

Как я узнал из этого приложения

Я думаю, что есть что сказать о попытках сделать что-то самостоятельно перед использованием библиотеки. Я все еще пытаюсь найти баланс между опорой на библиотеки и изучением чего-либо сам, чтобы лучше это понять. Думаю, если бы у меня был крайний срок для создания этого приложения, я бы раньше использовал HammerJS. Но я счастлив, что потратил время на изучение сенсорных событий JavaScript. Мне нравится, насколько они просты и бесхитростны.

Я также на собственном опыте узнал, что тестирование с помощью мобильного инспектора настольного браузера НЕ то же самое, что тестирование на реальном телефоне. Я провожу несколько коротких дней, пытаясь понять, почему в FireFox Developer Edition на Mac элементы со стилем

положение: фиксированное;

верх: 0px;

Иногда случайным образом перемещались с того места, где они должны были быть (зависали где-то за пределами нормальной структуры дерева DOM), на самый верх страницы. После того, как я несколько дней ломал голову над этим, я, наконец, отправил этот явно сломанный код в действующую версию сайта только для того, чтобы убедиться, что проблема не существует в производственной среде. На это было потрачено много времени, и был извлечен ценный урок.

Я также много думал о разнице во времени разработки между использованием React и нативного HTML / CSS / JS. Реагировать на React было бы намного быстрее, но он излишне увеличил бы размер проекта. Использование HTML / CSS / JS отлично подходит для изучения базовых технологий, которые используют все веб-разработчики, но, черт возьми, писать HTML с помощью JavsScript или HTML сам по себе требует больше времени, чем написание компонентов React.

Спасибо, что прочитали мою статью! Опять же, обратная связь всегда приветствуется. Вы можете найти меня здесь: