Сообщение Re[12]: Про обработку ошибок - типовые решения от 27.04.2025 15:16
Изменено 27.04.2025 15:17 Shmj
Re[12]: Про обработку ошибок - типовые решения
Здравствуйте, Sinclair, Вы писали:
S>>А есть же другие архитектуры — как flutter_bloc. Блок и его состояние хранятся отдельно — форму закрыли, а блок глобально зареган.
S>Это не flutter виноват в том, что у вас в голове каша. Форму закрыли => нет и вопроса о том, как обновить её состояние после окончания асинхронного запроса.
В современных приложениях ты обновляешь не форму а состояние. При этом может сразу несколько форм обновиться.
S>>Но дело даже не в этом. Даже в том же WinForms — вы можете сделать глобальное событие, которое оповестить сразу N открытых форм. Так вот — прежде чем оповещать — нужно проверить что пользователь тот же самый.
S>Что такое "оповещать"? Зачем это вообще делать?
Чтобы все было интерактивно — событие произошло — все формы, которые связаны с этим событием — мгновенно под него подстроились.
Забывайте дедовские технологии, когда событие было привязано к одной форме.
S>>Боле того — запрос к серверу может быть не один а много
S>Вот именно.
S>>- так вот, после первого мы уже можем знать что пользователь изменился и далее нет смысла делать запросы. Как оборвать процесс?
S>Перестаньте мыслить категориями "пользователь изменился". Забудьте об этом. Вы же видите, что
S>а) в вашей парадигме возникают проблемы
S>б) ни у кого другого таких проблем не возникает
Возникают — у многих. Но многим пофиг — нет стройной идеологии.
Либо решают как вы — что не может быть удобства в виде интерактивного обновления множества данных. Т.е. отказ от удобств. Либо забивают на то что такое интерактивное обновление очень редко но метко может внести проблемы, о которых сразу не думаешь.
S>Посмотрите на то, как сделано примерно 100% софта.
S>1. Как правило, нет никакой локальной базы. Нет базы — нет проблем. Банковские приложения, госуслуги, авиасейлз, покупка билетов в театр и прочее — прекрасно живут без локальных баз и фоновых запросов
Вы в каком году живете? Везде даже у каждого сайта есть локальная база на сегодня.
S>2. Если есть локальная база, то, как правило, она является либо репликой фрагмента глобальной базы, либо используется для детерминистического управления состоянием. В обоих случаях всё работает вполне простым и предсказуемым образом.
Ну вот вам и предсказуемым — пользователь изменился и привет. Просто обычно об этом не думают, т.к. проблема возникает редко и тестеры особо даже не тестируют.
S>>А есть же другие архитектуры — как flutter_bloc. Блок и его состояние хранятся отдельно — форму закрыли, а блок глобально зареган.
S>Это не flutter виноват в том, что у вас в голове каша. Форму закрыли => нет и вопроса о том, как обновить её состояние после окончания асинхронного запроса.
В современных приложениях ты обновляешь не форму а состояние. При этом может сразу несколько форм обновиться.
S>>Но дело даже не в этом. Даже в том же WinForms — вы можете сделать глобальное событие, которое оповестить сразу N открытых форм. Так вот — прежде чем оповещать — нужно проверить что пользователь тот же самый.
S>Что такое "оповещать"? Зачем это вообще делать?
Чтобы все было интерактивно — событие произошло — все формы, которые связаны с этим событием — мгновенно под него подстроились.
Забывайте дедовские технологии, когда событие было привязано к одной форме.
S>>Боле того — запрос к серверу может быть не один а много
S>Вот именно.
S>>- так вот, после первого мы уже можем знать что пользователь изменился и далее нет смысла делать запросы. Как оборвать процесс?
S>Перестаньте мыслить категориями "пользователь изменился". Забудьте об этом. Вы же видите, что
S>а) в вашей парадигме возникают проблемы
S>б) ни у кого другого таких проблем не возникает
Возникают — у многих. Но многим пофиг — нет стройной идеологии.
Либо решают как вы — что не может быть удобства в виде интерактивного обновления множества данных. Т.е. отказ от удобств. Либо забивают на то что такое интерактивное обновление очень редко но метко может внести проблемы, о которых сразу не думаешь.
S>Посмотрите на то, как сделано примерно 100% софта.
S>1. Как правило, нет никакой локальной базы. Нет базы — нет проблем. Банковские приложения, госуслуги, авиасейлз, покупка билетов в театр и прочее — прекрасно живут без локальных баз и фоновых запросов
Вы в каком году живете? Везде даже у каждого сайта есть локальная база на сегодня.
S>2. Если есть локальная база, то, как правило, она является либо репликой фрагмента глобальной базы, либо используется для детерминистического управления состоянием. В обоих случаях всё работает вполне простым и предсказуемым образом.
Ну вот вам и предсказуемым — пользователь изменился и привет. Просто обычно об этом не думают, т.к. проблема возникает редко и тестеры особо даже не тестируют.
Re[12]: Про обработку ошибок - типовые решения
Здравствуйте, Sinclair, Вы писали:
S>>А есть же другие архитектуры — как flutter_bloc. Блок и его состояние хранятся отдельно — форму закрыли, а блок глобально зареган.
S>Это не flutter виноват в том, что у вас в голове каша. Форму закрыли => нет и вопроса о том, как обновить её состояние после окончания асинхронного запроса.
В современных приложениях ты обновляешь не форму а состояние. При этом может сразу несколько форм обновиться.
S>>Но дело даже не в этом. Даже в том же WinForms — вы можете сделать глобальное событие, которое оповестить сразу N открытых форм. Так вот — прежде чем оповещать — нужно проверить что пользователь тот же самый.
S>Что такое "оповещать"? Зачем это вообще делать?
Чтобы все было интерактивно — событие произошло — все формы, которые связаны с этим событием — мгновенно под него подстроились.
Забывайте дедовские технологии, когда событие было привязано к одной форме.
S>>Боле того — запрос к серверу может быть не один а много
S>Вот именно.
S>>- так вот, после первого мы уже можем знать что пользователь изменился и далее нет смысла делать запросы. Как оборвать процесс?
S>Перестаньте мыслить категориями "пользователь изменился". Забудьте об этом. Вы же видите, что
S>а) в вашей парадигме возникают проблемы
S>б) ни у кого другого таких проблем не возникает
Возникают — у многих. Но многим пофиг — нет стройной идеологии.
Либо решают как вы — что не может быть удобства в виде интерактивного обновления множества форм. Т.е. отказ от удобств. Либо забивают на то что такое интерактивное обновление очень редко но метко может внести проблемы, о которых сразу не думаешь.
S>Посмотрите на то, как сделано примерно 100% софта.
S>1. Как правило, нет никакой локальной базы. Нет базы — нет проблем. Банковские приложения, госуслуги, авиасейлз, покупка билетов в театр и прочее — прекрасно живут без локальных баз и фоновых запросов
Вы в каком году живете? Везде даже у каждого сайта есть локальная база на сегодня.
S>2. Если есть локальная база, то, как правило, она является либо репликой фрагмента глобальной базы, либо используется для детерминистического управления состоянием. В обоих случаях всё работает вполне простым и предсказуемым образом.
Ну вот вам и предсказуемым — пользователь изменился и привет. Просто обычно об этом не думают, т.к. проблема возникает редко и тестеры особо даже не тестируют.
S>>А есть же другие архитектуры — как flutter_bloc. Блок и его состояние хранятся отдельно — форму закрыли, а блок глобально зареган.
S>Это не flutter виноват в том, что у вас в голове каша. Форму закрыли => нет и вопроса о том, как обновить её состояние после окончания асинхронного запроса.
В современных приложениях ты обновляешь не форму а состояние. При этом может сразу несколько форм обновиться.
S>>Но дело даже не в этом. Даже в том же WinForms — вы можете сделать глобальное событие, которое оповестить сразу N открытых форм. Так вот — прежде чем оповещать — нужно проверить что пользователь тот же самый.
S>Что такое "оповещать"? Зачем это вообще делать?
Чтобы все было интерактивно — событие произошло — все формы, которые связаны с этим событием — мгновенно под него подстроились.
Забывайте дедовские технологии, когда событие было привязано к одной форме.
S>>Боле того — запрос к серверу может быть не один а много
S>Вот именно.
S>>- так вот, после первого мы уже можем знать что пользователь изменился и далее нет смысла делать запросы. Как оборвать процесс?
S>Перестаньте мыслить категориями "пользователь изменился". Забудьте об этом. Вы же видите, что
S>а) в вашей парадигме возникают проблемы
S>б) ни у кого другого таких проблем не возникает
Возникают — у многих. Но многим пофиг — нет стройной идеологии.
Либо решают как вы — что не может быть удобства в виде интерактивного обновления множества форм. Т.е. отказ от удобств. Либо забивают на то что такое интерактивное обновление очень редко но метко может внести проблемы, о которых сразу не думаешь.
S>Посмотрите на то, как сделано примерно 100% софта.
S>1. Как правило, нет никакой локальной базы. Нет базы — нет проблем. Банковские приложения, госуслуги, авиасейлз, покупка билетов в театр и прочее — прекрасно живут без локальных баз и фоновых запросов
Вы в каком году живете? Везде даже у каждого сайта есть локальная база на сегодня.
S>2. Если есть локальная база, то, как правило, она является либо репликой фрагмента глобальной базы, либо используется для детерминистического управления состоянием. В обоих случаях всё работает вполне простым и предсказуемым образом.
Ну вот вам и предсказуемым — пользователь изменился и привет. Просто обычно об этом не думают, т.к. проблема возникает редко и тестеры особо даже не тестируют.