I
а что с блоками не так? 😄
гов## еб### на стримах
Size: a a a
2020 July 30
AS
гов## еб### на стримах
конструктивненько
KD
Другой кейс, который вечно не даёт покоя — проверка типа стейтов.
Если у нас стейты являются не одним большим классом с кучей флажков, а наследниками какого-нибудь
В том же примере выше, у меня есть лишь обработка кейса
Если у нас стейты являются не одним большим классом с кучей флажков, а наследниками какого-нибудь
MyState, то насколько считается нормальным в определённых кейсах обрабатывать только отдельных наследников, а не всех?В том же примере выше, у меня есть лишь обработка кейса
state is DataFetched, но я не смотрю на случай, когда state is DataIsLoading, потому что по моим прикидкам там его и не должно быть.I
конструктивненько
ну если человек не понимает что архитектура на базе rxjava/dart-stream это го###, то тут и обсуждать дальше нечего
ML
Другой кейс, который вечно не даёт покоя — проверка типа стейтов.
Если у нас стейты являются не одним большим классом с кучей флажков, а наследниками какого-нибудь
В том же примере выше, у меня есть лишь обработка кейса
Если у нас стейты являются не одним большим классом с кучей флажков, а наследниками какого-нибудь
MyState, то насколько считается нормальным в определённых кейсах обрабатывать только отдельных наследников, а не всех?В том же примере выше, у меня есть лишь обработка кейса
state is DataFetched, но я не смотрю на случай, когда state is DataIsLoading, потому что по моим прикидкам там его и не должно быть.Разбивай на функции поменьше
ML
а что с блоками не так? 😄
Потоки потоки everywhere
KD
Разбивай на функции поменьше
Стараюсь так делать, но если типов стейтов будет ~10, то на каждый эвент по 11 функций, многие из которых будут не нужны вовсе, т.к. будет состоянием к которому приложение не должно приходить.
AD
Было:
* Добавляется\удаляется пользователь
* выставляется стейт на загрузку
* данные обновляются и выдаются в стейте с данными
Стало:
* Добавляется (но не удаляется) пользователь
* Надо обновить данные только для нового пользователя
* Но надо показать загрузку
* Приходится в обработчике (читай
Т.к. если сразу вкинуть стейт загрузки мы теряем стейт с данными пользователей
* Добавляется\удаляется пользователь
* выставляется стейт на загрузку
* данные обновляются и выдаются в стейте с данными
Стало:
* Добавляется (но не удаляется) пользователь
* Надо обновить данные только для нового пользователя
* Но надо показать загрузку
* Приходится в обработчике (читай
reducer, но тут немного другая залупа) сохранять предыдущий стейт, чтобы потом из него достать предыдущие данные и добавлять к ним данные нового пользователяТ.к. если сразу вкинуть стейт загрузки мы теряем стейт с данными пользователей
если я правильно понял, то происходит такое:
- ивент о новом юзере
- делаем какой-то эффект и получаем список юзеров с учетом нового
- пока не получим юзеров, показываем лоадер
- показываем новый список
можно же сделать так:
- ивент о новом юзере
- добавили его в стейт и список здесь же (показали)
- послали эффект на добавление юзера
- ивент о новом юзере
- делаем какой-то эффект и получаем список юзеров с учетом нового
- пока не получим юзеров, показываем лоадер
- показываем новый список
можно же сделать так:
- ивент о новом юзере
- добавили его в стейт и список здесь же (показали)
- послали эффект на добавление юзера
RU
В смысле, а как же #desktop_app_live_matter
#desktop_app_live_matter
AD
Другой кейс, который вечно не даёт покоя — проверка типа стейтов.
Если у нас стейты являются не одним большим классом с кучей флажков, а наследниками какого-нибудь
В том же примере выше, у меня есть лишь обработка кейса
Если у нас стейты являются не одним большим классом с кучей флажков, а наследниками какого-нибудь
MyState, то насколько считается нормальным в определённых кейсах обрабатывать только отдельных наследников, а не всех?В том же примере выше, у меня есть лишь обработка кейса
state is DataFetched, но я не смотрю на случай, когда state is DataIsLoading, потому что по моим прикидкам там его и не должно быть.проверку на тип стейта «решил» грязно - у меня стейт:
interface SomeState {
fun reduce(msg: Msg) = TODO()
}
плюсы:
+ нет проверки на тип стейта
+ каждый стейт - своего рода черный ящик с входом и выходом
минусы:
- черный ящик умеет создавать другие стейты и вообще знает про них
interface SomeState {
fun reduce(msg: Msg) = TODO()
}
плюсы:
+ нет проверки на тип стейта
+ каждый стейт - своего рода черный ящик с входом и выходом
минусы:
- черный ящик умеет создавать другие стейты и вообще знает про них
KD
если я правильно понял, то происходит такое:
- ивент о новом юзере
- делаем какой-то эффект и получаем список юзеров с учетом нового
- пока не получим юзеров, показываем лоадер
- показываем новый список
можно же сделать так:
- ивент о новом юзере
- добавили его в стейт и список здесь же (показали)
- послали эффект на добавление юзера
- ивент о новом юзере
- делаем какой-то эффект и получаем список юзеров с учетом нового
- пока не получим юзеров, показываем лоадер
- показываем новый список
можно же сделать так:
- ивент о новом юзере
- добавили его в стейт и список здесь же (показали)
- послали эффект на добавление юзера
Беда в том, что твой кейс подразумевает, что список юзеров с учётом нового собирается где-то там в обработке эффекта, но нет. У меня он хранится только в стейте и больше нигде.
Поэтому и выходит такое, что при новом юзере нужно обновить его данные и добавить эти данные к тому списку, что был в предыдущем стейте.
Поэтому и выходит такое, что при новом юзере нужно обновить его данные и добавить эти данные к тому списку, что был в предыдущем стейте.
AD
Беда в том, что твой кейс подразумевает, что список юзеров с учётом нового собирается где-то там в обработке эффекта, но нет. У меня он хранится только в стейте и больше нигде.
Поэтому и выходит такое, что при новом юзере нужно обновить его данные и добавить эти данные к тому списку, что был в предыдущем стейте.
Поэтому и выходит такое, что при новом юзере нужно обновить его данные и добавить эти данные к тому списку, что был в предыдущем стейте.
вот мое предложение как раз и было про то, что список зверей только в стейте живет)
AD
KD
вот мое предложение как раз и было про то, что список зверей только в стейте живет)
Если ты о:
То не выйдет, т.к. нам сначала надо получить данные, а уже потом показать их.
Но снова таки, как я понял, это считается нормальной практикой держать ссылку на предыдущий стейт, тогда вопросов тут и нет
можно же сделать так:
- ивент о новом юзере
- добавили его в стейт и список здесь же (показали)
- послали эффект на добавление юзера
То не выйдет, т.к. нам сначала надо получить данные, а уже потом показать их.
Но снова таки, как я понял, это считается нормальной практикой держать ссылку на предыдущий стейт, тогда вопросов тут и нет
AD
Если ты о:
То не выйдет, т.к. нам сначала надо получить данные, а уже потом показать их.
Но снова таки, как я понял, это считается нормальной практикой держать ссылку на предыдущий стейт, тогда вопросов тут и нет
можно же сделать так:
- ивент о новом юзере
- добавили его в стейт и список здесь же (показали)
- послали эффект на добавление юзера
То не выйдет, т.к. нам сначала надо получить данные, а уже потом показать их.
Но снова таки, как я понял, это считается нормальной практикой держать ссылку на предыдущий стейт, тогда вопросов тут и нет
получай данные в момент создания ивента
KD
получай данные в момент создания ивента
И смысл? Они там где-то получаются, мы никак не оповещаем пользователя, что идёт обновление и потом в один момент просто *бац* у вас тут новый пользователь прилетел.
AD
резонно
KD
А юзер непонимая будет клацать кнопку обновление, тем самым за зря обновляя всё
AD
ладно, похоже, что проблема вполне себе решилась)
I
Беда в том, что твой кейс подразумевает, что список юзеров с учётом нового собирается где-то там в обработке эффекта, но нет. У меня он хранится только в стейте и больше нигде.
Поэтому и выходит такое, что при новом юзере нужно обновить его данные и добавить эти данные к тому списку, что был в предыдущем стейте.
Поэтому и выходит такое, что при новом юзере нужно обновить его данные и добавить эти данные к тому списку, что был в предыдущем стейте.
> это считается нормальной практикой держать ссылку на предыдущий стейт
Я так и не понял, что ты хочешь, но вот тебе sanity check:
- перепиши это на Elm, если получится, значит валидная архитектура