?

Log in

No account? Create an account
November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

Руководство по two-way data binding в React.

Posted on 2016.06.05 at 02:58
Tags: , , , ,
Во-первых, он таки в React есть. Называется value link. Это такой дизайн паттерн. И не смотря на то, что Фейсбук убирает свою кривую реализацию оного из React, он не может вам запретить его использовать.

Понимаем, что это такое, и учимся делать формы на React просто и приятно.

https://medium.com/@gaperton/managing-state-and-forms-with-react-part-1-12eacb647112#.m4awqrpf2

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

Учимся делать валидацию форм красиво, без традиционной для таких случаев боли:

https://medium.com/@gaperton/react-forms-with-value-links-part-2-validation-9d1ba78f8e49#.nbf6s3zee

Ну и в третьих. Самое интересное в этом паттерне вовсе не тот очевидный факт, что он устраняет ненужные коллбэки. А то, что он позволяет полностью отделить (и инкапсулировать) способ, которым выполняется data binding, как от слоя view, так и от слоя данных. Чего вообще ни один из популярных фреймворков не может.

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

Учимся работать со сложным состоянием:

https://medium.com/@gaperton/state-and-forms-in-react-part-3-handling-the-complex-state-acf369244d37#.9f9rp5mwi

Помимо того, что это просто красиво - эта техника сокращает объем кода в JSX примерно вдвое.

https://medium.com/@gaperton/software-managing-the-complexity-caff5c4964cf#.3zdeyc03t

Такие дела.

Comments:


LiveJournal
livejournal at 2016-06-05 08:31 (UTC) (Link)

Руководство по two-way data binding в React.

Пользователь om8 сослался на вашу запись в своей записи «Руководство по two-way data binding в React. » в контексте: [...] Оригинал взят у в Руководство по two-way data binding в React. [...]
brightist
brightist at 2016-06-05 12:39 (UTC) (Link)

какие-то убойные ссылки вы подсунули, не просто браузер схлопывается а весь айпад перегружается :)

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

реакт я не видела, а ангулар меня не впечатлил, хотя мы взяли оттуда пару идей
но наш подход propriatery и вряд ли он когда выйдет за пределы компании

upd: глянула ссылки - очень сложно и все еще messy, видимо пора выходить на публику с нашим подходом



Edited at 2016-06-05 01:05 pm (UTC)
Gaperton
gaperton at 2016-06-05 17:01 (UTC) (Link)
> видимо пора выходить на публику с нашим подходом

Выходите на здоровье, за чем дело встало. Публика оценит. Только в своих постах, пожалуйста.

Edited at 2016-06-05 05:09 pm (UTC)
brightist
brightist at 2016-06-05 17:43 (UTC) (Link)

а вы решили, что публика - это ваш блевничок? ))
какое у вас самомнение :)

неудивительно, что вы довольствуетесь этими жуткими фреймворками - у вас даже нет элементарной вежливости, уже не говоря о профессиональном любопытстве

мучайтесь дальше с вашим реактом :)

Gaperton
gaperton at 2016-06-05 20:47 (UTC) (Link)
Нахуй пошел из моих комментов. Вместе со своими блевничками, фреймворками, самомнением, и оценочными суждениями. Вежливости и профессиональному любопытству он меня учить собрался, смотрите. :)

Edited at 2016-06-05 09:09 pm (UTC)
Gaperton
gaperton at 2016-06-08 06:14 (UTC) (Link)
А нормальным людям я должен напомнить о политике комментариев здесь.

Штука в том, что мудака видно из далека. И переговоров с ними я не веду. Этот случай - классический, и мое поведение в них по шагам описано здесь: http://gaperton.livejournal.com/62888.html Я уверен, что чем больше людей адаптирует подобные правила, тем лучшим местом станет сеть.

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

Edited at 2016-06-08 06:26 am (UTC)
Id.
sachse at 2016-06-08 09:40 (UTC) (Link)
Да правильно всё. Это известный персонаж (кстати, женщина), все темы комментирует с какой-то странной озлобленностью.
Трещиноватые коллекторы. Инструкция.
maksenov at 2016-06-06 08:55 (UTC) (Link)
Выглядит, конечно симпатично, но есть вопрос:

Примеры разобраны для стейта, изолированного в одном "приложении" (ну, или странице) - у нас нет контекста приложения, нет расшаренных или переиспользуемых данных: запросили, отвалидировали, что-то сделали, ушли. Я так понимаю, что от флакса или там редакса какого мы в случае этих подходов не уйдем, да и логику взаимодействия с сервером и прочие кэш и мемоизацию, видимо, нужно будет делать прямо в компонентах, что в случае хитроты будет копироваться во все поля.

И в качестве оффтопика: пробовали ли вы mobx? Мы в текущий проект его засунули, и он вроде и работает, но реактивность местами создает неожиданные трудности (например, при копировании объектов реактивность теряется и нужно делать закат солнца вручную).
Gaperton
gaperton at 2016-06-06 19:10 (UTC) (Link)
> Примеры разобраны для стейта, изолированного в одном "приложении" (ну, или странице) - у нас нет контекста приложения, нет расшаренных или переиспользуемых данных: запросили, отвалидировали, что-то сделали, ушли. Я так понимаю, что от флакса или там редакса какого мы в случае этих подходов не уйдем, да и логику взаимодействия с сервером и прочие кэш и мемоизацию, видимо, нужно будет делать прямо в компонентах, что в случае хитроты будет копироваться во все поля.

Можно вынести разделяемый стейт в состояние корневого компонента, и передавать вниз линки на его части (как в статье номер 3). Но в целом да. Большое приложение на одних линках собирать мягко говоря не очень удобно. Потребуется стейт-контейнер, который может побольше, чем raw react component state.

И он у нас есть. Вот он: https://github.com/Volicon/NestedTypes А вот его привязка к React, где он используется вместо React state. https://github.com/Volicon/NestedReact Линки в данном случае делаются на его элементы.

> И в качестве оффтопика: пробовали ли вы mobx?

Нет. Не потому, что он плох. mobx - это шаг в правильном направлении, просто наш NestedReacts был сделан раньше, и умеет гораздо больше.

Помимо определения глубоких изменений (которые у нас определяются по другому, и обладают транзакционной семантикой, в рамках которой наблюдатели могут добавлять к транзакции изменения, и это будет определено как одно изменение), NestedTypes:

- содержит механизм сериализации, который умеет, в частности, работать с рекурсивными данными вроде деревьев, и отношениями по id. https://github.com/Volicon/NestedTypes/blob/master/docs/RelationsGuide.md

- является "динамически типобезопасным". То есть, он при присваивании в аттрибуты приводит типы, так, что сломать протокол невозможно. Например, если аттрибут Boolean, то там будет всегда лежать Booolean. И на сервер всегда уйдет Boolean.

В наших продуктах (это здоровенный SPA на 100К строк кода) ни flux, ни React state вообще не используется. Только вот это, как единая техника работы с состоянием.

Edited at 2016-06-06 10:39 pm (UTC)
Gaperton
gaperton at 2016-06-06 19:12 (UTC) (Link)
Я скоро напишу о NestedReact. Можно, не дожидаясь этого, посмотреть документацию в репозитории, там есть два примера.
Трещиноватые коллекторы. Инструкция.
maksenov at 2016-06-07 04:38 (UTC) (Link)
Ага, спасибо большое, посмотрим!
Previous Entry  Next Entry