Д
так, а в чём проблема то? И как это – "cлучайное" воздействие?
Ну лучше же когда такой вероятности физически нет, всегда нужно учитывать человеческий фактор
Size: a a a
2020 August 05
ML
Ну лучше же когда такой вероятности физически нет, всегда нужно учитывать человеческий фактор
а что мешает человеческому фактору в соседнем файле что то изменить? Например, накосячить с построением твоего состояния
Kd
Ну тип менял одно, удалил лишнее условие и поменялось заодно и другое состояние, хз как адекватно это описать
это что за код такой который ломает все приложение
ML
ты пытаешься разделить неразделимое
Д
какое "другое" – оно же у тебя одно. (кстати, НЕизменяемое)
Ну есть состояние отображения данных, если состояние отображения пустого контейнера когда данных нет, это два состояния
ML
Ну есть состояние отображения данных, если состояние отображения пустого контейнера когда данных нет, это два состояния
ещё раз. состояние у тебя одно
ML
либо пустота, либо данные
ML
в этом и есть вся суть, что нет никакого "другого"
ML
всё в одном месте
AM
Ну лучше же когда такой вероятности физически нет, всегда нужно учитывать человеческий фактор
Чтобы такой вероятности физически не было, надо отобрать у погромизда клавиатуру.
AM
Мне кажется, вы воюете с надуманной проблемой.
Д
Ну ладно, убедили
AM
В худшем случае, если за такое страшно, всегда есть тесты и кодревью, которые должны помочь.
Д
То есть тут не идёт речь за иерархию состояний? Есть только одно состояние у которого меняются филды?
Kd
в один момент времени существует одно состояние системы, но в разные моменты будут разные состояния.
и желательно чтобы каждое из таких состояний было иммутабельным, т.е. не "одно и то же с измененными филдами" а "два разных отличающихся филдами"
и желательно чтобы каждое из таких состояний было иммутабельным, т.е. не "одно и то же с измененными филдами" а "два разных отличающихся филдами"
ML
То есть тут не идёт речь за иерархию состояний? Есть только одно состояние у которого меняются филды?
Во-первых, иерархия – это дерево. т.е. ациклический граф. Где ты видел, чтобы из ошибки нельзя было обратно в загрузку перейти.
Во-вторых, у тебя есть состояние, которое общее на все экраны – с ним что ты будешь делать?
Во-вторых, у тебя есть состояние, которое общее на все экраны – с ним что ты будешь делать?
Д
Во-первых, иерархия – это дерево. т.е. ациклический граф. Где ты видел, чтобы из ошибки нельзя было обратно в загрузку перейти.
Во-вторых, у тебя есть состояние, которое общее на все экраны – с ним что ты будешь делать?
Во-вторых, у тебя есть состояние, которое общее на все экраны – с ним что ты будешь делать?
Почему нельзя перейти? У меня в примере есть такой переход
Тут уже зависит от конкретного примера. К примеру у меня там нужно было отрисовать прогресс бар поверх уже существующего состояния, я композицией это реализовал, думаю так же и с общим состоянием можно поступить
Тут уже зависит от конкретного примера. К примеру у меня там нужно было отрисовать прогресс бар поверх уже существующего состояния, я композицией это реализовал, думаю так же и с общим состоянием можно поступить
Д
Konstantin dmz9
в один момент времени существует одно состояние системы, но в разные моменты будут разные состояния.
и желательно чтобы каждое из таких состояний было иммутабельным, т.е. не "одно и то же с измененными филдами" а "два разных отличающихся филдами"
и желательно чтобы каждое из таких состояний было иммутабельным, т.е. не "одно и то же с измененными филдами" а "два разных отличающихся филдами"
Я опирался на статью https://proandroiddev.com/taming-state-in-android-with-elm-architecture-and-kotlin-part-2-c709f75f7596
Там состояние это класс который копируется с изменением полей как раз
Там состояние это класс который копируется с изменением полей как раз
AM
Почему нельзя перейти? У меня в примере есть такой переход
Тут уже зависит от конкретного примера. К примеру у меня там нужно было отрисовать прогресс бар поверх уже существующего состояния, я композицией это реализовал, думаю так же и с общим состоянием можно поступить
Тут уже зависит от конкретного примера. К примеру у меня там нужно было отрисовать прогресс бар поверх уже существующего состояния, я композицией это реализовал, думаю так же и с общим состоянием можно поступить
А зачем себе жизнь усложнять? Проще жить себе с одним дата-классом на компонент, чем чёт к этому стейту ещё композировать.
Д
Я опирался на статью https://proandroiddev.com/taming-state-in-android-with-elm-architecture-and-kotlin-part-2-c709f75f7596
Там состояние это класс который копируется с изменением полей как раз
Там состояние это класс который копируется с изменением полей как раз
Но почему то увидел слово state и по привычке начал хуярить иерархию классов