Как мы пришли к реактивному связыванию в Unity3D

[firnind]

А вы изначально смотрели на UniRx, и он чем-то не подошёл, или сразу стали пилить своё?

[nshalimov]

Смотрели. Если кратко, то в UniRx нет динамических ViewModel, из-за чего авторинг блокируется программистами

[SAWER]

Если бы не строковые константы и ограничение уже по базовым типам. Последнее ещё можно «простить», но вот строковые константы без хотя бы гарантированной обработки ошибок никак нельзя. Хотя тем же страдает и сама Unity, но уподобляться их частой практике 10-летней давности не стоит.
Планируете дорабатывать именно по базовому функционалу(типы, валидация, переменные/перечисления вместо строк), удобству?

Сравнение с другими было бы ок, если бы так же написали о их возможностях, а они, вроде как, в разы больше. Это не плохо, просто и быстро — тоже хороший результат. Но хотелось бы знать чем пожертвовали или чего можно больше получить в сравнении. Такие же таблицы можно найти к любому сериализатору на своей страничке — каждый показывает, что уж его то велосипед лучше других, умалчивая о некоторых незначительных нюансах.

[nshalimov]

Строго говоря константы там не строковые, ключи имеют тип PropertyName обычно их значениня уносятся в константы. Хотя есть желание отказаться от этого в пользу обычных строк. Но я так понимаю, вы не можете «простить» именно «динамичность» вьюмодели? Если так, то дискуссия рискует перетечь в плоскость очердного обсуждения «статика vs динамика». Мы и сами туда часто скатывамся во внутрннних обсуждениях. Но тут был упор именно на то, что набор свойств без особых усилий сформировать может человек, не пишущий код.
Валидация – это хорошо, и мы добавляем проверки, особенно в критичных частях. Но это касается и первого куска кода, который с линковкой компонент в поля, так что тут описанный подход ничем особенным не выделяется.

Дорабатывать планируем. Будет расширение разнообразия типов (очень в этом поможет SerializeReference) и прочие плюшки. А валидация (и даже некоторая кодогенерация) уже частично реализованы.

По функциональности мы покрыли всё, что есть у других участников сравнения, за исключениеем каких-то специфичных вещей, вытекающих из особенностей рализации.

[SAWER]

Здесь я вижу именно частое использование строк, часто даже не вынесенных в константы. К примеру:
_playerId = viewModel.GetString("player/id");
То же в инспекторе.
Проблемы могут быть не видны, если есть всеобъемлющая валидация, но работать с этим будет не удобно, даже при не большом объёме. Я вот как-то не верю, что проблем нет или почти нет вообще, т.к. ни разу не было ни 1 проекта, где несколько раз из-за таких констант что-то не работало.
PS: а code не отработал что-то…

И я тут не о типизации. Но могу и о ней пару слов кинуть. Во вьюхах компонентов как бы «динамика» вполне ок. А вот в логике самой схемы всё таки лучше чистая статика. При любой большой командной работе динамика плодит ошибки, не самые простые для разбора, ухудшает скорость чтения. Опытные программисты могут писать и без таких ошибок, но только пока у них есть понимание каждого элемента кода, условно, пока оперативки хватает. За то динамика импонирует простотой и скоростью перетекания мысли в код, что на тех же формочках даже важнее, да и ошибиться там сложнее. Но если в результате система становится сложной, то проявляется боль, которой нет в статике.

[kraidiky]

1) Очень важная и нужная фича — уметь сериализовывать ViewModel и в случае ошибки отправлять состояние интерфейса в качестве багрепорта. Если ещё не сделали — сделайте, много крови и слёз сэкономите.
2) Адресация по строкам — первородное зло в самой своей чистой форме. Пути для избавления — автогенерящиеся енумы, кастомные контролы на этапе редактирования делающие связывание через рефлекшен, а на этапе выполнения выгребающие данные из автоматически создаваемого массива по индексам.

[nshalimov]

1) Согласен. Есть такой план, даже расширенный – уметь ещё и десериализовать ViewModel. Очень пригодится для автотестов интерфйса. Автотест загружает префаб, пихает в нго условный джсон и смотрит, что получилось. Огромный плюс в том, что при реализации такого тестирования можно максимально абстрагироваться от кода самого проекта.
2) Да, возможно это зло. Но почти за два года использования связанных с этим проблем возникло исчезающе мало. Я подумываю, что тут можно сделать, но меня останавливает нежелание чинить то, что не сломано.

[kraidiky]

1) Хммм… Как интересно. У меня модель может сериализоваться и десериализоваться, но идея использовать это в автотестах мне в голову не пришла. Впрочем, в отличии от вас, у меня никогда не было лишних одного-программиста и одного QA инженера для того чтобы покрыть автотестами не только базовую функциональность, но и все интерфейсы. Я это использовал для другого. У меня модель меняется транзактно и поля обновляются не по вызову Refresh, этот вызов частенько оказывается забыт когда происходят какие-то сложные манипуляции с моделью, а по концу транзакции. Событие раздаётся только изменившимся полям. Если при этой раздаче где-то происходит эксепшен, очень удобно сформировать автоматический багрепорт в который включается состояние модели до начала транзакции и произведённые изменения. А десериализация позволяет ошибку воспроизвести чуть ли не автоматически. ЧТо важно, это избавляет от необходимоти выяснять у реального игрока на проде — чего он там вчера такого нажал, что приложение рухнуло.

[nshalimov]

Думаю, что к этому мы ещё придём.
А для транзактных изменений у нас тоже есть инструменты, но используются они явно. Код в статье слишком упрощён, я не стал там показыать всё. Делается как-то так

using (viewModel.Lock())
{
    // тут мы меняем свойста
} // тут срабатывают все затронутые диспатчеры