Step 4. Практика JavaScript

Это последнее задание перед ревью. Чат для отчетов остаётся прежним — из 3-его задания.

Описание задания Задание заключается в написании плагина для jQuery, который бы реализовывал функционал «бегунка» (также называемого слайдером) — специальный контрол, который позволяет перетягиванием задавать какое-то числовое (будет круто, если в реализации можно сделать не только числовое) значение. Этот элемент уже использовался во втором задании, дизайн можно взять оттуда. (http://joxi.ru/LmGLwnBieqq6K2) Требования:

1. Плагин должен иметь удобное API для подключения его к элементам на странице и соответствовать best practices по созданию плагинов для jQuery.
2. Плагин должен уметь работать независимо, если подключен несколько раз на странице, не должен ломать стили остальных элементов на странице.
3. Плагин должен быть максимально кастомизируемым. Помимо базовых конфигов вроде мининимально, максимального и текущего значения, надо позволить настраивать:
   1. размер шага,
   2. вертикальный/горизонтальный вид,
   3. одиночное значение или интервал,
   4. возможность на лету изменить значение "снаружи" javascript-ом,
   5. возможность включать/отключать элемент над бегунком, который показывает значение и который ползает за мышкой (при выключении просто кругляш сам только на слайдера, при включении над кругляшом элемент с цифрой).
4. Для демонстрации надо сверстать демо-страницу, где будет одновременно подключено больше трёх слайдеров, каждый с разными параметрами.
   1. Рядом с каждым слайдером разместить панель конфигурирования, чтобы можно было на лету менять параметры.
   2. Рядом с каждым слайдером разместить инпут, в котором всегда будет синхронизировано значение слайдера — при изменении инпута на анфокус слайдер тоже меняет значение. И наоборот, при изменении слайдера, в инпут устанавливается сразу значение.
5. Весь код должен быть на Github в вашем публичном репозитории, результатом задачи будет как раз этот репозиторий.
6. Требования к ежедневности коммитов и их названиям остаются, как во втором задании: коммиты минимум раз в день, когда вы хоть что-то сделали, у всех элементов должны быть осознанные названия.
7. Обязательно написание кода на TypeScript. Мы используем этот язык в разработке, он помогает держать сложность больших проектов под контролем, а также выручает при проектировании. Старайтесь не прибегать к помощи `any`, старайтесь настроить tsconfig максимально строгим образом. Код тестов желательно тоже писать на TypeScript, но это нестрого обязательно.
8. У вашего приложения должны быть четко разделенные слои приложения:
   1. Нужно сделать отдельный слой управления данными (Model), который будет содержать бизнес-логику приложения и не производить никаких расчетов, которые нужны для отображения.
   2. Отдельный слой для управления отображением (View) — здесь нельзя проводить никаких расчетов, относящихся к бизнес-логике. Слой должен содержать логику, связанную с отображением (например, для изменения положения ползунка слайдера на экране), а также реагировать на взаимодействие пользователя с приложением.
   3. Отдельный слой для обновления модели и отображения (Controller или Presenter). Это - единственный слой среди трех, который может иметь зависимость от других слоев. Он будет:

• реагировать на сообщения от отображения о действиях пользователей и обновлять модель;
• реагировать на сообщения об обновлении модели и обновлять отображение.

1. 1. 4.На выходе должно получиться подобие MVP-архитектуры с Passive View. Обязательно прочитайте про MVC архитектуру, про то, зачем она нужна, и какие у нее есть ответвления. Также изучите, как можно писать MVC-приложения на JavaScript. Вот несколько полезных источников:
      1. https://addyosmani.com/blog/understanding-mvc-and-mvp-for-javascript-and-backbone-developers/ — описание MVC и MVP архитектур и различий между ними;
      2. https://habrahabr.ru/post/321050/ — подробный разбор MVC, часть 1;
      3. https://habr.com/ru/post/322700/ — подробный разбор MVC, часть 2;
      4. https://habrahabr.ru/post/119369/ — подробное описание простейшего примера с четким разделением на три слоя и все на русском языке (обратите внимание, что в этом примере реализован классический вариант MVC паттерна, где отображение подписано на модель, а на действия пользователей реагирует контроллер, т.е. не стоит в точности повторять архитектурные решения из данного примера в своем проекте);
      5. https://habrahabr.ru/post/276593/ — основы архетиктуры, статья довольно сложная для новичка, нормально, если вы её в первый раз не очень глубоко поймёте, а потом под конец 4-го задания ещё раз вернётесь;
      6. Мы ожидаем, что это требование создаст больше всего проблем для вас и вызовет больше всего вопросов — мы готовы на все ответить и помочь разобраться. Зато для вас это будет самым ценным опытом — разобраться в простейших паттернах проектирования и попробовать создать что-то свое небольшое с нуля, используя такие паттерны. Так что смело задавайте вопросы, экспериментируйте и готовьтесь к тотальному переписыванию кода минимум пару раз :)
2. 9.Архитектура приложения должна быть задокументирована:
   1. В README проекта нужно добавить описание вашей архитектуры.
   2. После проектирования слоёв приложения, в README вам нужно написать, как вы отвязываете ваши слои приложений от внешних зависимостей, и осуществляете передачу данных снизу-вверх по слоям приложения. Возможно, вы обратили внимание, что получившиеся слои не являются равнозначными: есть слои с высокими уровнями абстракции, а есть — с низкими. Помимо этого, возможно, вы заметили, что каждый класс вашей архитектуры отвечает за отдельный аспект приложения.
   3. Помимо этого, вы должны составить UML-диаграмму своего приложения, которую тоже нужно добавить в README. Программа для составления диаграммы:https://www.draw.io/
3. 10.Приложение должно быть покрыто тестами:
   1. Самые основы можно почитать в главе у Кантора: https://learn.javascript.ru/testing. («В этой главе мы разберём основы автоматического тестирования. Оно будет применяться далее в задачах, и вообще, входит в “образовательный минимум” программиста.»).
   2. Сами тесты обязательны к написанию, должны находиться так же в репозитории, команда запуска тестов должна быть описана в README, запуск тестов после клонирования должен быть максимально простым (в идеале выполнения одной команды `npm i && npm test` должно быть достаточно), тестами должны быть покрыты все слои вашего приложения.
   3. TDD (которое в том числе немного описано у Кантора) — это когда сначала пишутся тесты, а после уже сами модули и методы. Если я сначала напишу плагин, а потом тесты, то задание не засчитают? Вообще на самом деле это нестрого обязательное требование, я решил явно тут про это написать, поправил описаниеЭто необязательное условие, особенно допустимо его нарушить для первой версии вашей программы. Желательно потом после создания каркаса попробовать некоторую функциональность добавить пару раз с использованием техники TDD (это как раз про то, что сначала должны быть тесты, потом сам код), это поможет вам лучше почувствовать методику.
4. 11.Желательно попробовать какие-нибудь новые молодежные фичи: все на ваш выбор и все необязательно. Будет круто, если сможете написать кастомные правила для линтера или небольшой сервачок, например. Но ни в коем случае не фреймворки (Angular, Ember, etc) и не React, вам нужно самим проработать MVC-архитектуру, а указанные решения навязывают сверху что и как делить в приложении.

Задание вам даст

• Базовые навыки проектирования (ООП, вариации MVC-архитектуры, разделение ответственности).
• Навыки по созданию удобных библиотек с удобным API (интерфейсом использования для других разработчиков).
• Навыки разделения конфигурирования и бизнес-логики.
• Умение документировать свой продукт (описывать заложенную архитектуру, визуализировать её через UML-диаграммы).
• Навыки автоматического unit-тестирования (включая TDD).

Если вы уверенно владеете этими темами, то можете пропускать данное задание и приступать к следующему. Дополнительные материалы:

1. Сборщики Parcel — очень быстрый бандлер, не требующий настройки Руководство по организации структуры и сборке проекта с webpack
2. Тестирование
   • Зачем нужны юнит-тесты
   • Как, используя TDD, сократить время разработки
   • Об использовании модульных тестов и TDD
   • Пример разработки «Крестиков‑ноликов» по TDD
   Ссылки на уроки по юнит-тестам с использованием Jasmine и Karma: Видеоуроки по Jasmine: https://www.youtube.com/watch?v=9xkfgprKTmY&list=PLY4rE9dstrJwM36wcLi4we_JfhlhgYbcB Основы работы с Karma: https://www.youtube.com/watch?v=0jFB32IT2u0 Настройка Karma в связке с Webpack: https://habr.com/ru/company/rambler-co/blog/278503/ Настройка Karma-Jasmine-Webpack-Typescript: https://developerlife.com/2019/07/06/starter-project-typescript-karma-jasmine-webpack/
3. 3. Подкасты:
   1. Веб-стандарты: https://soundcloud.com/web-standards
   2. RadioJS: https://soundcloud.com/radiojspodcast
   3. Пятиминутка React: https://soundcloud.com/5minreact