K
не знаю, я xaml больше люблю, чем html+css, у меня от "пиксел перфект верстки" жопа сгорала на флексах
+
Size: a a a
2020 July 07
K
мне кажется для xaml-а нет норм инструмента рендеринга (первью) например
Есть такое, да
K
Но проблема в дизайнере, а не XAML. Не факт, что шарповый код оно будет хорошо рендерить.
I
Скажем, банальная кнопка
https://i.gyazo.com/1d23f9f257065dce1e24220cc20f3782.png
Ну смотри та же кнопка уже композируемый элемент.
Неплохой пример в Google Jetpack Compose
И каждый из них точно такой же независимый компонент.
Ну смотри та же кнопка уже композируемый элемент.
Неплохой пример в Google Jetpack Compose
Surface > Box > ProvideTextStyleИ каждый из них точно такой же независимый компонент.
K
https://i.gyazo.com/1d23f9f257065dce1e24220cc20f3782.png
Ну смотри та же кнопка уже композируемый элемент.
Неплохой пример в Google Jetpack Compose
И каждый из них точно такой же независимый компонент.
Ну смотри та же кнопка уже композируемый элемент.
Неплохой пример в Google Jetpack Compose
Surface > Box > ProvideTextStyleИ каждый из них точно такой же независимый компонент.
Вижу, но что я должен тут оценить?
Краткость кода? Или то, что оно в одном файле с код бихайндом?
Краткость кода? Или то, что оно в одном файле с код бихайндом?
S
Если сложность не в самом XML, а в разных XAML составляющих типа StateTrigger, Binding и т.д., то в едином языке все эти конструкции ведь тоже нужны будут. Возможно в другом виде. И их надо будет учить.
ну вот к стати, я топлю за авалония стили , т.е css подобные.
оставить параметры , которые характерны xaml, но задавать через селекторы куда круче выглядит, эдакий микс подход.
сами visualtrigger/statetrigger etc не сложно понять (как по мне), но часто приходиться ради простого ховера, тянуть простыню говна)
оставить параметры , которые характерны xaml, но задавать через селекторы куда круче выглядит, эдакий микс подход.
сами visualtrigger/statetrigger etc не сложно понять (как по мне), но часто приходиться ради простого ховера, тянуть простыню говна)
I
Вижу, но что я должен тут оценить?
Краткость кода? Или то, что оно в одном файле с код бихайндом?
Краткость кода? Или то, что оно в одном файле с код бихайндом?
Их можно использовать по отдельности, а можно собрать в кнопку.
И поведение всегда будет одинаковое, тк они зависят только от параметров (и есть мемозиция для оптимизации).
И поведение всегда будет одинаковое, тк они зависят только от параметров (и есть мемозиция для оптимизации).
I
А из кнопок можно собрать tab-bar, а его вложить в page, а page в stack-history-application
Композиция одним словом.
Композиция одним словом.
K
ну вот к стати, я топлю за авалония стили , т.е css подобные.
оставить параметры , которые характерны xaml, но задавать через селекторы куда круче выглядит, эдакий микс подход.
сами visualtrigger/statetrigger etc не сложно понять (как по мне), но часто приходиться ради простого ховера, тянуть простыню говна)
оставить параметры , которые характерны xaml, но задавать через селекторы куда круче выглядит, эдакий микс подход.
сами visualtrigger/statetrigger etc не сложно понять (как по мне), но часто приходиться ради простого ховера, тянуть простыню говна)
Да, потому тоже присел на авалонию сейчас.
Но и у нее с этим проблема, на одних селекторах все не вытащить. И так же приходится тянуть простыню говна, только вместо State у тебя уже Pseudoclass.
Но и у нее с этим проблема, на одних селекторах все не вытащить. И так же приходится тянуть простыню говна, только вместо State у тебя уже Pseudoclass.
S
Да, потому тоже присел на авалонию сейчас.
Но и у нее с этим проблема, на одних селекторах все не вытащить. И так же приходится тянуть простыню говна, только вместо State у тебя уже Pseudoclass.
Но и у нее с этим проблема, на одних селекторах все не вытащить. И так же приходится тянуть простыню говна, только вместо State у тебя уже Pseudoclass.
В каком случае пришлось тащить, если не секрет ?
K
В каком случае пришлось тащить, если не секрет ?
Когда создаешь контрол с особым состоянием, который не можешь определить в селекторе через доступные свойства.
I
https://i.gyazo.com/1d23f9f257065dce1e24220cc20f3782.png
Ну смотри та же кнопка уже композируемый элемент.
Неплохой пример в Google Jetpack Compose
И каждый из них точно такой же независимый компонент.
Ну смотри та же кнопка уже композируемый элемент.
Неплохой пример в Google Jetpack Compose
Surface > Box > ProvideTextStyleИ каждый из них точно такой же независимый компонент.
И опять так для работы с этим достаточно редактора кода.
Тот же Xaml требует отдельной поддержки в IDE и до недавнего времени тупо не работал в Rider.
И скорее всего до сих пор в VSCode.
Тот же Xaml требует отдельной поддержки в IDE и до недавнего времени тупо не работал в Rider.
И скорее всего до сих пор в VSCode.
S
Когда создаешь контрол с особым состоянием, который не можешь определить в селекторе через доступные свойства.
Понял
K
Их можно использовать по отдельности, а можно собрать в кнопку.
И поведение всегда будет одинаковое, тк они зависят только от параметров (и есть мемозиция для оптимизации).
И поведение всегда будет одинаковое, тк они зависят только от параметров (и есть мемозиция для оптимизации).
Скажем, вот типичный шаблон кнопки в XAML фреймфорке.
<Button>
<Button.Template>
<Border>
<ContentPresenter/>
</>
</>
</>
K
Где ContentPresenter - атомарный контрол, который просто рендерит тот контент, который в него положили.
Border - атомарный контрол для бекграунда, рамки, округлых углов.
Button - состоит из первых двух + события на Click и прочее кнопко-специфичное.
Border - атомарный контрол для бекграунда, рамки, округлых углов.
Button - состоит из первых двух + события на Click и прочее кнопко-специфичное.
K
И из таких кнопок можно так же собрать tab-bar
K
А лучше через ItemsRepeater или аналог, с которым тебе не надо будет напрямую модифицировать список Children контейнера этого tab-bar
K
И опять так для работы с этим достаточно редактора кода.
Тот же Xaml требует отдельной поддержки в IDE и до недавнего времени тупо не работал в Rider.
И скорее всего до сих пор в VSCode.
Тот же Xaml требует отдельной поддержки в IDE и до недавнего времени тупо не работал в Rider.
И скорее всего до сих пор в VSCode.
Это да. Не везде хорошо бывает.
K
Но если в VS с XAML особо проблем нет в поддержке редактора, то превьювер проблемный в принципе (и C#/F# верстка не спасет).
I
По этому в Flutter / React-Native и есть live-reload
Которые при этом состояние не сбрасывает, а когда это у тебя декларативный UI это гораздо проще, тк стейт в одном месте, а не размазан по графу виджетов.
Которые при этом состояние не сбрасывает, а когда это у тебя декларативный UI это гораздо проще, тк стейт в одном месте, а не размазан по графу виджетов.