Интересно почему WPF, а не Avalonia?) Мне кажется Avalonia намного более предпочтительна в 2024 году, особенно, если нет потребности использовать какие-нибудь телерик и devExpress.
А почему рекомендуете go_router? Можете поделиться, чем auto_route хуже, какие кейсы не покрывает в ваших проектах или с какими проблемами столкнулись. Мы недавно в компании перешли на Flutter с Xamarin Native, и пока сделали выбор в пользу auto_route.
А если в приложении 100+ экранов и при навигации на все (кроме парочки, касающихся авторизации) нужна проверка через AuthGuard, нужно вручную для всех ста роутов прописывать параметр guards? Или есть какой-то способ задания AuthGuard без ручного прокидывания в каждый роут?
DevExpress и Telerik - это поставщики контролов под разные UI либы - WPF, MAUI, Blazor и пр.) Уверен и под AvaloniaUI появятся, когда Avalonia станет самой популярной UI либой под С# для десктопа
Спасибо большое за статью. Неделю назад тоже озаботился написанием генератора для рабочего проекта. Столкнулся с тем, что прекрасно работает на простом проекте, на рабочем же просто уходил в загрузку и ничего не происходило) Так же переписал на инкрементальный генератор и результат получился таким же. Жду с нетерпением новой части, хотя и в этой узнал много новых нюансов, с которыми буду экспериментировать в своем генераторе.
Почему бы не сделать пару виртуальных методов: "Task ExecuteIterationAsync(CancellationToken ct)" и "void ExecuteIteration(CancellationToken ct)", чтобы исключить все эти ограничения на то, как должен быть определён метод???
Походу это тоже работает) По крайней мере, сейчас попробовал убрать "namespace MyApp;" в файле класса - всё собралось нормально с глобальным неймспейсом проекта.
Это при создании нового проекта в окошке выбора только net6. Потом, можно в свойствах проекта таргетнуться куда угодно. Конечно, не придется держать 2019, 2022 всё также будет поддерживать.
ViewLocator нам в этот раз не пригодится, так как он используется для создания кастомных контролов.
Правильнее, наверное, сказать «пользовательских контролов», а не «кастомных». По крайней мере, если использовать терминологию WPF.
И ещё… В Avalonia строки и столбцы сетки можно указывать куда проще:
Например,
Тяжело будет портировать в любом случае) Хотя бы из-за отсутствия различных библиотек контролов и приколюх, которые есть для WPF. А к другой организации стилей привыкаешь буквально за пару-тройку дней. Мне вот нравится синтаксис байндингов, когда вместо {Binding Path=Property, RelativeSource{RelativeSource Self}},
пишешь что-то в духе {Binding $self.Property}
Интересно почему WPF, а не Avalonia?) Мне кажется Avalonia намного более предпочтительна в 2024 году, особенно, если нет потребности использовать какие-нибудь телерик и devExpress.
Ссылки все про generic math или я что-то упустил?
Я же имел ввиду Descriminated Unions.
Лучше бы в С# добавили алгебраические типы данных))
А почему рекомендуете go_router? Можете поделиться, чем auto_route хуже, какие кейсы не покрывает в ваших проектах или с какими проблемами столкнулись. Мы недавно в компании перешли на Flutter с Xamarin Native, и пока сделали выбор в пользу auto_route.
Нашёл в доке, как сделать глобальную обработку
А если в приложении 100+ экранов и при навигации на все (кроме парочки, касающихся авторизации) нужна проверка через AuthGuard, нужно вручную для всех ста роутов прописывать параметр guards? Или есть какой-то способ задания AuthGuard без ручного прокидывания в каждый роут?
Правильно я понял, что sealed class'ы - это по сути discriminated unions из F#, которые уже сколько лет мы ждем, когда они наконец-то заедут в C#?
DevExpress и Telerik - это поставщики контролов под разные UI либы - WPF, MAUI, Blazor и пр.) Уверен и под AvaloniaUI появятся, когда Avalonia станет самой популярной UI либой под С# для десктопа
Спасибо большое за статью. Неделю назад тоже озаботился написанием генератора для рабочего проекта. Столкнулся с тем, что прекрасно работает на простом проекте, на рабочем же просто уходил в загрузку и ничего не происходило) Так же переписал на инкрементальный генератор и результат получился таким же. Жду с нетерпением новой части, хотя и в этой узнал много новых нюансов, с которыми буду экспериментировать в своем генераторе.
Вот, сделал пример стиля, который делает всё тоже самое.
Можно было взять обычный ToggleButton и всё это реализовать в стиле в XAML.
Почему бы не сделать пару виртуальных методов:
"Task ExecuteIterationAsync(CancellationToken ct)" и
"void ExecuteIteration(CancellationToken ct)",
чтобы исключить все эти ограничения на то, как должен быть определён метод???
PS: Всё понял... тогда DI в методе не сделать
Походу это тоже работает) По крайней мере, сейчас попробовал убрать "namespace MyApp;" в файле класса - всё собралось нормально с глобальным неймспейсом проекта.
Правильнее, наверное, сказать «пользовательских контролов», а не «кастомных». По крайней мере, если использовать терминологию WPF.
И ещё… В Avalonia строки и столбцы сетки можно указывать куда проще:
Например,
пишешь что-то в духе {Binding $self.Property}