DE
тебя не заботит их состояние
Size: a a a
2020 February 14
(
Так в этом и прелесть, у каждого компонента своё внутреннее состояние, а может и несколько. Всё общение с компонентами только через вход/выход. Приведите пример гонок.
Экран, на котором есть поле ввода, открывающаяся клавиатура
Одна фича контролит это поле, а вторая контролит какой-нибудь диалог, который время от времени вылезает на экране, и ему нужно закрывать клавиатуру если отображается этот диалог, но он не может, потому что у него нет (не должно быть) доступа к клавиатуре
Одна фича контролит это поле, а вторая контролит какой-нибудь диалог, который время от времени вылезает на экране, и ему нужно закрывать клавиатуру если отображается этот диалог, но он не может, потому что у него нет (не должно быть) доступа к клавиатуре
SB
Так в этом и прелесть, у каждого компонента своё внутреннее состояние, а может и несколько. Всё общение с компонентами только через вход/выход. Приведите пример гонок.
Может быть такое что фичи связаны друг с другом. Передавать друг другу инфу. Тогда может быть гонка
SB
прикол в том, что у тебя фичи полностью обособленные
Если так всегда ок
IM
Как быть с тем что допустим фич очень много, значит стейтов очень много. И нельзя увидеть всю картину, нет единой точки входа, стейта. Появляется гонка состояний итд
Андроид приложение(в отличии от консольного к примеру) не имеет определенной точки входа.
Да, условно можно считать Application, но это не так.
Приложение представляет собой набор относительно автономных блоков. И проектировать его как цельное - изначально неверно. Стоит попробовать дружить с андроидом, вместо того, чтобы насиловать его.
Да, условно можно считать Application, но это не так.
Приложение представляет собой набор относительно автономных блоков. И проектировать его как цельное - изначально неверно. Стоит попробовать дружить с андроидом, вместо того, чтобы насиловать его.
IM
Экран, на котором есть поле ввода, открывающаяся клавиатура
Одна фича контролит это поле, а вторая контролит какой-нибудь диалог, который время от времени вылезает на экране, и ему нужно закрывать клавиатуру если отображается этот диалог, но он не может, потому что у него нет (не должно быть) доступа к клавиатуре
Одна фича контролит это поле, а вторая контролит какой-нибудь диалог, который время от времени вылезает на экране, и ему нужно закрывать клавиатуру если отображается этот диалог, но он не может, потому что у него нет (не должно быть) доступа к клавиатуре
Почитайте, что такое компонент в андроид и какие они бывают)
SB
Но допустим есть изменение функционала и фичи которые были не связаны становятся связанными, или их надо обьединять в одну фичу
(
Ihor Martyniuk
Почитайте, что такое компонент в андроид и какие они бывают)
Не разговаривайте со мной пожалуйста
IM
Не разговаривайте со мной пожалуйста
ой, простите 😁
(
Имхо, декомпозировать фичи конечно надо, но ещё надо иметь возможность их перекомпозировать, сливая в одну большую фичу на уровне типов
(
что-то вроде
f1 = Feature<M1, S1>, f2 = Feature<M2, S2>, gf: Feature<Either<M1, M2>, Either<S1, S2>> = f1 + f2AI
Экран, на котором есть поле ввода, открывающаяся клавиатура
Одна фича контролит это поле, а вторая контролит какой-нибудь диалог, который время от времени вылезает на экране, и ему нужно закрывать клавиатуру если отображается этот диалог, но он не может, потому что у него нет (не должно быть) доступа к клавиатуре
Одна фича контролит это поле, а вторая контролит какой-нибудь диалог, который время от времени вылезает на экране, и ему нужно закрывать клавиатуру если отображается этот диалог, но он не может, потому что у него нет (не должно быть) доступа к клавиатуре
Как вариант, этот компонент с диалогом может выдать команду наверх, что он показал диалог. Дальше кто-то общий сверху отправит команду закрыть_клаву вниз компоненту с полем ввода
DE
Ihor Martyniuk
Почитайте, что такое компонент в андроид и какие они бывают)
немного странный комментарий сообщения
AI
В результате есть возможность переиспользовать компоненты и чётко видно что им надо как с ними работать
(
Как вариант, этот компонент с диалогом может выдать команду наверх, что он показал диалог. Дальше кто-то общий сверху отправит команду закрыть_клаву вниз компоненту с полем ввода
ну вот, да. Тогда задача сводится к тому, чтобы сделать абстрактный композитор фич, который сам эмиттит фичи и в который можно запихивать ещё дополнительно предобработку ивентов
AI
ну вот, да. Тогда задача сводится к тому, чтобы сделать абстрактный композитор фич, который сам эмиттит фичи и в который можно запихивать ещё дополнительно предобработку ивентов
Эмитит фичи?
AI
Можно на фрагментах сделать
DE
что-то вроде
f1 = Feature<M1, S1>, f2 = Feature<M2, S2>, gf: Feature<Either<M1, M2>, Either<S1, S2>> = f1 + f2вот за это плюс. Тогда все приложение можно удобнее описать, как набор фич: application = f1 + f2 + f3 + f4 + ....
IM
Как вариант, этот компонент с диалогом может выдать команду наверх, что он показал диалог. Дальше кто-то общий сверху отправит команду закрыть_клаву вниз компоненту с полем ввода
под компонентом вы что подразумеваете? Если компонент == компонент - тогда диалог по факту существует в скоупе активности, как компонента и сам пример изначально глуп.
Если компонент - это некий абстрактный модуль в вакууме - тогда уточните , что он из себя представляет.
Если компонент - это некий абстрактный модуль в вакууме - тогда уточните , что он из себя представляет.
AI
Ihor Martyniuk
под компонентом вы что подразумеваете? Если компонент == компонент - тогда диалог по факту существует в скоупе активности, как компонента и сам пример изначально глуп.
Если компонент - это некий абстрактный модуль в вакууме - тогда уточните , что он из себя представляет.
Если компонент - это некий абстрактный модуль в вакууме - тогда уточните , что он из себя представляет.
Компонент - это некий интерфейс с реализацией