Comments 12
причина изучения Rx заключается в оптимизации производительности приложений
А можете уточнить, как конкретно RxJs влияет на производительность? Это вроде бы больше про организацию асинхронного кода, само по себе это не увеличивает производительность
Это перевод, поэтому, наверное, лучше задавать вопросы в оригинальной статье. =) Но вообще там раскрыто дальше:
Меньше ререндеров – больше производительность. Логика, видимо, такая.
Управлять повторным рендерингом компонентов, например, можно, пропуская через пайп только те события, возникновение которых подразумевает необходимость в повторном рендеринге.
Меньше ререндеров – больше производительность. Логика, видимо, такая.
По большей части верное замечание, однако автор, вероятно, имел в виду следующие кейсы:
- Операторы по типу debounce/throttle/audit- Time,
- Различное кеширование стримов через share/publish/replay
- Все что связано с фильтрацией данных с помощью distinct и filter
- Одно из важнейших: встроенный пайп async, который идеально работает с rx и onPush
После нескольких попыток построить сложные бизнес приложения понял, что RxJS и сервисов — мало. Я бы сказал, что state management тоже обязателен, в частности, ngrx.
После нескольких попыток построить сложные бизнес приложения понял, что RxJS и сервисов — мало.нет
Я бы сказал, что state management тоже обязателеннет
в частности, ngrxо нет
Сервис с rxjs спокойно выступают в роли хранилища. Наличие стороннего стейта не обязательно, и ngrx их них не лучший.
Сторонний стейт удобен разве что поддержкой девтулзов и готовой документацией. Но нельзя сказать что это необходимость.
Аргументировано. ;)
1. Каким именно образом хранить данные? В BehaviorSubject?
2. Есть single source of truth или одна и та же сущность может в разных экземплярах behavior subject?
3. А как быть с объектами, у которых много связей? Строить пайпы в ngOnInit на страницу текста?
Можно пример более лучшего state management решения под ангуляр? Сравнение?
Сторонний стейт удобен тем, что даёт готовую архитектуру, которая определяет то, как будут взаимодействовать уровни приложения, храниться и передаваться данные.
Сервис с rxjs спокойно выступают в роли хранилища.
1. Каким именно образом хранить данные? В BehaviorSubject?
2. Есть single source of truth или одна и та же сущность может в разных экземплярах behavior subject?
3. А как быть с объектами, у которых много связей? Строить пайпы в ngOnInit на страницу текста?
Наличие стороннего стейта не обязательно, и ngrx их них не лучший.
Можно пример более лучшего state management решения под ангуляр? Сравнение?
Сторонний стейт удобен разве что поддержкой девтулзов и готовой документацией.
Сторонний стейт удобен тем, что даёт готовую архитектуру, которая определяет то, как будут взаимодействовать уровни приложения, храниться и передаваться данные.
Вмешаюсь в спор, а то, судя по всему, тут начинается холливар.
Выделенное звучит как-то безапелляционно.
Согласитесь, что flux-паттерн — это всего лишь «прием», как и любой другой паттерн.
Странно утверждать, к примеру, следующее: «без паттерна адаптер нельзя построить сложное приложение». Ведь можно?
С учётом вышесказанного, легко сделать вывод: в каких-то приложениях некий паттерн может не применяться. Тогда можем ли мы написать фронтенд-приложение без стейтменеджмента, что по сути является flux-паттерном? Можем.
Другое дело, что сейчас стейтменеджмент стал стандартом во фронтенде, и он действительно помогает решать задачи единообразно. Это круто по многим причинам, и должна быть довольно веская и, вероятно, специфичная причина, чтобы пренебрегать подобными тулзами.
Считаю, что упомянуть в статье концепцию стейтменеджмента стоило, добавив про ngrx/ngxs и прочее. Думаю, что инициатор ветки именно это и имел в виду, однако, в ответе ему справедливо добавили, что это всё же необязательное условие.
После нескольких попыток построить сложные бизнес приложения понял, что RxJS и сервисов — мало… state management тоже обязателен
Выделенное звучит как-то безапелляционно.
Согласитесь, что flux-паттерн — это всего лишь «прием», как и любой другой паттерн.
Странно утверждать, к примеру, следующее: «без паттерна адаптер нельзя построить сложное приложение». Ведь можно?
С учётом вышесказанного, легко сделать вывод: в каких-то приложениях некий паттерн может не применяться. Тогда можем ли мы написать фронтенд-приложение без стейтменеджмента, что по сути является flux-паттерном? Можем.
Другое дело, что сейчас стейтменеджмент стал стандартом во фронтенде, и он действительно помогает решать задачи единообразно. Это круто по многим причинам, и должна быть довольно веская и, вероятно, специфичная причина, чтобы пренебрегать подобными тулзами.
Считаю, что упомянуть в статье концепцию стейтменеджмента стоило, добавив про ngrx/ngxs и прочее. Думаю, что инициатор ветки именно это и имел в виду, однако, в ответе ему справедливо добавили, что это всё же необязательное условие.
Я специально указал, что state management обязателен для сложных бизнес приложений. А не вообще всегда. Это утверждение сделано на основании собственного опыта построения таких приложений, как без state management, так и с ним.
И да, я готов к предметному обсуждению вопроса.
И да, я готов к предметному обсуждению вопроса.
Что такое «сложное»-бизнес приложение? Каждый эту формулировку понимает по своему, и уже это подобный спор делает довольно бессмысленным.
Когда появился первый ангуляр, эта концепция не была популяризирована во фронтенде. Как же без неё обходились? Или сложные приложения не разрабатывались?
Если отбросить web и подойти с подобной темой к разработчикам других клиентов, у которых абсолютно другой бэкграунд, то станет очевидно, что это просто прием, к которому не нужно относиться с фанатизмом, к чему я всех и призываю :)
Когда появился первый ангуляр, эта концепция не была популяризирована во фронтенде. Как же без неё обходились? Или сложные приложения не разрабатывались?
Если отбросить web и подойти с подобной темой к разработчикам других клиентов, у которых абсолютно другой бэкграунд, то станет очевидно, что это просто прием, к которому не нужно относиться с фанатизмом, к чему я всех и призываю :)
1. ну да. сабжекты. В том числе можно использовать и спрятанные сабжекты, типа publishReplay.
2. не понял вопроса, зачем хранить одну сущность в разных сабжектах.
3. Точно так же все. Как напишете, так и будет.
Я не утверждаю что стейт это плохо, но не могу сказать что он обязателен. Есть разные точки зрения на этот счет.
Я использую Akita. Меньше бойлерплейта, практически сервис на сабжектах, только с готовым апи с закосом под cqrs. Девтулз от редакса подходит. Плюс в отличии от ngrx есть возможность создавать и дестроить сторы.
Минус — она все таки не такая уж маленькая, если посмотреть исходники, зато есть пара полезных тулзов
2. не понял вопроса, зачем хранить одну сущность в разных сабжектах.
3. Точно так же все. Как напишете, так и будет.
Я не утверждаю что стейт это плохо, но не могу сказать что он обязателен. Есть разные точки зрения на этот счет.
Я использую Akita. Меньше бойлерплейта, практически сервис на сабжектах, только с готовым апи с закосом под cqrs. Девтулз от редакса подходит. Плюс в отличии от ngrx есть возможность создавать и дестроить сторы.
Минус — она все таки не такая уж маленькая, если посмотреть исходники, зато есть пара полезных тулзов
2. не понял вопроса, зачем хранить одну сущность в разных сабжектах.
Я это спросил, потому что не знаю вашей архитектуры. У меня просто были чисто практические затыки, которые приводили к появлению странных костылей. Наверно я просто не умею готовить сабжекты. Вот, допустим. Есть страница, где выводится список пользователей, постраничный. На бек уходит запрос с параметрами пейджинга, ответ помещается в сабжект. И есть ещё компонент, где выводится текущий пользователь. Что делать, если он не попал в сабжект? Хранить его в другом сабжекте? Дополнять текущий ещё и этим пользователем, но хранить настройки пейджинга, чтобы он не показывался на каждой странице? Это один из простых вопросов, с которыми сталкивался.
3. Точно так же все. Как напишете, так и будет.
И всё же? Если на странице в компоненте выводится таблица, где каждая строка — это данные пяти различных сущностей, где происходит их объединение? В коде компонента? В сервисе?
Я использую Akita. Меньше бойлерплейта, практически сервис на сабжектах, только с готовым апи.
Интересное решение, спасибо, гляну. Сейчас в ngrx бойлерплейта сильно меньше, чем было пару релизов назад.
А в чём нужда дестроить сторы?
Есть страница, где выводится список пользователей, постраничный. На бек уходит запрос с параметрами пейджинга, ответ помещается в сабжект.
Получаем пользователей, растаскиваем их в мапу по айдишникам. Можно даже не сабжект.
Рядом отдельно храним инфу про пейджинг, порядок итемов, в общем все что относится к ui.
По запросу потребителя, в зависимости от переданных параметров, собираем в список.
Фактически тут две проблемы: 1. Как хранить. 2 Как уведомить потребителя насчет обновления. Не обязательно их смешивать.
где происходит их объединение? В коде компонента? В сервисе?
Сервис, инжектящий сервисы с данными и предоставляющий паблик обсервабл. В компоненте это делать не нужно, на случай возможного переиспользования сервисов. Компонент может ничего не знать про источники данных.
А в чём нужда дестроить сторы?
А зачем держать свалку ненужных сторов?
Кроме того, евент-сорсинг модель, когда каждое событие проходит по свитчам в куче редьюсеров тоже не лучшим образом сказывается на производительности.
Sign up to leave a comment.
6 концепций, которые нужно освоить архитектору Angular-приложений