YK
подскажите хороший мануал по реактивному стилю в ангуляре
Size: a a a
2020 February 04
YK
шоб блин все было потоками, и в конце один субскрайб - и тот в async-pipe
YK
у меня вот почти идеальный CRSSFUD (create read, search, sort by, filter, update, delete), тока еще с бесконечным скроллом
YK
я вот так думаю:
1. Есть поток поиска, параметризуется значениями фильтра, направлением и полем сортировки, плюс еще каким-то хитрым финтом чтобы была бесконечная прокрутка, ненавижу ее.
2. Добавление, обновление и удаление объекта должно заставлять поток поиска делать новый запрос с его текущими параметрами.
3. изменение фильтров и сортировки приводит к выстреливанию их обсерваблов, которые опять-таки заставляют поток поиска делать новый запрос и все перерисовывать по-новой
4. скролл тоже вызывает новый запрос, но результаты конкатенируются к существующим, а не заменяют оные.
1. Есть поток поиска, параметризуется значениями фильтра, направлением и полем сортировки, плюс еще каким-то хитрым финтом чтобы была бесконечная прокрутка, ненавижу ее.
2. Добавление, обновление и удаление объекта должно заставлять поток поиска делать новый запрос с его текущими параметрами.
3. изменение фильтров и сортировки приводит к выстреливанию их обсерваблов, которые опять-таки заставляют поток поиска делать новый запрос и все перерисовывать по-новой
4. скролл тоже вызывает новый запрос, но результаты конкатенируются к существующим, а не заменяют оные.
L
у меня вот почти идеальный CRSSFUD (create read, search, sort by, filter, update, delete), тока еще с бесконечным скроллом
твоя задача просто сделать так что б на каждый юзер екшн поток менялся
L
Попробуй через EventBus
DB
я вот так думаю:
1. Есть поток поиска, параметризуется значениями фильтра, направлением и полем сортировки, плюс еще каким-то хитрым финтом чтобы была бесконечная прокрутка, ненавижу ее.
2. Добавление, обновление и удаление объекта должно заставлять поток поиска делать новый запрос с его текущими параметрами.
3. изменение фильтров и сортировки приводит к выстреливанию их обсерваблов, которые опять-таки заставляют поток поиска делать новый запрос и все перерисовывать по-новой
4. скролл тоже вызывает новый запрос, но результаты конкатенируются к существующим, а не заменяют оные.
1. Есть поток поиска, параметризуется значениями фильтра, направлением и полем сортировки, плюс еще каким-то хитрым финтом чтобы была бесконечная прокрутка, ненавижу ее.
2. Добавление, обновление и удаление объекта должно заставлять поток поиска делать новый запрос с его текущими параметрами.
3. изменение фильтров и сортировки приводит к выстреливанию их обсерваблов, которые опять-таки заставляют поток поиска делать новый запрос и все перерисовывать по-новой
4. скролл тоже вызывает новый запрос, но результаты конкатенируются к существующим, а не заменяют оные.
Сомневаюсь, что есть конкретно такой мануал для ангуляра, судя по вопросу всё выглядит так, будто надо курить именно RxJS.
По пунктам -
1) Поле поиска, фильтр, сортировка - простая реактивная форма. Создаешь FormGroup, вешаешь valueChanges - профит. Пускай это будет одним из триггеров для нового запроса.
2) И это тоже просто триггер для нового запроса.
3) То же самое, что и 1.
4) Ну тут уже просто дело техники. Не знаю, причём тут реактивность.
В итоге все триггеры собираешь с помощью
По пунктам -
1) Поле поиска, фильтр, сортировка - простая реактивная форма. Создаешь FormGroup, вешаешь valueChanges - профит. Пускай это будет одним из триггеров для нового запроса.
2) И это тоже просто триггер для нового запроса.
3) То же самое, что и 1.
4) Ну тут уже просто дело техники. Не знаю, причём тут реактивность.
В итоге все триггеры собираешь с помощью
combineLatest, подписываешься делаешь свои запросыYK
Сомневаюсь, что есть конкретно такой мануал для ангуляра, судя по вопросу всё выглядит так, будто надо курить именно RxJS.
По пунктам -
1) Поле поиска, фильтр, сортировка - простая реактивная форма. Создаешь FormGroup, вешаешь valueChanges - профит. Пускай это будет одним из триггеров для нового запроса.
2) И это тоже просто триггер для нового запроса.
3) То же самое, что и 1.
4) Ну тут уже просто дело техники. Не знаю, причём тут реактивность.
В итоге все триггеры собираешь с помощью
По пунктам -
1) Поле поиска, фильтр, сортировка - простая реактивная форма. Создаешь FormGroup, вешаешь valueChanges - профит. Пускай это будет одним из триггеров для нового запроса.
2) И это тоже просто триггер для нового запроса.
3) То же самое, что и 1.
4) Ну тут уже просто дело техники. Не знаю, причём тут реактивность.
В итоге все триггеры собираешь с помощью
combineLatest, подписываешься делаешь свои запросы4. в предыдущие мои попытки такое сделать, это было самое сложное, ведь если у нас в шаблоне что-то типа {{results|async}}, то results должен в себе содержать все элементы, подлежащие отображению
DB
4. в предыдущие мои попытки такое сделать, это было самое сложное, ведь если у нас в шаблоне что-то типа {{results|async}}, то results должен в себе содержать все элементы, подлежащие отображению
YK
ну, я доскроллил до 6й страницы, а юзер поменял фильтры
YK
значит нужно results обнулить, и запрашиваемую страницу поиска тоже обнулить
DB
ну, я доскроллил до 6й страницы, а юзер поменял фильтры
Смена фильтров должна делать switchMap
YK
я понимаю
YK
combineLatest(фильтры, сортировка, поисковая строка) | switchMap(поиск) - тут все ясно
DB
я понимаю
Смотрите, всё начинается с потока, который эмитит параметры по дефолту (пустая строка поиска, сортировка, фильтр).
Эти параметры по пайплану попадают в switchMap(), который возвращает поток, содержащий в себе scan и реакцию на скролл.
Это в общих чертах. Могу помочь более конкретно, если есть более конкретный вопрос
Эти параметры по пайплану попадают в switchMap(), который возвращает поток, содержащий в себе scan и реакцию на скролл.
Это в общих чертах. Могу помочь более конкретно, если есть более конкретный вопрос
YK
а, кажется понял, то бишь номер страницы не должен быть в нашем combineLatest
DB
Вот, в итоге этот поток отдаёт results, на который вы и подписываетесь в шаблоне
DB
а, кажется понял, то бишь номер страницы не должен быть в нашем combineLatest
Если поиск, фильтр и сортировка = 1 FormGroup, то тут даже combineLatest не нужен