ДИПЛОМ
Слайд 1.
Добрый день, уважаемые члены Государственной аттестационной комиссии. Меня зовут Афанасенков Андрей Витальевич, моим научным руководителем является кандидат технических наук, доцент, заведующий кафедрой 316 Хорошко Леонид Леонидович.
Сегодня я хотел бы представить вам мою Выпускную Квалификационную работу магистра. На тему – «Исследование технологических особенностей менеджеров состояний в JavaScript фреймворках».
Слайд 2.
Целью работы являлось осуществление анализа особенностей менеджеров состояния в JavaScript фреймворках.
В ходе работы были поставлены следующие задачи:
1. Рассмотреть концепции хранения данных в JavaScript фреймворках
2. Рассмотреть существующие подходы управления состояниями
3. Провести сравнительный анализ ключевых особенностей популярных менеджеров состояний
4. Реализовть переход на единый источник состояний для Web приложения
Слайд 3.
Актуальность выбранной темы связана со следующими факторами
1. Проблема управление состоянием в интерпрайз приложениях
2. Существование большого количество менеджеров состояний, со своими определенными особенностями
3. Отсутствие единых рекомендаций по использования того или иного менеджера состояний под определенные задачи
Слайд 4.
Рассмотрим как выглядит архитектура слоя представления в spa-приложениях.
Как правило, это дерево компонентов. Элементы дерева между собой общаются и передают данные.
Все фрэймворки по умолчанию имеют однонаправленный поток данных. То есть, данные передаются из родительского компонента в дочерний.
Слайд 5.
С увеличением количества компонентов увеличивается и количество сложных каскадных зависимостей.
В следствие чего происходит передача избыточных данных между компонентами, отсутствует гарантия согласованности данных и появляется сложность в делении компонентов.
И при этом, если в дочернем компоненте есть какая-либо бизнес-логика, и он взаимодействует с другим дочерним компонентом, то приложение становится уже громоздким и его поддержка значительно усложняется.
Слайд 6.
Основной подход позволяющий избавиться от этих проблем это – переход на централизованное хранилище данных. Такие хранилища позволяют легко масштабировать проект и заботиться о чистоте его архитектуры.
Слайд 7.
Одной из самых популярный концепций централизованного хранилища данный является Редакс.
Преимуществами которого является –
-единое хранилище состояний,
-все имзенения происходят – толкько аз счет чистых функций,
-простоая и эффективная откладка
-и иммутабальность данных(объекты не меняются).
Слайд 8
В ходе исследования были выли выявлены три наиболее популярных реализации паттерна редакс в фреймворке Ангуляр,
это - ngRx, NgXS и Акита.
Рассмотирм концепцию каждого из них
9 слайд
NGRX разработан на основе Redux и RxJs (это библиотека для работы с асинхронном кодом). Давайте рассмотрим концепцию NGRX.
10 слайд
У нас есть компонент (желтый) - Из компонентами происходит диспатчинег Action в редюсер
Хотелось бы также уточнить, то, что Action в NGRX представляет из себя класс с уникальным типом и пейлоудом, который мы передаем в конструктор.
Далее, в редюсере происходит вызов нужной логики, которая возвращает уже новое состояние и передает его в Store
Наш компонент подписывается на изменение в Store и получает обновлённое состояние.
11) слайд
Далее у нас идет NgXS, NGXS был придуман для того, чтобы избавиться от некоторого бойлерплейта(обязательный код, который необходимо повторять), используя, так называемые, декораторы.
В JavaScript декораторы позволяет нам динамически в рантайме, добавлять метаинформацию, либо динамически изменять поведение компонента.
12 слайд
И в этом случае, теперь концепция изменяется в том плане, что мы полностью избавляемся от редюсеров. Тем самым код становится более типизированный и еще сильнее соблюдающий принципы ООП.
13 слайд
Следующая на очереди Акита
Если NGRX, NGXS очень похоже на Redux-концепцию, то здесь уже идут значительные отличия.
Акита разработан на основе концепции Flax, из него он взял Мультиплей дата сторс.
-У нее есть RxJs,
-Имутабельность из Redux
и Angular сервисы.
14) слайд
Рассмотрим концепцию.
Есть компонент, он диспатчит экшен в сервис.
В сервисе находится основная наша бизнес-логика, которая позволяет взаимодействовать с сервисами, а также с API.
Далее, с сервиса происходит команда на изменение состояния в Store.
Store эту команду получает, обрабатывает.
Далее из Store обновлённое состояние переходит в Квери.
Квери – это запрос. Он может только считывать информацию из нашего Store, взаимодействовать с другими Квери, и в конце своей работы передавать новое состояние в наш компонент
15 слайд
В ходе работы было разработано три ТуДу приложения Имеющих схожую логику под каждый рассмотренный менеджер состояния
Были выделены их ключевые особенности и проведен сравнительный анализ.
16 слайд
Менеджеры состояний сравнивались по 6 критериям
Первый критерий – Показатель популярности – выраженный в количестве звезд на гитхаб
Второй критерий бойлерплейт – это показатель, отвечающий за объем обязательно повторяющегося кода
Третий критерий – кривая обучения -характеризующая простоту обучения
Четвертый критерий – удобность покрытия тестами
Пятый критерий – Наличие и качество документации, описывающей процесс внедрения менеджера состояния
Последний критерий - наличие дополнительных инструментов для разработчика
В результате анализа были сделаны следующие выводы:
NGRX – это менеджер состояния для тех, кто переходит с Реакта на Angular и хочет писать на Redux также как там. Поэтому он отлично подходит для Реакт разработчиков
NGXS, это уже более такой высокоуровневый интерфейс для работы с стейтами в приложении и он очень хорошо подходит для больших и средних энтерпрайз-проектов.
Акита, имеет преимущества для того, чтобы закрепиться в тяжёлом энтерпрайзе.
((Потому что, в этом случае, вы действительно пишите боллее ООП код, У вас есть отдельно сервисы на запись, отдельные сервисы на чтение, и вы отделяете, действительно, декомпозируете свое приложение и работу стейтом в вашем приложении.))
16 слайд
В ходе выполнения работы был поставлена задача внедрить один из менеджеров состояния в веб приложение для преподавателей и студентов, которое являлось предметом моей квалификационной работы бакалавра, В нем раннее использовался обычный подход с разными источники состояния, в последствии увеличения объема приложения, его поддержка значительно усложнилась
После сравнительного анализа подходов управления состояния, было принято решения внедрить в веб приложение менеджер состояния NgXS, самый оптимальный по рассматриваемым критериям.
За счет этого удалось
-сократить кодовую БАЗУ приложения на 18% и ускорить рабоут отдельный компонентов
Слайд 17.
Подведём итоги. В результате выполнения работы:
· Была Рассмотрена концепция хранения данных в JavaScript фреймворках
· Рассмотрены существующие подходы управления состояниями
· Осуществлен переход на единый источник состояния (NgXS) в разработанном ранее веб приложении
Спасибо за вниманиееееееее