Понятно. Просто как будто бы контролировать очередность событий не то, чтобы частый кейс для большинства приложений. Тип, если это нужно в одном экране из ста — ничего страшного, можно и через блок. Возможно, специфика проектов в Яндексе говорит об обратной статистике)
В BLoC есть Cubits, которые не так многословны как сами блоки. Пока не очень понятно, в чем преимущество данной библиотеки перед кубитами. Те же стратегии есть в bloc_concurrency
Накидал код для прототипа GUI инструмента Табличка выглядит так. TreeDataGrid отлично подошел с учетом иерархичной структуры файлов локалей. Осталось дело за малым - превратить это в удобный инструмент.
GUI инструмента пока нет, но думаю могу этим заняться. По идее одну табличку в той же авалонии сделать - много времени не займет. В планах еще было - добавить пару команд в CLI. Одну для анализа на валидность json'ов со строками (такая уже есть в оригинальной библиотеке). И вторую - для миграции .resx файлов в json.
Насчет XAML я думал над каким-нибудь решением, чтобы уменьшить число бойлерплейта, но пока нет хороших идей)
Мы у нас в проектах не смешиваем freezed с json. Для data - слоя используются json модельки, для domain-слоя - freezed. Думал, это общепринятая практика (clean architecture).
Мы у себя на проекте используем yandex_mapkit. Пока на офф пакет от яндекса не перешли, тк еще бета - есть краши на симе iOS. Работы по миграции лежат в отдельной ветке - ждем выхода стабильной версии
Просто создавать из кода разметку недостаточно, чтобы это стало декларативным UI как во Flutter. Тут нужен совершенно другой подход к рендерингу, и возможно даже к самой платформе .NET. Например, сборщик мусора, оптимизированный под декларативный подход к UI. С такой проблемой, к примеру, столкнулись разработчики Jetpack Compose, сделав новый GC под их нужды, чтобы не было подвисаний и тормозов.
У меня нет хейта к MAUI и microsoft. Я считаю просто, что на MAUI будет минимум production проектов на рынке, технология останется нишевой. Если бы MAUI поддерживал декларативный подход к построению UI, я бы по другому оценил шансы того, что технология не умрет.
Да, действительно, есть еще ReactiveUI - возможно, используя этот фреймворк, было бы меньше проблем, связанных с MvvmCross. Насчет дженериков - была проблема, что иногда приложение просто крашилось с java исключением на уровне связывания .net View с java View. Я уже точно не помню какое именно исключение, загуглить тоже не получается, но проблема точно была. Возможно, это касалось только Activity.
Прошло более полугода с момента закрытия проекта на замарине и уже все напрочь забыл))
Небольшой дисклеймер: употребляя ниже термин «декларативный UI», я имею в виду исключительно подходы Compose, Flutter и SwiftUI к построению интерфейса.
Все три работают примерно так - в виде кода описывается иерархия из виджетов(контролов), и эта иерархия из виджетов меняется при смене состояния. Это если грубо-говоря. HTML c биндингами в моем понимании - это не «декларативный UI».
У меня возникло несколько вопросов: - генерация кода, за счет чего она работает? Это Incremental Source Generator в основе или что-то другое? - я для своих проектов, использую Jab для DI. Знакомы ли Вы с этой библиотекой? В чем принципиальные различия с Pure.Di? Какие преимущества и недостатки есть в сравнении? Почему мне стоит попробовать Pure.Di, если я пользователь Jab к примеру?)
Интересно почему WPF, а не Avalonia?) Мне кажется Avalonia намного более предпочтительна в 2024 году, особенно, если нет потребности использовать какие-нибудь телерик и devExpress.
Понятно. Просто как будто бы контролировать очередность событий не то, чтобы частый кейс для большинства приложений. Тип, если это нужно в одном экране из ста — ничего страшного, можно и через блок. Возможно, специфика проектов в Яндексе говорит об обратной статистике)
В BLoC есть Cubits, которые не так многословны как сами блоки. Пока не очень понятно, в чем преимущество данной библиотеки перед кубитами. Те же стратегии есть в bloc_concurrency
Накидал код для прототипа GUI инструмента
Табличка выглядит так. TreeDataGrid отлично подошел с учетом иерархичной структуры файлов локалей. Осталось дело за малым - превратить это в удобный инструмент.
для "21 яблока" будет использоваться вариант "one".
Под капотом используются следующие правила для склонений под различные культуры.
GUI инструмента пока нет, но думаю могу этим заняться. По идее одну табличку в той же авалонии сделать - много времени не займет.
В планах еще было - добавить пару команд в CLI. Одну для анализа на валидность json'ов со строками (такая уже есть в оригинальной библиотеке). И вторую - для миграции .resx файлов в json.
Насчет XAML я думал над каким-нибудь решением, чтобы уменьшить число бойлерплейта, но пока нет хороших идей)
В итоге настолько проникся удобством slang, что сделал порт библиотеки на .NET, чтобы не страдать при разработке десктопа и переводить через GPT
«Удалено автором»
Мы у нас в проектах не смешиваем freezed с json. Для data - слоя используются json модельки, для domain-слоя - freezed. Думал, это общепринятая практика (clean architecture).
Мы у себя на проекте используем yandex_mapkit. Пока на офф пакет от яндекса не перешли, тк еще бета - есть краши на симе iOS. Работы по миграции лежат в отдельной ветке - ждем выхода стабильной версии
Скорее не считая
dynamic.varкак иfinalвроде никак не намекает на то, что язык может быть не строго типизированный)Просто создавать из кода разметку недостаточно, чтобы это стало декларативным UI как во Flutter. Тут нужен совершенно другой подход к рендерингу, и возможно даже к самой платформе .NET. Например, сборщик мусора, оптимизированный под декларативный подход к UI. С такой проблемой, к примеру, столкнулись разработчики Jetpack Compose, сделав новый GC под их нужды, чтобы не было подвисаний и тормозов.
У меня нет хейта к MAUI и microsoft. Я считаю просто, что на MAUI будет минимум production проектов на рынке, технология останется нишевой. Если бы MAUI поддерживал декларативный подход к построению UI, я бы по другому оценил шансы того, что технология не умрет.
Ответ в статье от моего коллеги - то из чего выбирали и почему выбрали flutter)
Да, действительно, есть еще ReactiveUI - возможно, используя этот фреймворк, было бы меньше проблем, связанных с MvvmCross.
Насчет дженериков - была проблема, что иногда приложение просто крашилось с java исключением на уровне связывания .net View с java View. Я уже точно не помню какое именно исключение, загуглить тоже не получается, но проблема точно была. Возможно, это касалось только Activity.
Прошло более полугода с момента закрытия проекта на замарине и уже все напрочь забыл))
Все три работают примерно так - в виде кода описывается иерархия из виджетов(контролов), и эта иерархия из виджетов меняется при смене состояния. Это если грубо-говоря. HTML c биндингами в моем понимании - это не «декларативный UI».
Не знаю - в этом плане для десктопа я считаю AvaloniaUI лучшим фреймворком на данный момент.
Да) очень ждем их появления в релизе) А самое главное библиотек, которые будут с ними работать
Спасибо большое за развернутый ответ)
Почти продали Pure.Di - обязательно найду время изучить сэмплы и попробую внедрить в своих проектах.
У меня возникло несколько вопросов:
- генерация кода, за счет чего она работает? Это Incremental Source Generator в основе или что-то другое?
- я для своих проектов, использую Jab для DI. Знакомы ли Вы с этой библиотекой? В чем принципиальные различия с Pure.Di? Какие преимущества и недостатки есть в сравнении? Почему мне стоит попробовать Pure.Di, если я пользователь Jab к примеру?)
Интересно почему WPF, а не Avalonia?) Мне кажется Avalonia намного более предпочтительна в 2024 году, особенно, если нет потребности использовать какие-нибудь телерик и devExpress.