> Потому, что мы не знаем сколько у пользователя памяти и как далеко он хочет домотать.
Так он все равно не домотает, докуда хочет, зачем предоставлять возможность, которую нельзя использовать? Или вы полагаете, что кто-то правда будет 5 минут крутить?..
Вы знаете, это как на сайт повесить кнопку, при клике на которую она будет вешать вкладку. Можно, конечно. Но зачем?
Разница с гуглом кардинальная — если в гугле я хочу (по каким-то причинам, вот хочу) попасть на 100 страницу, то я просто жму на 100 страницу. И все работает. То есть если функционал предоставлен — то нет проблем в его использовании. А что я делаю в вашем случае? Тереблю колесико 5 минут или пользуюсь скролом, который вешает вкладку? Какой смысл выводить потенциальные 9000 товаров, если пользователь все равно не сможет до этой условной девятой тысячи добраться? А если доберется — то у него все будет тормозить, виснуть, жрать память и т.д.? Получается, вы предоставили возможность домотать до 9000 товара, но тут же говорите, что «мотать не надо». А зачем даете потенциальную возможность, если «не надо»?
Это просто ссылка на все связанные проекты в конце. А про промис-миддлеваре написано прямо в разделе миддлеваре.
> Правильно, потому что редакс идеологически синхронен.
Потому что он не о том. Редакс — про изменение стейта через композабельные редьюсеры, а саги — про декларативное описание эффектов. То, что саги прикручены к редаксу — это вообще исторический казус (там от редакса реально используется десяток строк кода). И у них, насколько я помню, даже issue был на откручивание.
> Промис не чист по определению, мы это уже обсуждали.
«чистейший» в смысле «чисто промис», а не в смысле чистой функции в терминологии фп :)
> Ну как это. Вся фишка в возможности обрабатывать в одном редьюсере разные экшены.
Разные _типы_ экшонов. А сам экшон вы обрабатываете каждый раз один единственный — который к вам прилетел. И про другие вы вообще не в курсе.
> Вообще-то нет. doAnything() не содержит в себе эффекта, эффект описан в саге как реакция на результат doAnything
Давайте начнем с того, что вообще, по дефолту, в редаксе никаких саг нет. И если, например, те же миддлеваре для промисов упоминаются в доках, то саги — не упоминаются.
Надо понимать, что, фактически, саги имеют очень мало общего с редаксом в плане архитектуры — они просто используют миддлеваре-инфраструктуру редакса как базу для интерпретатора своего дсл'я. Интерпретатор (сага-мидлеваре) по одному принимает сага-команды и исполняет их. Заметьте — вы даже можете полностью отказаться от редьюсеров и писать вместо них так же саги (некоторые так и делают). Тогда от редакса ничего кроме лупа интерпретатора внутри dispatch вообще не остается!
> А если у вас внутри doAnything промисы, thunk'и и прочая белиберда, так это значит, что идея redux нарушается.
Ну как это нарушается? С промис-мидлеваре у вас там и будет промис, вот прям самый что ни на есть тупо-промис, обыкновеннейший, чистейший. И это более «дефолтное» для редакса решение, чем саги (которые вообще не стоит рассматривать в контексте архитектуры редакса в силу указанных выше причин).
В редьюсере на порядок завязаться нельзя в принципе, для редьюсера никаких экшонов кроме одного не существует. Речь изначально шла конкретно о том, что когда вы делаете store.dispatch(doAnything()) вместо функционального вызова doAnything(...) — то не надо думать, что вы чудесным образом избавляетесь от классических проблем с управлением стейта. Происходит-то в результате этого вызова одно и то же — грязный вызов грязных эффектов.
А я вот только неделю назад заметил, что на хабре есть поле поиска. Надо, оказывается, кликнуть на лупу. До этого я думал, что поиска нет кроме как на https://habrahabr.ru/search/
А что там до слепоты — чтобы это поле увидеть, надо еще нажать 32-пиксельную белую кнопку на белом фоне заныканную в самый угол экрана. Скажу честно — если бы я заранее не знал, что на вашей странице есть фильтры, я бы их не обнаружил.
> Никакой асинхронный экшон за это время не прилетит. ДА, оно может заспавнить асинхронные сайд-эффектовые экшоны. Которые никак не повляют на данные, потому что когда им придет время резолвится, они точно так же отправят простые экшоны в стор.
Вы сами себе противоречите. Если асинхронный экшон может отправить в стор обычный — то этот асинхронный экшон МОЖЕТ влиять на данные. Тот факт, что вы делаете это через промежуточный вызов — никак не сказывается вообще на control-flow вашего приложения. Нет никакой разницы между вызовом экшона и вызовом функции, апдейтящей стор напрямую.
> Эта фича позволяет быстро показать страницу, не парясь по поводу количества найденных фильтром товаров.
То есть вы сперва выдумали проблему (зачем-то решили показывать пользователю 9к товаров), а потом ее героически преодолели, не показывая их сразу, а показывая по-немногу.
> А браузерный поиск не нужен, если есть соответствующий фильтр по тексту.
Я когда захочу что-то найти на странице, то точно не стану искать какой-то там фильтр по тексту, а нажму ctrl+f. И когда поиск ничего не найдет — то в первую очередь подумаю, что на странице просто и нет соответствующих данных, а не то, что они не подгружены из-за виртуального скролла.
Я не представляю такой ситуации, когда пользователь упорно проматывает тысячи товаров — не важно, в каком виде. Хоть скроллом, хоть с пагинацией, как угодно.
Очевидно, пользователь сперва применит какие-то фильтры, а потом, когда товаров останется ~несколько сотен, уже и будет просматривать.
Выходит, что:
1. в том случае, когда у вас 9к товаров, виртуальный скролл не нужен, потому что пользователь все равно не будет скроллить
2. а когда товаров несколько сотен — виртуальный скролл не нужен, потому что их можно подгрузить целиком
В итоге получается что какая-то ненужная (в данном конкретном случае, я не говорю, что виртуальный скролл вообще никогда не нужен) фича.
Ну и еще на десктопах меня лично виртуальный скролл всегда бесит — с ним, по очевидным причинам, не работает поиск
Ни разу не встречал такой ситуации, когда экшоны на клиенте четко соответствуют апи. Обычно отдельно слой взаимодействия с бекендом, отдельно — экшоны (они зависят от функциональности клиента, а не от апи, апи и слой взаимодействия с ним как раз могут быть заменены, а экшоны останутся теми же). Если в вашем случае это соответствие есть — тогда да, будет удобно все работать.
Так он же возвращает то, что возвращает middleware. Не понял, как это решит проблему с отсутствием детерменизма в обработке. Вот вам прилетел в стор асинхронный экшон, потом еще один (до того, как зарезолвился первый). Какой из них в итоге первый зарезолвится — неизвестно, и результат будет зависеть от порядка.
А зачем вообще вы пытаетесь выводить на одной странице 9000 товаров? Какова вероятность того, что пользователь промотает хотя бы до 1000? Вы всерьез можете представить ситуацию, как пользователь упорно сидит и мотает 5 минут страницу???
> Конкретно всё это безобразие можно реализовать и другими способами (от предложенного общего сервиса, до синглтона-хранилища-состояний). Но у использования того же localStorage в данном конкретном примере очевидны свои плюсы.
Да его смотреть не надо, понятно, что там гарантированно будет что-то для обработка асинхронщины, и этого уже достаточно, чтобы вся «красота и функциональность» редакса чудесным образом исчезла.
> Суть такая что все сайд эффекты локализованы в action-creator'ах и middleware. Это дает значительно больше уверенности, нежели когда сайд-эффекты размазаны по структуре сервисов
Чем размазывание по сервисам отличается от размазывания по асинхронным экшонам? Там разница в коде — минимальная и чисто синтаксическая.
> А promise или observable возвращать не?
Возвращать, извините, откуда? store.dispatch(action) — вот здесь, из dispatch?
А в чем преимущество предложенного решения перед стандартный workflow? Точно так же ведь надо объявить типы экшенов, создать экшен криэйторы, написать редьюсеры. Что изменилось?
Не actions не изолированы, а апдейт стейта. Потому что его можно апдейтить просто через x = y. Чем это отличается от старого доброго двустороннего биндинга из первого ангуляра?
> каждый «корневой» компонент (как правило, привязанный к опредленному роуту) получает свое актуальное состояние с бэка при инициализации или изменении параметров роута
Если стейт хранится на беке, то как его потом синхронно обновить? Вот у вас есть несколько несвязанных компонент, каждая из которых подтягивает копию некоторого стейта с бекенда, в одной из компонент стейт обновили => он ушел на бекенд, как обновить остальные копии стейта, в других компонентах? Какая часть программы отвечает за то, что остальные компоненты сделают в этот момент запрос к бекенду и обновят свой стейт? Или в таких случаях только руками через output и надеяться, что не придется прокидывать слишком далеко?
> Эти принципы подробно описаны в официальной документации Angular-а и, как мне показалось, являются тем самым angular way.
Я точно не помню сейчас уже, но мне казалось, что в доках описывается вариант обмена данными между компонентами через сервис.
> То есть важно, как mobx с этим observable работает. Именно в этом может быть зарыта императивность, а не в самом наличии observable.
А по самому вопросу — например, она может выражаться в том, как изменяется в mobx стейт (через аналог двустороннего биндинга вместо изоляции при помощи actions)
Так он все равно не домотает, докуда хочет, зачем предоставлять возможность, которую нельзя использовать? Или вы полагаете, что кто-то правда будет 5 минут крутить?..
Вы знаете, это как на сайт повесить кнопку, при клике на которую она будет вешать вкладку. Можно, конечно. Но зачем?
Это просто ссылка на все связанные проекты в конце. А про промис-миддлеваре написано прямо в разделе миддлеваре.
> Правильно, потому что редакс идеологически синхронен.
Потому что он не о том. Редакс — про изменение стейта через композабельные редьюсеры, а саги — про декларативное описание эффектов. То, что саги прикручены к редаксу — это вообще исторический казус (там от редакса реально используется десяток строк кода). И у них, насколько я помню, даже issue был на откручивание.
> Промис не чист по определению, мы это уже обсуждали.
«чистейший» в смысле «чисто промис», а не в смысле чистой функции в терминологии фп :)
Разные _типы_ экшонов. А сам экшон вы обрабатываете каждый раз один единственный — который к вам прилетел. И про другие вы вообще не в курсе.
> Вообще-то нет. doAnything() не содержит в себе эффекта, эффект описан в саге как реакция на результат doAnything
Давайте начнем с того, что вообще, по дефолту, в редаксе никаких саг нет. И если, например, те же миддлеваре для промисов упоминаются в доках, то саги — не упоминаются.
Надо понимать, что, фактически, саги имеют очень мало общего с редаксом в плане архитектуры — они просто используют миддлеваре-инфраструктуру редакса как базу для интерпретатора своего дсл'я. Интерпретатор (сага-мидлеваре) по одному принимает сага-команды и исполняет их. Заметьте — вы даже можете полностью отказаться от редьюсеров и писать вместо них так же саги (некоторые так и делают). Тогда от редакса ничего кроме лупа интерпретатора внутри dispatch вообще не остается!
> А если у вас внутри doAnything промисы, thunk'и и прочая белиберда, так это значит, что идея redux нарушается.
Ну как это нарушается? С промис-мидлеваре у вас там и будет промис, вот прям самый что ни на есть тупо-промис, обыкновеннейший, чистейший. И это более «дефолтное» для редакса решение, чем саги (которые вообще не стоит рассматривать в контексте архитектуры редакса в силу указанных выше причин).
А что там до слепоты — чтобы это поле увидеть, надо еще нажать 32-пиксельную белую кнопку на белом фоне заныканную в самый угол экрана. Скажу честно — если бы я заранее не знал, что на вашей странице есть фильтры, я бы их не обнаружил.
Вы сами себе противоречите. Если асинхронный экшон может отправить в стор обычный — то этот асинхронный экшон МОЖЕТ влиять на данные. Тот факт, что вы делаете это через промежуточный вызов — никак не сказывается вообще на control-flow вашего приложения. Нет никакой разницы между вызовом экшона и вызовом функции, апдейтящей стор напрямую.
То есть вы сперва выдумали проблему (зачем-то решили показывать пользователю 9к товаров), а потом ее героически преодолели, не показывая их сразу, а показывая по-немногу.
> А браузерный поиск не нужен, если есть соответствующий фильтр по тексту.
Я когда захочу что-то найти на странице, то точно не стану искать какой-то там фильтр по тексту, а нажму ctrl+f. И когда поиск ничего не найдет — то в первую очередь подумаю, что на странице просто и нет соответствующих данных, а не то, что они не подгружены из-за виртуального скролла.
Это никак не отменяет того, что порядок, в котором простые экшоны потом придут к вам в редьюсер, не определен.
Очевидно, пользователь сперва применит какие-то фильтры, а потом, когда товаров останется ~несколько сотен, уже и будет просматривать.
Выходит, что:
1. в том случае, когда у вас 9к товаров, виртуальный скролл не нужен, потому что пользователь все равно не будет скроллить
2. а когда товаров несколько сотен — виртуальный скролл не нужен, потому что их можно подгрузить целиком
В итоге получается что какая-то ненужная (в данном конкретном случае, я не говорю, что виртуальный скролл вообще никогда не нужен) фича.
Ну и еще на десктопах меня лично виртуальный скролл всегда бесит — с ним, по очевидным причинам, не работает поиск
https://github.com/btroncone/ngrx-store-localstorage
Да его смотреть не надо, понятно, что там гарантированно будет что-то для обработка асинхронщины, и этого уже достаточно, чтобы вся «красота и функциональность» редакса чудесным образом исчезла.
> Суть такая что все сайд эффекты локализованы в action-creator'ах и middleware. Это дает значительно больше уверенности, нежели когда сайд-эффекты размазаны по структуре сервисов
Чем размазывание по сервисам отличается от размазывания по асинхронным экшонам? Там разница в коде — минимальная и чисто синтаксическая.
> А promise или observable возвращать не?
Возвращать, извините, откуда? store.dispatch(action) — вот здесь, из dispatch?
Если стейт хранится на беке, то как его потом синхронно обновить? Вот у вас есть несколько несвязанных компонент, каждая из которых подтягивает копию некоторого стейта с бекенда, в одной из компонент стейт обновили => он ушел на бекенд, как обновить остальные копии стейта, в других компонентах? Какая часть программы отвечает за то, что остальные компоненты сделают в этот момент запрос к бекенду и обновят свой стейт? Или в таких случаях только руками через output и надеяться, что не придется прокидывать слишком далеко?
> Эти принципы подробно описаны в официальной документации Angular-а и, как мне показалось, являются тем самым angular way.
Я точно не помню сейчас уже, но мне казалось, что в доках описывается вариант обмена данными между компонентами через сервис.
> То есть важно, как mobx с этим observable работает. Именно в этом может быть зарыта императивность, а не в самом наличии observable.
А по самому вопросу — например, она может выражаться в том, как изменяется в mobx стейт (через аналог двустороннего биндинга вместо изоляции при помощи actions)