?

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
cartoon

NestedReact 1.0 beta. Hierarchical Checklist Demo.

Posted on 2016.08.08 at 21:50

Comments:


Gaperton
gaperton at 2016-08-09 17:50 (UTC) (Link)
> Точно так же есть стор (ака @predefine у вас или класс с @observable полями в mobx)

@predefine это не стор, это определение модели. Которая, на минуточку, рекурсивна, и формирует дерево. В этом примере никакого "стора" нет. Вообще ни одного синглтона.

> Точно так же компоненты биндятся к стору (через @define у вас или @observer в mobx)

Никак компоненты не байндятся к стору, вообще :). Компонента работает с составным локальным state. Я могу три таких компоненты вставить в одну страницу - и они будут прекрасно работать каждая со своим состоянием, не мешая друг другу.

И @define называется словом 'define' а не 'observe' не просто так. Он много что делает помимо создания модели для локального state и 'observe'. Например - собирает миксин для pure render, когда это надо. Или (чего в данном примере нет), возвращает в react классы миксины, которые были в React.createClass.

> Точно так же есть транзакции для изменения стора (ака @action в mobx)

Пока не увижу этот пример на mobx работающим - слова "точно также" мы опустим. Про стор мы уже выяснили, что его в примере нет? Значит, уже не так же. А как-то очень сильно по другому.

> На mobx вам указывают совершенно справедливо - с точки зрения апи библиотеки практически ничем не отличаются:

Не вижу в API в принципе ничего общего. Кроме факта, что в mobx тоже наблюдаемое состояние (оно дофига где есть, вообще-то - еще knockout его делал), и тоже есть класс-декораторы с @ (если они есть - это совсем не означает, что они одинаково работают). И не понимаю, в чем "справделивость" этих указаний, которые делаются вместо приложения элементарных усилий чтобы понять, о чем речь. Вы ж не веганы, чтобы по любому поводу лезть к людям и заявлять - "я веган!"

> утверждение про "самый простой способ управления состоянием" по крайней мере спорно

Поспорьте. Желательно, в виде примера кода - самый лучший способ спорить. Мой пример - вот. С удовольствием посмотрю ваш.

> не очень понятны перспективы использования вашей либы вне компании, при живом-то mobx (и при том что у них версия 2.4 а у вас 0.6)

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

Edited at 2016-08-09 06:33 pm (UTC)
Курилыч
kurilka at 2016-08-09 19:42 (UTC) (Link)
Жжесть, 20 раз редактировать комммент...
Gaperton
gaperton at 2016-08-09 20:31 (UTC) (Link)
Я к комментам отношусь серьезно, как к части поста, так что можно и 20 раз. С учетом опечаток. Он за эти 20 раз принципиально не поменялся, не так ли?

ЗЫ: Этот коммент уже редактирован 1 раз.
ЗЗЫ: Вообще - мой коммент, что хочу, то с ним и делаю. Редактировано 2 раза.

Edited at 2016-08-09 08:38 pm (UTC)
ЛёШа Фу!
kvasdopil at 2016-08-10 15:15 (UTC) (Link)
> Поспорьте.
Да пожалуйста. https://github.com/kvasdopil/checklistTree

В принципе, видны преимущества вашей библиотеки:
1) из коробки есть сериализация и контроль типов
2) прикручен 2-way биндинг к контролам форм
3) (наверное) оно быстрее работает на ваших задачах

С другой стороны, от синтаксиса апей хочется разрыдаться.
Gaperton
gaperton at 2016-08-10 21:25 (UTC) (Link)
А что, выглядит совсем неплохо. Кода чуть побольше, но незначительно.

Индивидуальная подписка каждого экземпляра на обновления своих данных с автоматическими локальными апдейтами - это конечно выглядит очень круто. Это то место, где эти примеры работают по разному - NestedReact подписывает на обновления только state, и update идет сверху, отсекая лишнее pureRender-ом.

Локальные обновления тоже можно, но их надо включать отдельной строкой (listenToProps = 'propName1 propName2' ) и выносить state в store. Мы так не любим делать. Хотелось бы посмотреть, как оно будет работать в случае со state - для чистоты сравнения. И что там тогда с рендерами будет.

А так да, по возможностям наблюдения за состоянием получается практически равноценно. Отсутствие data binding, сериализации, валидации (в этом примере не используется) - это, пожалуй, основное.

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

Edited at 2016-08-10 09:43 pm (UTC)
Gaperton
gaperton at 2016-08-10 22:11 (UTC) (Link)
Ну и спасибо, конечно. Отличный пример.
ЛёШа Фу!
kvasdopil at 2016-08-11 06:00 (UTC) (Link)
Вам тоже спасибо, идея линков меня заинтересовала. Задницей чую что их можно получить в mobx из коробки. Напишу если найду.
ЛёШа Фу!
kvasdopil at 2016-08-11 08:44 (UTC) (Link)
В общем от mobx функциональности линков добиться не получилось. Они там внутри используются (ака BoxedValue), но их проблематично достать из рендера.
В принципе, всё легко решается наколхоживанием линков руками (см https://github.com/kvasdopil/checklistTree/blob/master/src/link.js) и валидаторы туда засунуть не проблема. Правда есть сомнения, что оно будет прям настолько уж удобно.

Оно будет несколько удобнее, если формы описывать живыми реактовскими компонентами. Просто мы вместо этого пишем что то типа

popupForm({
 title: "Edit User",
 data: this.object,
 fields: [{
  name: 'name',
  validator: validators.UserName,
 },{
  name: 'icon',
  type: IconSelect
 }]
})

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

А как у вас валидация сделана? Мож я не понимаю чего-то?
Gaperton
gaperton at 2016-09-06 02:24 (UTC) (Link)
Все просто. Во-первых, реализация линков вынесена в отдельный пакет.

https://github.com/Volicon/NestedLink

Там кода совсем немного, и он простой. Его можно почитать.

Во-вторых, эти линки легко прикручиваются к любому источнику данных. Сделать привязку к mobx - это немного поправить метод Link.state. Надо сделать линк, который вместо setState при записи тупо пишет в проперти объекта. И все.

Еще надо поправить Link.all(). По хорошему - эта пара поправленных методов выносится в базовый класс, рядом с которым кладется новый подкласс линков.

Вот так это делается для NestedReact: https://github.com/Volicon/NestedReact/blob/develop/src/nested-link.js
Gaperton
gaperton at 2016-09-06 02:28 (UTC) (Link)
Могу добавить, что эти линки из NestedLink мало того, что дохрена могут (что, впрочем, в случае mobx по большей части не нужно, но валидацию на коленке, например, могут), но лишены их традиционных недостатков о которы пишут в сети. Например, они умеют кэшируются в компоненте. Что не ломает pure render.

Последнее, впрочем, тоже в случае mobx не особенно нужно, наверное. Там локальный render ведь всегда, вроде. ХЗ, как это с линками будет дружить при их передаче в другие компоненты.
Gaperton
gaperton at 2016-09-06 02:35 (UTC) (Link)
Валидация сделана так. http://slides.com/vladbalin/deck#/

Каждый класс модели и коллекции умеет валидировать себя, и метод model.getLink( 'attr' ) протаскивает validation error модели как еще один проперти линка.

Принцип, как линки используются для валидации, объяснен здесь: https://medium.com/@gaperton/react-forms-with-value-links-part-2-validation-9d1ba78f8e49#.78tgyjp5m

Этот трюк - это по настоящему круто, кстати. Позволило сократить код форм в нашем продукте примерно в половину. ИМХО - это главнейший аргумент в пользу линков. То, что они позволяют писать минус пропс - это ерунда в сравнении с валидацией.

Edited at 2016-09-06 02:37 am (UTC)
Previous Entry  Next Entry