главное не сдаваться!

вся страна смотрит на тебя!

/stat@comstatbot

Всё для вас

Коллеги, встречаем! Слава вчера рассказывал про Relay и GraphQL. До этого он целый год с ним работал и даже делал свою реализацию.

hello world

у вас тут весело, смотрю

@chicoxyzzy долго еще сидели после меня?

@dmitriiabramov ты в fb работаешь?

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

формат такой

вечером на большие доклады нет времени

на самом деле доклады тут лишь повод

ну да, согласен, тем более всегда можно пообщаться лично

повод встретиться и поговорить

ага

:)

@DenisIzmaylov какие еще чаты в телеграмме?

надо ссылку с набором ссылок

Есть поди awesome list. Ссылка где-то пробегала.

я знаю список всех чатов от mr-mig

надо посмотреть там

https://github.com/A-gambit/awesome-telegram-chats

Вот лови

ага, спасибо

а тут нет их, надо добавить https://github.com/mr-mig/ru-it-chats/blob/master/README.md

Ребят, а есть слайды с докладов или запись?

слайды поищи в твиттере @moscowjs

мои точно есть

видео будет не быстро, его надо обработать

спасибо)

Коллеги, встречаем! Слава вчера рассказывал про Relay и GraphQL. До этого он целый год с ним работал и даже делал свою реализацию.

а где то глянуть этот рассказ можно?

смотри пару сообщений выше

спс

https://t.co/Q8WZgCMPlS

https://t.co/Yhm6RywOz5

Это к вопросу про слайды

?

товарищи, кто пользует redux-form, как считаете для нового проекта стоит сразу брать 6.0.0-alpha или таки 5.2.1? кто то обкатывал уже 6ую версию?

Offtop для тех, кому понравилась идея с эффектом CodeInTheDark https://github.com/codeinthedark/awesome-power-mode

товарищи, кто пользует redux-form, как считаете для нового проекта стоит сразу брать 6.0.0-alpha или таки 5.2.1? кто то обкатывал уже 6ую версию?

5 точно не брать если большие формы

производительность?

вот как раз большие планируются, с complex данными

судя по репке товарищ активно занимается проектом, есть надежда в скором времени увидеть stable

производительность?

вот такой есть мега ишью на эту тему https://github.com/erikras/redux-form/issues/529

производительность в первую очередь

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

плюс очень сырокая либа, куча багов

но достойных альтернатив честно говоря я не нашел, для случаев сложных форм и данных

мы написали простенькую либу

пробовал react-redux-form и react-formal, не то

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

и удобно группировать значение поля, его touched и ошибку в объект, который передается в компонент

BaobabJS для форм по идее, хорош – там в ветках всё, и много-сценарные формы удобно реализовать

и Undo из коробки

все остальное очень опиньёнейтед, в том числе из-за этого сложно что то было под себя переделывать в redux-form

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

если весь стейт всего приложения держать в Baobab

то каждый стейт сохраняется и можно откатить

*каждая версия

Baobab имхо черезчур для меня

http://redux-form.com/6.0.0-alpha.5/docs/MigrationGuide.md/ Array Fields This part of v6 has not yet been written.... тоска печаль

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

ребят как у реакта с роутингом щас/

?

С редуксом норм вяжется ?

http://redux-form.com/6.0.0-alpha.5/docs/MigrationGuide.md/ Array Fields This part of v6 has not yet been written.... тоска печаль

кстати в нашей мини либе мы вообще не делали различий между типами полей и получилось что ничего особенного для массивов не нужно. ты всегда можешь заменить весь массив в своем стейте целиком. А все остальное (concat, delete etc) делать перед тем как отправить экшн на изменение значения

то есть передавали поле внутрь отдельного компонента как "documents" вместо "documents[${index}].some_field"?

годная идея

если нужно редактировать some_field, то передавали documents[${index}].some_field если нужно было добавлять/удалять элементы в documents, то его целиком

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

вот второе нужно как раз

надо обкатать на react-formal, в нем на массивах объектов пошли глюки и стал смотреть в сторону альтернатив

пока мне очень нравится что получается. будем допиливать и может выложим

желаю успеха, обязательно выкладывайте ?

https://t.co/Yhm6RywOz5

мерси

Плагинчик к ESLint для валидации GraphQL https://github.com/apollostack/eslint-plugin-graphql

Спасибо Косте Таркусу за ссылку)

Как вы предпочитаете делать, с bool пропсами

делать их не required, если по умолчанию false, или ставить defaultProps в false?

я по умолчанию ставлю всем required, а если это не возможно, то определяю дефолтное значение для него

в этом случае API становится чуть более явным на мой взгляд

да, тут согласен

@gusnkt https://github.com/JedWatson/react-select/blob/master/src/Select.js#L29-L131

только у него все не required

да, это так

я как пример хотел показать, как досканально можно описывать эти штуки

было круто потом еще доку для компенентов генерить по этим декларациям

я не понимаю, почему не появилось красивого генератора доков по propTypes

это же элементарно делается

https://github.com/kadirahq/react-storybook ?

@gusnkt вероятно внутри больших проектов и делают, правда никто наружу не выкладывает

а так да, там не сложно сделать

https://github.com/kadirahq/react-storybook ?

Цас пользуюсь этой вещью, довольно удобная