VN
/cat@relaxcats_bot
Size: a a a
2020 September 14
V
/cat@relaxcats_bot
ML
d
У анклбоба пригорело http://blog.cleancoder.com/uncle-bob/2020/09/12/TheDisinvitation.html
А какие у него политические убеждения?
AM
В допотопном MVC есть стейт вьюхи, от которого UI был бы функцией? Не припомню такого.
AM
Переслано от Кирилл Романенко...
А в чём он ошибся? Даже в допотопном mvc это утверждение верно.
КР
В допотопном MVC есть стейт вьюхи, от которого UI был бы функцией? Не припомню такого.
Не обязательно воспринимать буквально.) f() и State не обязательно должны быть чистой функцией и одним классом.
AM
Не обязательно воспринимать буквально.) f() и State не обязательно должны быть чистой функцией и одним классом.
Дык ну если единого стейта нет, буквально воспринимай, не буквально, а единой зависимости нет.
КР
Помогице. :( https://t.me/gradle/5996
Я вообще не уверен, возможно ли то, чего я пытаюсь добиться...
Я вообще не уверен, возможно ли то, чего я пытаюсь добиться...
AM
В MVP обычно экран тюнится вызовами экшнов из презентера, в MVVM -- кучей мелких реактивных подстейтов. За отсутствие этой f, которая в вышеприведенной формуле, эти подходы и не любят)
КР
В MVP обычно экран тюнится вызовами экшнов из презентера, в MVVM -- кучей мелких реактивных подстейтов. За отсутствие этой f, которая в вышеприведенной формуле, эти подходы и не любят)
> за отсутствие f
Ну я воспринимаю это не буквально. Скорее, просто как то, что после изменения состояния должно происходить изменение юая. И не важно, достигается это экшенами или реактивными подстейтами.
Ну я воспринимаю это не буквально. Скорее, просто как то, что после изменения состояния должно происходить изменение юая. И не важно, достигается это экшенами или реактивными подстейтами.
AM
> за отсутствие f
Ну я воспринимаю это не буквально. Скорее, просто как то, что после изменения состояния должно происходить изменение юая. И не важно, достигается это экшенами или реактивными подстейтами.
Ну я воспринимаю это не буквально. Скорее, просто как то, что после изменения состояния должно происходить изменение юая. И не важно, достигается это экшенами или реактивными подстейтами.
Ну если растягивать эту формулу настолько, чтобы, к примеру, в той же моксе стейтом называть все приватные свойства, очередь команд, а также все глобальные свойства, которые рукожопый разработчик зацепил ненароком -- то можно, конечно, и так судить. Но это сова на глобусе, как по мне)
КР
Ну если растягивать эту формулу настолько, чтобы, к примеру, в той же моксе стейтом называть все приватные свойства, очередь команд, а также все глобальные свойства, которые рукожопый разработчик зацепил ненароком -- то можно, конечно, и так судить. Но это сова на глобусе, как по мне)
Но вообще, по факту Игорь прав. Воспринимая буквально, UI = f(State) это лучшее, что возможно придумать.
Я вот недавно писал музыкальный плеер, у него было размазанное состояние, которое и обновлялось более размазанно. Я написал Игорю, он предложил мне централизовать состояние и его изменения (хотя я мог и сам додуматься, но я был уставший). И, о чудо, ВСЕ мучающие меня баги исчезли.☺️ И я не сделал TEA, я просто собрал в кучу размазанные стейт и логику.
Я вот недавно писал музыкальный плеер, у него было размазанное состояние, которое и обновлялось более размазанно. Я написал Игорю, он предложил мне централизовать состояние и его изменения (хотя я мог и сам додуматься, но я был уставший). И, о чудо, ВСЕ мучающие меня баги исчезли.☺️ И я не сделал TEA, я просто собрал в кучу размазанные стейт и логику.
I
И как же хорошо все таки в UI, все четко и понятно.
Я вот последние время пишу ботов и сервисы и там НИ-ХРЕНА не понятно, как правильно делать UDF
Я вот последние время пишу ботов и сервисы и там НИ-ХРЕНА не понятно, как правильно делать UDF
I
Понял пока только одно - надо покрывать e2e тестами с самого начало.
Что бы потом архитектуру по 100 раз переписывать.
Ну и еще бить все на маленькие модули, что бы независимо по 100 раз их переписывать.
Что бы потом архитектуру по 100 раз переписывать.
Ну и еще бить все на маленькие модули, что бы независимо по 100 раз их переписывать.
КР
Понял пока только одно - надо покрывать e2e тестами с самого начало.
Что бы потом архитектуру по 100 раз переписывать.
Ну и еще бить все на маленькие модули, что бы независимо по 100 раз их переписывать.
Что бы потом архитектуру по 100 раз переписывать.
Ну и еще бить все на маленькие модули, что бы независимо по 100 раз их переписывать.
Хм
Мб, дробить на компоненты, которые будут общаться друг с другом с помощью Msg и каждый будет содержать свой стейт?
Мб, дробить на компоненты, которые будут общаться друг с другом с помощью Msg и каждый будет содержать свой стейт?
I
Ну в одно приложении +- так сделал.
Там модули "общались" через event-bus, он же сериализовался в монгу для сохранения состояни.
Плюсы
- вся логика в коде (нет sql / индексов и тп)
Минусы
- сложно правильно спроектировать события
===
Там модули "общались" через event-bus, он же сериализовался в монгу для сохранения состояни.
Плюсы
- вся логика в коде (нет sql / индексов и тп)
Минусы
- сложно правильно спроектировать события
===