AM
Армения, грузия? Хм. Грузии может и не стать, как это было в 2008...
Size: a a a
2021 March 16
AM
Армения? Да вот 2020ый как раз..
D
Kd
Dima
опоздал
AM
День охуетительных новостей, правда?))
D
Konstantin dmz9
опоздал
Не читал ещё чат
D
Подпольная наука
D
Реквестую уголовные дела
AM
В Словакии ещё всё очень хорошо. И Интернет свободен, и штрафы за торренты, как в Германии, не присылают :)
D
За нелегальные лекции
Kd
ну работающая правовая система это обоюдоострый меч
KD
Такой архитектурный вопрос, касаемый UDF и глобального стейта.
Есть, значит, общий стейт приложения, который состоит из сборной солянки мелких стейтов. Условный
Эти мелкие стейты — общие, а не привязанные к какому-то конкретному экрану.
Т.е., условный стейт с данными, который просто содержит эти самые данные, их статус и пр., а экраны уже на основе этого строятся.
Однако!
Появилась нужда в более местячковых стейтах, для конкретных экранов и не более.
Пример: экран добавления новой сущности. Стейт нужен при открытии экрана, при создании, получении ошибок, но после успешного создания он уже лишний.
Вот обдумываю такое дело, но не могу прийти к какому-то решению, которое казалось бы хорошим.
1: Можно завести полноценный отдельный стейт под экран добавления, который не будет композироваться в
2: Встроить таки его в
Как вы считаете как принято это делать?
(конкретно речь о redux, но в целом вопрос ложится на любую udf архитектуру)
@themishkun, ты вроде любитель такого, что скажешь?
Есть, значит, общий стейт приложения, который состоит из сборной солянки мелких стейтов. Условный
AppState(DataState, AuthState)Эти мелкие стейты — общие, а не привязанные к какому-то конкретному экрану.
Т.е., условный стейт с данными, который просто содержит эти самые данные, их статус и пр., а экраны уже на основе этого строятся.
Однако!
Появилась нужда в более местячковых стейтах, для конкретных экранов и не более.
Пример: экран добавления новой сущности. Стейт нужен при открытии экрана, при создании, получении ошибок, но после успешного создания он уже лишний.
Вот обдумываю такое дело, но не могу прийти к какому-то решению, которое казалось бы хорошим.
1: Можно завести полноценный отдельный стейт под экран добавления, который не будет композироваться в
AppState.2: Встроить таки его в
AppState, но дополнительно придётся обнулять его в нужные моменты.Как вы считаете как принято это делать?
(конкретно речь о redux, но в целом вопрос ложится на любую udf архитектуру)
@themishkun, ты вроде любитель такого, что скажешь?
Kd
В Словакии ещё всё очень хорошо. И Интернет свободен, и штрафы за торренты, как в Германии, не присылают :)
с одной стороны тебя обидеть сложнее, с другой стороны штрафы за порренты, окей...
Kd
Такой архитектурный вопрос, касаемый UDF и глобального стейта.
Есть, значит, общий стейт приложения, который состоит из сборной солянки мелких стейтов. Условный
Эти мелкие стейты — общие, а не привязанные к какому-то конкретному экрану.
Т.е., условный стейт с данными, который просто содержит эти самые данные, их статус и пр., а экраны уже на основе этого строятся.
Однако!
Появилась нужда в более местячковых стейтах, для конкретных экранов и не более.
Пример: экран добавления новой сущности. Стейт нужен при открытии экрана, при создании, получении ошибок, но после успешного создания он уже лишний.
Вот обдумываю такое дело, но не могу прийти к какому-то решению, которое казалось бы хорошим.
1: Можно завести полноценный отдельный стейт под экран добавления, который не будет композироваться в
2: Встроить таки его в
Как вы считаете как принято это делать?
(конкретно речь о redux, но в целом вопрос ложится на любую udf архитектуру)
@themishkun, ты вроде любитель такого, что скажешь?
Есть, значит, общий стейт приложения, который состоит из сборной солянки мелких стейтов. Условный
AppState(DataState, AuthState)Эти мелкие стейты — общие, а не привязанные к какому-то конкретному экрану.
Т.е., условный стейт с данными, который просто содержит эти самые данные, их статус и пр., а экраны уже на основе этого строятся.
Однако!
Появилась нужда в более местячковых стейтах, для конкретных экранов и не более.
Пример: экран добавления новой сущности. Стейт нужен при открытии экрана, при создании, получении ошибок, но после успешного создания он уже лишний.
Вот обдумываю такое дело, но не могу прийти к какому-то решению, которое казалось бы хорошим.
1: Можно завести полноценный отдельный стейт под экран добавления, который не будет композироваться в
AppState.2: Встроить таки его в
AppState, но дополнительно придётся обнулять его в нужные моменты.Как вы считаете как принято это делать?
(конкретно речь о redux, но в целом вопрос ложится на любую udf архитектуру)
@themishkun, ты вроде любитель такого, что скажешь?
рост приложения спровоцирует увеличение сложности менеджмента если вклеишь. держи отдельно конечно, это проще
KD
Konstantin dmz9
рост приложения спровоцирует увеличение сложности менеджмента если вклеишь. держи отдельно конечно, это проще
Пока к этому тоже склоняюсь.
Но тогда теряется часть прелести единого стейта.
Но тогда теряется часть прелести единого стейта.
AM
Dima
За нелегальные лекции
Изи подтекст понять: "нечего тут свои технологии обхода блокировочек выдумывать. А то сядете. Вот. Или штраф олимпиард деревянных".
(
Такой архитектурный вопрос, касаемый UDF и глобального стейта.
Есть, значит, общий стейт приложения, который состоит из сборной солянки мелких стейтов. Условный
Эти мелкие стейты — общие, а не привязанные к какому-то конкретному экрану.
Т.е., условный стейт с данными, который просто содержит эти самые данные, их статус и пр., а экраны уже на основе этого строятся.
Однако!
Появилась нужда в более местячковых стейтах, для конкретных экранов и не более.
Пример: экран добавления новой сущности. Стейт нужен при открытии экрана, при создании, получении ошибок, но после успешного создания он уже лишний.
Вот обдумываю такое дело, но не могу прийти к какому-то решению, которое казалось бы хорошим.
1: Можно завести полноценный отдельный стейт под экран добавления, который не будет композироваться в
2: Встроить таки его в
Как вы считаете как принято это делать?
(конкретно речь о redux, но в целом вопрос ложится на любую udf архитектуру)
@themishkun, ты вроде любитель такого, что скажешь?
Есть, значит, общий стейт приложения, который состоит из сборной солянки мелких стейтов. Условный
AppState(DataState, AuthState)Эти мелкие стейты — общие, а не привязанные к какому-то конкретному экрану.
Т.е., условный стейт с данными, который просто содержит эти самые данные, их статус и пр., а экраны уже на основе этого строятся.
Однако!
Появилась нужда в более местячковых стейтах, для конкретных экранов и не более.
Пример: экран добавления новой сущности. Стейт нужен при открытии экрана, при создании, получении ошибок, но после успешного создания он уже лишний.
Вот обдумываю такое дело, но не могу прийти к какому-то решению, которое казалось бы хорошим.
1: Можно завести полноценный отдельный стейт под экран добавления, который не будет композироваться в
AppState.2: Встроить таки его в
AppState, но дополнительно придётся обнулять его в нужные моменты.Как вы считаете как принято это делать?
(конкретно речь о redux, но в целом вопрос ложится на любую udf архитектуру)
@themishkun, ты вроде любитель такого, что скажешь?
Если упарываться в край в ультра-глобальный стейт, то по-хорошему в этом же стейте нужно держать и навигацию. Если навигация лежит в стейте, то описанная проблема автоматически уходит, потому что если этот экран лежит там в каком-то условном стеке, то когда пользователь из него выйдет, он уберется из стека.
Но у нас пока на андроиде все хуево с этим, поэтому проще выпилить в отдельный стейт
Но у нас пока на андроиде все хуево с этим, поэтому проще выпилить в отдельный стейт
KD
Если упарываться в край в ультра-глобальный стейт, то по-хорошему в этом же стейте нужно держать и навигацию. Если навигация лежит в стейте, то описанная проблема автоматически уходит, потому что если этот экран лежит там в каком-то условном стеке, то когда пользователь из него выйдет, он уберется из стека.
Но у нас пока на андроиде все хуево с этим, поэтому проще выпилить в отдельный стейт
Но у нас пока на андроиде все хуево с этим, поэтому проще выпилить в отдельный стейт
У меня флаттер, но там с навигацией в стейте тоже головной боли хватает, т.к. нет единой обработки всех кейсов.
Kd
