Относительно недавно тоже произошел небольшой конфликт с одним из разработчиков. Был вариант разделить на несколько функций для уменьшения дублирования, но я настаивал на «доменном» подходе когда у нас дублирование остается, но зато каждая функция несет в себе законченный сюжетный отрывок. Благодаря этому не происходит этого перепрыгивания и потери контекста поскольку теперь блок кода помещается в высоту экрана ноутбука. Да, вроде мелочь, но такте мелочи и формируют силу хорошей архитектуры.
Зависит от сложности ситуации. В связи с нововведением сигналов, количество оных сокращается. Привожу примеры кейсов, какие были актуальны до их введения и что я смог оценить на собственном опыте:
1. Сбор данных селекторами без необходимости использовать combineLatest 2. Иммутабельность состояния (все сабскрайберы вкурсе что что-то обновилось) 3. Pure functions для обновления состояния (долой лишние сайдэффекты) 4. Возможность хранить и изменять вложенные структуры данных (попробуйте сделать тоже самое через сабжекты) 5. Отложенная инициализация состояния (возможность инициализации после конструктора) 6. Органичное взаимодействие с глобальным стором (те же понятия, структура и т.п.)
Если у нас просто поля, которые не связаны между собой, то можно было просто обойтись сабжектами (сейчас сигналы). Если что-то большее, то component-store прекрасно себя раскрывает и оправдывает. Опять же повторюсь, что с внедрением сигналов (реально классная вещь) будет меньше необходимости (как в случае с вычисляемыми полями), но актуальность его сохраняется
Насчет последнего, думаю, что совсем скоро будет и возможность использовать его и в Nx/Angular проектах вместо Webpack. Привет nx/vite. А если уж не в моготу, можешь добавить Analogjs через генератор Nx. Красота
Полностью согласен с утверждением что Nx это обертка над Angular CLI. Пока за последние два года работы на разных проектах с Nx не нашел того, что может Angular CLI и что не может сделать Nx. Огромные плюсы в виде мощных инструментов (graph, кэширование, контроля зависимостей и миграций). Все это окупается сторицей.
Все верно, но в таком случае это уже не тот, кейс где вы очищаете стор после закрытия страницы. В таком случае данные вы теряете и другие ваши компоненты получат пустышки. И мы еще не говорим про lazy loading, где другие компоненты просто не смогут ничего получить пока данная страница не подгрузиться. А это, как понимаете, чревато ошибками если подгрузится не в нужной последовательности.
Для использования лучшего из двух миров я предлагаю для инкапсулированного внутри страницы состояния использовать компонентный стор, а для того, что шарится - глобальный стор (причем тот его спайс, который не инитится самой страницей т.е. не forFeature). Таким образом мы избавляемся от необходимости использовать глобальный стор для страницы и получаем возможность шарить данные через общий слайс который инитится в forRoot и таким образом не страдаем от возможных проблем с lazy loading потому что эта часть стора доступна с начала работы приложения
Работал на проекте где был преимущественно глобальный стор и сейчас разрабатываю проект в который внедряю в основном компонентный стор.
Не понимаю, зачем следовать логике использовать глобальный стор для страницы чтобы потом после ее разрушения очищать стор если можно тут же использовать компонентный стор, который все это делает автоматически?
Ок, нужно вам поделиться данными, пожалуйста, отправьте экшн в глобальный стор. Хочется отслеживать состояние в Redux Devtools, пожалуйста, там есть где-то хак для этого.
После предыдущего места работы задался этим же вопросом и пришел к выводу "Действительно, а зачем глобальный стор?" Начал внедрять везде компонентный стор и пока не пожалел. А еще сигналы скоро будут - красота.
Да, такое же удивление вызвало)
Последняя фраза - кайфовая. Спасибо! Записал)
Интересно. Однако пока не вижу кейсов где это применимо в мире большинства веб проектов. Если только в толстых клиентах.
Согласен, прямо в точку.
Относительно недавно тоже произошел небольшой конфликт с одним из разработчиков. Был вариант разделить на несколько функций для уменьшения дублирования, но я настаивал на «доменном» подходе когда у нас дублирование остается, но зато каждая функция несет в себе законченный сюжетный отрывок. Благодаря этому не происходит этого перепрыгивания и потери контекста поскольку теперь блок кода помещается в высоту экрана ноутбука. Да, вроде мелочь, но такте мелочи и формируют силу хорошей архитектуры.
Согласен, хорошее напутствие. Лучше профилактика чем потом лечение
Ничего личного, но, упаси боже, только не JSX
Спасибо за статью. Как раз задумываюсь об оптимизации своего пайплайна с Nx.
Можете поделиться своим опытом:
Какие оптимизации стоит использовать в самом пайплане, а какими стоит ограничиться лишь локально?
Что можете сказать о прогонке тестов во время разработки. Насколько я слышал за это отвечает механизм watch.
Зависит от сложности ситуации. В связи с нововведением сигналов, количество оных сокращается. Привожу примеры кейсов, какие были актуальны до их введения и что я смог оценить на собственном опыте:
1. Сбор данных селекторами без необходимости использовать combineLatest
2. Иммутабельность состояния (все сабскрайберы вкурсе что что-то обновилось)
3. Pure functions для обновления состояния (долой лишние сайдэффекты)
4. Возможность хранить и изменять вложенные структуры данных (попробуйте сделать тоже самое через сабжекты)
5. Отложенная инициализация состояния (возможность инициализации после конструктора)
6. Органичное взаимодействие с глобальным стором (те же понятия, структура и т.п.)
Если у нас просто поля, которые не связаны между собой, то можно было просто обойтись сабжектами (сейчас сигналы). Если что-то большее, то component-store прекрасно себя раскрывает и оправдывает. Опять же повторюсь, что с внедрением сигналов (реально классная вещь) будет меньше необходимости (как в случае с вычисляемыми полями), но актуальность его сохраняется
Насчет последнего, думаю, что совсем скоро будет и возможность использовать его и в Nx/Angular проектах вместо Webpack. Привет nx/vite. А если уж не в моготу, можешь добавить Analogjs через генератор Nx. Красота
Полностью согласен с утверждением что Nx это обертка над Angular CLI. Пока за последние два года работы на разных проектах с Nx не нашел того, что может Angular CLI и что не может сделать Nx. Огромные плюсы в виде мощных инструментов (graph, кэширование, контроля зависимостей и миграций). Все это окупается сторицей.
Все верно, но в таком случае это уже не тот, кейс где вы очищаете стор после закрытия страницы. В таком случае данные вы теряете и другие ваши компоненты получат пустышки. И мы еще не говорим про lazy loading, где другие компоненты просто не смогут ничего получить пока данная страница не подгрузиться. А это, как понимаете, чревато ошибками если подгрузится не в нужной последовательности.
Для использования лучшего из двух миров я предлагаю для инкапсулированного внутри страницы состояния использовать компонентный стор, а для того, что шарится - глобальный стор (причем тот его спайс, который не инитится самой страницей т.е. не forFeature). Таким образом мы избавляемся от необходимости использовать глобальный стор для страницы и получаем возможность шарить данные через общий слайс который инитится в forRoot и таким образом не страдаем от возможных проблем с lazy loading потому что эта часть стора доступна с начала работы приложения
Потом обнуляем счетчик "Дней без нового фреймворка во фронте" ;)
Работал на проекте где был преимущественно глобальный стор и сейчас разрабатываю проект в который внедряю в основном компонентный стор.
Не понимаю, зачем следовать логике использовать глобальный стор для страницы чтобы потом после ее разрушения очищать стор если можно тут же использовать компонентный стор, который все это делает автоматически?
Ок, нужно вам поделиться данными, пожалуйста, отправьте экшн в глобальный стор. Хочется отслеживать состояние в Redux Devtools, пожалуйста, там есть где-то хак для этого.
После предыдущего места работы задался этим же вопросом и пришел к выводу "Действительно, а зачем глобальный стор?" Начал внедрять везде компонентный стор и пока не пожалел. А еще сигналы скоро будут - красота.