C
интересн был бы пример какой-нибудь про гонку состояний
Size: a a a
2020 June 22
C
вроде как кто последний обьновил состояние то и валидно
AO
MVI это конечная как бы архитектура наиболее "правильная"?
нет правильных архитектур, примите это
MM
Ну и кода там зачастую побольше. Но ещё из преимуществ: нет гонки состоянии. В других паттернах бывает что из разных мест меняется стейт, в результате он становится неконсистентным.
Пару раз в текущем проекте (MVP) получалась такое :)
MM
К примеру: есть карта, которая должна отображать какие-то точки в зависимости от положения. Появилась потребность показывать точки, если пользователь переместить карту, но при этом нужно было ограничить по зуму. После этого появилась потребность скрывать точки в зависимости от зума и иногда получалось ситуация, что пользователь отдалил и точки у него сначала исчезали, а потом появлялись (:
CC
Доброго времени суток.
Есть вопрос на целесоозность а точнее насколько это вредно или нет
есть интерфейс с переменными и объектами (Котлин) пльюс компаньон который имеет одну функцию и возвращает другой интерфейс который помогает реализовать это интерфейс . Заранее спасибо
Есть вопрос на целесоозность а точнее насколько это вредно или нет
есть интерфейс с переменными и объектами (Котлин) пльюс компаньон который имеет одну функцию и возвращает другой интерфейс который помогает реализовать это интерфейс . Заранее спасибо
КР
А ещё есть один плюс, но он, по сути, присущ именно используемому мной подходу и библиотеке. Я сижу на tea oolong (правда на форке, где я переделал ядро). В tea есть такая штука как view, это функция, которая маппит Model на Props (то что непосредственно надо отрисовать экрану). И вычисление всей этой информации идёт на бекграунд треде, в render поступает готовые набор данных, который надо отрендерить, и никак не надо интерпретировать.
АЕ
Constantine Cerberus
Доброго времени суток.
Есть вопрос на целесоозность а точнее насколько это вредно или нет
есть интерфейс с переменными и объектами (Котлин) пльюс компаньон который имеет одну функцию и возвращает другой интерфейс который помогает реализовать это интерфейс . Заранее спасибо
Есть вопрос на целесоозность а точнее насколько это вредно или нет
есть интерфейс с переменными и объектами (Котлин) пльюс компаньон который имеет одну функцию и возвращает другой интерфейс который помогает реализовать это интерфейс . Заранее спасибо
ничего непонятно, код может покажете?
CC
ничего непонятно, код может покажете?
Сек ща организуем
CC
ничего непонятно, код может покажете?
Interface a{
val name
val last name
Object{
MODE =1
}
companion object{
fun Creator(): interface Z{
Return impl of Z interface
}
}
Примерно так.
val name
val last name
Object{
MODE =1
}
companion object{
fun Creator(): interface Z{
Return impl of Z interface
}
}
Примерно так.
АЕ
странновато фабрику иметь прямо в интерфейсе, но вполне законно. И вопрос чуток мимо, это скорее в котлин-чатик.
CC
странновато фабрику иметь прямо в интерфейсе, но вполне законно. И вопрос чуток мимо, это скорее в котлин-чатик.
То что странно согласен поэтому и спросил насколько это законно именно в плане архитектурного подхода . Спасибо осталось только найти чатик с котлином 😂
АЕ
Constantine Cerberus
То что странно согласен поэтому и спросил насколько это законно именно в плане архитектурного подхода . Спасибо осталось только найти чатик с котлином 😂
(
мозг в трубочку свернётся) Слишком много концепций должно уже быть устаканено в голове.
чего?
(
каких концепций? Что такое класс и функция?
СГ
А ещё есть один плюс, но он, по сути, присущ именно используемому мной подходу и библиотеке. Я сижу на tea oolong (правда на форке, где я переделал ядро). В tea есть такая штука как view, это функция, которая маппит Model на Props (то что непосредственно надо отрисовать экрану). И вычисление всей этой информации идёт на бекграунд треде, в render поступает готовые набор данных, который надо отрендерить, и никак не надо интерпретировать.
Почему ядро переписал?
AD
А ещё есть один плюс, но он, по сути, присущ именно используемому мной подходу и библиотеке. Я сижу на tea oolong (правда на форке, где я переделал ядро). В tea есть такая штука как view, это функция, которая маппит Model на Props (то что непосредственно надо отрисовать экрану). И вычисление всей этой информации идёт на бекграунд треде, в render поступает готовые набор данных, который надо отрендерить, и никак не надо интерпретировать.
да вроде в любой библиотеке можно или любой реализации можно такое придумать (кажется, у меня тоже так, осталось лишь на корутины переехать)
КР
Почему ядро переписал?
1. Init без учёта предыдущей модели
2. Асинхронный рендеринг - пропсы будут меняться местами иногда
3. Диспатч функция только в рендере (вообще дичь, а не решение)
4. Рендер - функция, а не флоу
5. Диспатч функция внутри кора также асинхронная. Если разработчик писал нагрузочные тесты, то должен был увидеть, что стейт может быть в итоге невалидным.
2. Асинхронный рендеринг - пропсы будут меняться местами иногда
3. Диспатч функция только в рендере (вообще дичь, а не решение)
4. Рендер - функция, а не флоу
5. Диспатч функция внутри кора также асинхронная. Если разработчик писал нагрузочные тесты, то должен был увидеть, что стейт может быть в итоге невалидным.
КР
Из хорошего в этой библиотеке - тайпалиасы и документация.)