Потому что на практике тебе компилятор будет мешать писать код, который не упадёт. Вот ты написал match x with | True -> x | False -> y | _ -> z А компилятор тебе и говорит, что ты лох, и третья ветка не нужна. Хотя она нужна, если в DU добавят ещё одно значение.

На самом деле не нужна. Новая ветка в du - ломающее изменение

На самом деле не нужна. Новая ветка в du - ломающее изменение

Кто это говорит?

Кто это говорит?

Внутренний голос ;)

Лучше ему так не говорить!

Лучше ему так не говорить!

Это еще почему?

Потому что у ООПшников, например, новый класс в иерархии наследования — обычно не ломающее изменение.

Получается, ООП-архитектура лучше масштабируется? ?

Я насмотрелся примеров калькулятора и тп в репозитории Сайма. Но там во всех примерах обновление гуя происходит на юзер экшн. И инфраструктура на это сильно завязана, на первый взгляд по крайней мере. У меня же модель другая - в один из акторов нужно передать функцию, которая перерисует гуй или затриггерит этот процесс. А юзер экшны складываются в мейлбокс и по таймеру процессятся

Ну, тебе не нужен Elmish.

Потому что у ООПшников, например, новый класс в иерархии наследования — обычно не ломающее изменение.

Наследник в ООП - открытая альтернатива, DU - закрытая. Выбирай то, что подходит под твою задачу

Ну, на самом деле тоже верно.

Привет.

Ну, тебе не нужен Elmish.

Почему? Что почитать можно на этот счет?

Почему? Что почитать можно на этот счет?

Потому что Elmish форсирует определенную архитектуру, а у тебя другая. Зачем тебе Elmish?

Я не знаю. Я и про элмиш толком ничего не знаю, выбрал его, потому что это было единственное известное мне пересечение F# & Xamarin

?

ну, в разработке UI у меня опыта примерно 0. Поэтому выбор мог быть дурацкий)

Ну, с акторами для UI тебе лучше к @vshapenko обратиться.

Я насмотрелся примеров калькулятора и тп в репозитории Сайма. Но там во всех примерах обновление гуя происходит на юзер экшн. И инфраструктура на это сильно завязана, на первый взгляд по крайней мере. У меня же модель другая - в один из акторов нужно передать функцию, которая перерисует гуй или затриггерит этот процесс. А юзер экшны складываются в мейлбокс и по таймеру процессятся

Я не знаю как там в xamarin но в обычном elmish для этого есть subscription

Как только начнутся темплейты,elmish может сказать "ой, всё"

Там eDSL для динамических вьюх.

Как только начнутся темплейты,elmish может сказать "ой, всё"

Или темплейты или elmish. Кому что ближе.

Шаблон в Elmish -- это просто функция. :)

Ну речь про xaml я так понимаю. Elmish не для тех, кому нравится xaml :)

Лично я для себя понял, что разделение представления и юайной логики а затем их связывание - это дополнительная сложность. Но некоторым такое по душе

С другой стороны можно было бы и с XAML использовать -- только нужны динамически обновляемые биндинги.

У Elmish.WPF они статические, это прибавляет неудобства при работе с шаблонами.

С другой стороны можно было бы и с XAML использовать -- только нужны динамически обновляемые биндинги.

Что ты имеешь в виду под динамическими биндингами? Неявное связывание модели и xaml?

У Elmish.WPF они статические, это прибавляет неудобства при работе с шаблонами.

Двойная работа. Сначала описываешь xaml , а потом ещё биндинги.

В WPF немного другая концепция. Там все же модель отделена от представления

В WPF немного другая концепция. Там все же модель отделена от представления

В Elmish тоже.

В Elmish тоже.

В методе View в Elmish что возвращается?

Что ты имеешь в виду под динамическими биндингами? Неявное связывание модели и xaml?

В Elmish.WPF биндинги один раз задаются при создании приложения. И уже внутри биндинги описывается некоторая логика, зависящая от модели. Хотелось бы и сами биндинги обновлять. Могу показать позже, с чем я столкнулся.

В методе View в Elmish что возвращается?

Отображение.

Вот

В Elmish.WPF биндинги один раз задаются при создании приложения. И уже внутри биндинги описывается некоторая логика, зависящая от модели. Хотелось бы и сами биндинги обновлять. Могу показать позже, с чем я столкнулся.

А , понял.

А для того же WPF логичнее возвращать не отображение, а как его получить, условно

А для того же WPF логичнее возвращать не отображение, а как его получить, условно

Не для всех это логично)

А , понял.

Лично мне не хватило, кажется, некоторых данных о текущем состоянии модели при маппинге сообщений от внутренних компонентов.

А для того же WPF логичнее возвращать не отображение, а как его получить, условно

Я ничего не понял.

Я ничего не понял.

Я хочу вернуть правило, по которому выберу шаблон

А не само отображение

Я хочу вернуть правило, по которому выберу шаблон

Функция?

Я хочу вернуть правило, по которому выберу шаблон

Зачем?

Одна и та же VM может отображаться по-разному даже в пределах одной страницы

Одна и та же VM может отображаться по-разному даже в пределах одной страницы

Разные функции view.

Для одной и той же модели.

Ок, зайдем с другой стороны

Что я должен вернуть во view? xaml?

Что я должен вернуть во view? xaml?

Что угодно, что поймет твой рендерер.

Ладно, току зрения я понял в целом. КАк уволюсь, изучу вопрос

?

У меня не получился конкретный сценарий просто , когда я пробовал

Все, ушел грабить гробницы

Elmish.WPF стрёмный тем, что возвращает биндинги (half elmish). Для него бы DSL написать нормальный, но это некоторый труд.

Лучше для Avalonia сделать.

Лучше для Avalonia сделать.

Никаких новостей нет? Жду хотя бы беты 2.0

Привет!

Никаких новостей нет? Жду хотя бы беты 2.0

Новости такие, что потихоньку внедряется на разных проектах. Всё чаще проплывает инфа, что авалонию поюзали на том или ином кроссплатформенном проекте.

Во всяком случае, не сказать, что интерес падает.

Во всяком случае, не сказать, что интерес падает.

Это же прекрасно

Да, безусловно.

Авалония ждёт пользователей и контрибьюторов!

Жалко, что у них в ядре нету F#, правда.

Кто бы архитектуру рассказал и в курс дела ввёл

Самому читать с 0 до конца сложновато

Кто бы архитектуру рассказал и в курс дела ввёл

А есть доклады от @kekekeks на тытрубе

Чекну к вечеру

Чекну к вечеру

https://youtu.be/8qzqweimcFs вот, я нашёл

Спасибо!

Ну и у них код достаточно человечный, в нём обычно всё понятно.

(я контрибьютил, знаю о чём говорю)

https://www.linkedin.com/company/fsharp/

Господи, когда же у меня хватит сил на "Монады и отложенные вычисления в дот нет"

Одна и та же VM может отображаться по-разному даже в пределах одной страницы

Вот, кстати в Elm, функция update как раз возвращает ViewModel (логическое представление UI), только без методов/логики

Плюс эльму в карму

Привет!!

https://twitter.com/Neftedollar/status/1041084521419104257?s=19

https://twitter.com/Neftedollar/status/1041084521419104257?s=19

"published" же, вроде, должно быть. Прошу прощения за занудство ?

Привет. Не могу понять почему JsonProvider в коде видит св-ва (Id, Name etc), а в winforms биндинг не работает. Биндится только ToString(в виде {Id:"", Name=""}. Все равно приходится вводить свои типы и мапить на них перед биндингом. Я думал провайдер готовые типы выдает. Вот так machines.DisplayMember <- "Name" machines.ValueMember <- "Id" не видит автосвойства. Их видит только IDE.

Привет. Не могу понять почему JsonProvider в коде видит св-ва (Id, Name etc), а в winforms биндинг не работает. Биндится только ToString(в виде {Id:"", Name=""}. Все равно приходится вводить свои типы и мапить на них перед биндингом. Я думал провайдер готовые типы выдает. Вот так machines.DisplayMember <- "Name" machines.ValueMember <- "Id" не видит автосвойства. Их видит только IDE.

Покажи определения своих автосвойств.

А, ты их нагенерил, интересно.

А JsonProvider генеративный или какой?

Я бы просто начал с того, что потыкал бы декомпилятором в сборку и посмотрел, как эти свойства определены. Вполне вероятно, что они какие-нибудь internal или вроде того, и у JsonProvider могут быть настройки для изменения этого факта.

https://github.com/fsharp/FSharp.Data/blob/49a3bfb22a8955463d7536af1d2df86449e335c6/src/Json/JsonGenerator.fs#L190 Признаться, я не нашёл сеттеров у этих свойств