Цель заброшена
Автор не отписывался в цели 5 лет 4 месяца 15 дней
Step 4. Практика JavaScript
Это последнее задание перед ревью. Чат для отчетов остаётся прежним — из 3-его задания.
Описание задания Задание заключается в написании плагина для jQuery, который бы реализовывал функционал «бегунка» (также называемого слайдером) — специальный контрол, который позволяет перетягиванием задавать какое-то числовое (будет круто, если в реализации можно сделать не только числовое) значение. Этот элемент уже использовался во втором задании, дизайн можно взять оттуда. (http://joxi.ru/LmGLwnBieqq6K2) Требования:
- Плагин должен иметь удобное API для подключения его к элементам на странице и соответствовать best practices по созданию плагинов для jQuery.
- Плагин должен уметь работать независимо, если подключен несколько раз на странице, не должен ломать стили остальных элементов на странице.
- Плагин должен быть максимально кастомизируемым. Помимо базовых конфигов вроде мининимально, максимального и текущего значения, надо позволить настраивать:
- размер шага,
- вертикальный/горизонтальный вид,
- одиночное значение или интервал,
- возможность на лету изменить значение "снаружи" javascript-ом,
- возможность включать/отключать элемент над бегунком, который показывает значение и который ползает за мышкой (при выключении просто кругляш сам только на слайдера, при включении над кругляшом элемент с цифрой).
- Для демонстрации надо сверстать демо-страницу, где будет одновременно подключено больше трёх слайдеров, каждый с разными параметрами.
- Рядом с каждым слайдером разместить панель конфигурирования, чтобы можно было на лету менять параметры.
- Рядом с каждым слайдером разместить инпут, в котором всегда будет синхронизировано значение слайдера — при изменении инпута на анфокус слайдер тоже меняет значение. И наоборот, при изменении слайдера, в инпут устанавливается сразу значение.
- Весь код должен быть на Github в вашем публичном репозитории, результатом задачи будет как раз этот репозиторий.
- Требования к ежедневности коммитов и их названиям остаются, как во втором задании: коммиты минимум раз в день, когда вы хоть что-то сделали, у всех элементов должны быть осознанные названия.
- Обязательно написание кода на TypeScript. Мы используем этот язык в разработке, он помогает держать сложность больших проектов под контролем, а также выручает при проектировании. Старайтесь не прибегать к помощи `any`, старайтесь настроить tsconfig максимально строгим образом. Код тестов желательно тоже писать на TypeScript, но это нестрого обязательно.
- У вашего приложения должны быть четко разделенные слои приложения:
- Нужно сделать отдельный слой управления данными (Model), который будет содержать бизнес-логику приложения и не производить никаких расчетов, которые нужны для отображения.
- Отдельный слой для управления отображением (View) — здесь нельзя проводить никаких расчетов, относящихся к бизнес-логике. Слой должен содержать логику, связанную с отображением (например, для изменения положения ползунка слайдера на экране), а также реагировать на взаимодействие пользователя с приложением.
- Отдельный слой для обновления модели и отображения (Controller или Presenter). Это - единственный слой среди трех, который может иметь зависимость от других слоев. Он будет:
- реагировать на сообщения от отображения о действиях пользователей и обновлять модель;
- реагировать на сообщения об обновлении модели и обновлять отображение.
- 4.На выходе должно получиться подобие MVP-архитектуры с Passive View. Обязательно прочитайте про MVC архитектуру, про то, зачем она нужна, и какие у нее есть ответвления. Также изучите, как можно писать MVC-приложения на JavaScript. Вот несколько полезных источников:
- https://addyosmani.com/blog/understanding-mvc-and-mvp-for-javascript-and-backbone-developers/ — описание MVC и MVP архитектур и различий между ними;
- https://habrahabr.ru/post/321050/ — подробный разбор MVC, часть 1;
- https://habr.com/ru/post/322700/ — подробный разбор MVC, часть 2;
- https://habrahabr.ru/post/119369/ — подробное описание простейшего примера с четким разделением на три слоя и все на русском языке (обратите внимание, что в этом примере реализован классический вариант MVC паттерна, где отображение подписано на модель, а на действия пользователей реагирует контроллер, т.е. не стоит в точности повторять архитектурные решения из данного примера в своем проекте);
- https://habrahabr.ru/post/276593/ — основы архетиктуры, статья довольно сложная для новичка, нормально, если вы её в первый раз не очень глубоко поймёте, а потом под конец 4-го задания ещё раз вернётесь;
- Мы ожидаем, что это требование создаст больше всего проблем для вас и вызовет больше всего вопросов — мы готовы на все ответить и помочь разобраться. Зато для вас это будет самым ценным опытом — разобраться в простейших паттернах проектирования и попробовать создать что-то свое небольшое с нуля, используя такие паттерны. Так что смело задавайте вопросы, экспериментируйте и готовьтесь к тотальному переписыванию кода минимум пару раз :)
- 4.На выходе должно получиться подобие MVP-архитектуры с Passive View. Обязательно прочитайте про MVC архитектуру, про то, зачем она нужна, и какие у нее есть ответвления. Также изучите, как можно писать MVC-приложения на JavaScript. Вот несколько полезных источников:
- 9.Архитектура приложения должна быть задокументирована:
- В README проекта нужно добавить описание вашей архитектуры.
- После проектирования слоёв приложения, в README вам нужно написать, как вы отвязываете ваши слои приложений от внешних зависимостей, и осуществляете передачу данных снизу-вверх по слоям приложения. Возможно, вы обратили внимание, что получившиеся слои не являются равнозначными: есть слои с высокими уровнями абстракции, а есть — с низкими. Помимо этого, возможно, вы заметили, что каждый класс вашей архитектуры отвечает за отдельный аспект приложения.
- Помимо этого, вы должны составить UML-диаграмму своего приложения, которую тоже нужно добавить в README. Программа для составления диаграммы:https://www.draw.io/
- 10.Приложение должно быть покрыто тестами:
- Самые основы можно почитать в главе у Кантора: https://learn.javascript.ru/testing. («В этой главе мы разберём основы автоматического тестирования. Оно будет применяться далее в задачах, и вообще, входит в “образовательный минимум” программиста.»).
- Сами тесты обязательны к написанию, должны находиться так же в репозитории, команда запуска тестов должна быть описана в README, запуск тестов после клонирования должен быть максимально простым (в идеале выполнения одной команды `npm i && npm test` должно быть достаточно), тестами должны быть покрыты все слои вашего приложения.
- TDD (которое в том числе немного описано у Кантора) — это когда сначала пишутся тесты, а после уже сами модули и методы. Если я сначала напишу плагин, а потом тесты, то задание не засчитают? Вообще на самом деле это нестрого обязательное требование, я решил явно тут про это написать, поправил описаниеЭто необязательное условие, особенно допустимо его нарушить для первой версии вашей программы. Желательно потом после создания каркаса попробовать некоторую функциональность добавить пару раз с использованием техники TDD (это как раз про то, что сначала должны быть тесты, потом сам код), это поможет вам лучше почувствовать методику.
- 11.Желательно попробовать какие-нибудь новые молодежные фичи: все на ваш выбор и все необязательно. Будет круто, если сможете написать кастомные правила для линтера или небольшой сервачок, например. Но ни в коем случае не фреймворки (Angular, Ember, etc) и не React, вам нужно самим проработать MVC-архитектуру, а указанные решения навязывают сверху что и как делить в приложении.
Задание вам даст
- Базовые навыки проектирования (ООП, вариации MVC-архитектуры, разделение ответственности).
- Навыки по созданию удобных библиотек с удобным API (интерфейсом использования для других разработчиков).
- Навыки разделения конфигурирования и бизнес-логики.
- Умение документировать свой продукт (описывать заложенную архитектуру, визуализировать её через UML-диаграммы).
- Навыки автоматического unit-тестирования (включая TDD).
Если вы уверенно владеете этими темами, то можете пропускать данное задание и приступать к следующему. Дополнительные материалы:
- Сборщики Parcel — очень быстрый бандлер, не требующий настройки Руководство по организации структуры и сборке проекта с webpack
- Тестирование
- Зачем нужны юнит-тесты
- Как, используя TDD, сократить время разработки
- Об использовании модульных тестов и TDD
- Пример разработки «Крестиков‑ноликов» по TDD
- 3. Подкасты:
- Веб-стандарты: https://soundcloud.com/web-standards
- RadioJS: https://soundcloud.com/radiojspodcast
- Пятиминутка React: https://soundcloud.com/5minreact
Критерий завершения
материал пройден
- 786
- 20 июня 2019, 14:54
Не пропустите новые записи!
Подпишитесь на цель и следите за ее достижением