Jakobz (jakobz) wrote,
Jakobz
jakobz

Хочется странного датабиндинга на стероидах

React охуенен. Я как все устаканю отпишу обязательно.

Для полного экстаза оперденестроения, хочется понять как решать такую задачку:

В оперденях есть формы. У них есть какой-то "основной" стейт, грубо говоря все поля - то что мы умеем получать с сервера и сохранять туда же. Объект, который мы редактируем, и ничего более. Ну, типа для формы с полем "Name" и списком с добавить/удалить в элементах которого - дропдаун и поле ввода для чисел, стейт будет с каким-то таким типом: { string orderName, [{ int productId, int amount}]}.

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

Чтобы все эти save/cancel/undo работали, стейт хочется держать монолитным и сериализуемым. по крайней мере иметь возможность в любой момент его вынуть и вставить другой.

С другой стороны, есть компоненты, которые делают что-то типа "если чувак выбрал что-то в дропдауне, надо в табличку навалить элементы из словарика по выбранному ключику". И с этой стороны хочется давать этим компонентам возможность влезть в момент когда дропдаун обновляет стейт, и заодно обновить стейт таблички. Чтобы работали механизмы типа undo, стейт должен поменяться атомарно, никакие события типа "что-то в стейте поменялось" - не катят.

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

Я изобразил пока наколенный data binding - есть обертка над общим стейтом, от которой можно кусочек с get()/set() отколоть и отдать, а от него - можно еще кусочек рекурсивно. Что-то на линзы похожее короче. Оно работает, но пахнет императивным пиздецом.

Может быть кто посоветует чего? Мне видится что-то типа гибрида FRP и линз - от FRP возможность гибко содинять и "врезаться в провод", от линз - двунаправленность. Или может я FRP не раскурил, и через него это все решаемо?

Также не откажусь от любых советов/ссылок/книжек по теоретическому и прикладному оперденестроению.
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

  • 12 comments
О, я подпишусь на комменты.
посмотреть на Om и cjs ?
А cjs - это что?
ClojureScript, подозреваю
в общем да, мне кажется, что надо модель данных построить по заветам Окасаки, и в этом смысле Om таки подходит. но брать clojurescript в продакшен я пока не готов)
ClojureScript больно уж джедайский. У меня идея как раз противоположная - придумать подход, который масштабируется на среднестатистических программистов. Но на него в планах посмотреть, ссыкотно только что полюблю и ничего больше не захочется :)

Кроме того, сам по себе ClojureScript не решает обозначенной проблемы. Да, там все проще будет и логичнее из-за иммутабельности, но какие-то хитрые линзы для форм все равно надо будет придумывать.
"если чувак выбрал что-то в дропдауне, надо в табличку навалить элементы из словарика по выбранному ключику"
в обозначенном Ом`е при выборе в дропдауне чего-то предполагается делать swap! в глобальном стейте: допустим в поле field теперь у нас "newvalue".
и никуда ничего не наваливать не стоит, табличка должна сама иметь "правило" рендеринга (из стейта в хтмлю условно), которое знает, что если в стейте у field какое-то значение, то надо отрендериться списком "из словарика по ключику".

Идея в том чтобы сделать декларативно, а не императивно типа "навалить"

Вроде так, м?
Там суть в том, что "навалить из словарика" надо именно в стейт - там потом это наваленное можно менять еще руками - добавлять/удалять/редактировать эти строчки. Т.е. изменение дропдауна вызывает изменение не только стейта "значение в дропдауне", но и действие типа "сходить ajax-ом за табличкой и смерджить ее в текущий стейт таблички".

Впрочем, наверное я там действительно по непытности перемудрил - надо было конкретно в данном случае делать изменение всего стейта по колбеку от дропдауна, в момент прихода ответа на ajax.

Про Om - я понимаю что иммутабельность с react заживет очень круто, и как в целом с таким подходом в ФП строить UI мне тоже в целом понятно - я делал что-то вроде на Хаскеле. Просто мне в данный момент надо что-то более мейнстримное чем Clojure.
про джейдайский vs среднестатистический — да, проблема понятная. я бы подискутировал, что, мол, конечно все зависит от того, что делаем и кто решает, но возможно корень всех проблем в проекте часто в умолчательном соглашении с тем, что нужно быть готовым работать со "среднестатистическими программистами" ))
которые имхо подразумеваются как "лажовенькие".
Im i right?
Да, примерно так.
Кажется вот в этом tutorial по Om в точности такой пример рассмотрен: https://github.com/swannodette/om/wiki/Basic-Tutorial#wiki-interactivity--higher-order-components
Я скоро попробую на Реакте написать линзу которая делает AES encryption для JSON-обьекта, можно запасаться попкорном ;-)

А, и diff-merge тоже напишу)