Пока нет

/JSlang

/JSlang

упс

=)

redux-form радует своей активностью)

да, но предыдущую версию пришлось выкинуть и писать свое

Сликшом opinionated ?

очень не удобные на больших формах

плюс просто тыща багов

))

Мне так тоже показалось, когда ещё первый раз прочитал код

это перекат скайп чата?

всем привет

они интересную концепуию предлагают привязки полей к стейту. но не знаю на сколько она хороша в деле

это перекат скайп чата?

Здесь уже больше чем в скайпе

:)

всё? убунта вышла?

Это в девопс чатик)

откуда тогда столько радости? )

/JSlang

?

Итак, мы преодолели отметку в 300. Отлично.

То чувство, когда реакт программистов, больше чем js

Именно :)

Итак, весь список русскоязычных чатов в Telegram по JavaScript, DevOps и DBA на данный момент: + https://telegram.me/react_js + https://telegram.me/angular_js + https://telegram.me/jslang + https://telegram.me/devops_ru + https://telegram.me/dba_ru + https://telegram.me/nodejs_ru Теперь пора заниматься делами. :)

Итак, мы преодолели отметку в 300. Отлично.

ещё бы, заспамил все чаты, чего удивляться... ))

В надежде удалить Gitter и забыть про него :)

Давно пора было

gitter тяжёлый, да

То чувство, когда реакт программистов, больше чем js

ахаха. в жизни так и есть. не все реакт программисты являются js программистами) да и вообще не всегда являются программистами)

по флаксу сюда ведь тоже норм писать?

Да

Про Redux / Flux / Relay тоже здесь всё

ахаха. в жизни так и есть. не все реакт программисты являются js программистами) да и вообще не всегда являются программистами)

вспоминается мем со стаковерфлоу про сложение чисел

Хочу для разминки обсудить почти классическую проблемку, послушать мнения других Есть UserStore, есть OrdersStore. Запрос к серверу для получения orders работает только при авторизованном юзере. Юзер авторизуется необязательно в момент открытия приложения, а теоретически в любой момент. Задача — как только сделан успешный запрос на юзера и юзер сохранён в UserStore (регистрация или логин), — сделать запрос на orders и сохранить их в OrdersStore. Как правильно "связать" эти события? В каком месте "слушать" авторизацию пользователя, чтобы инициировать запрос на orders?

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

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

вот промисы — как раз не по флаксу Но даже если с помощью них — в какое место их засунуть? :)

гусары молчать

http://codepen.io/towc/pen/wGjXGY

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

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

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

если ты можешь подписаться на него, то конечно почему бы нет. В редуксе просто это считается не модным патерном :_

Сторы должны слушать экшны, и никто больше

Иначе это в pub/sub превращается

на крайняк всегда можно в каком нибудь компоненте в componentWillReceiveProps проверять изменения пропса userId или какого нибудь еще и если понимаешь, что юзер изменился, запрашивать заказы. но имхо это не красиво

ну вот если у тебя есть ограничения что кто то что то "должен", тогда да :)

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

ну вот если у тебя есть ограничения что кто то что то "должен", тогда да :)

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

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

ERROR: S client not available

поэтому не вижу ничего плохого в pub/sub

на крайняк всегда можно в каком нибудь компоненте в componentWillReceiveProps проверять изменения пропса userId или какого нибудь еще и если понимаешь, что юзер изменился, запрашивать заказы. но имхо это не красиво

снова чуть ближе, только componentWillReceiveProps не то, конечно, если уж делать подобное из компонента, то это задача компонента-контейнера, который (в идеале) не имеет пропсов. Верно? )

>в перспективе идут на пользу понятности происходящего в теории.

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

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

как запасной вариант, потому что по мне это не красиво

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

хех, примерно то же самое, что в "неклассическом" ))

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

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

Мысль примерно понятна, и да, так сделать можно. Но вопрос-то не в том "как блин это вообще сделать", а как это сделать "канонично" флаксу. Если кто-то считает, что "флакс неидеален / не нужен" — предлагаю с этого начинать ответ. На мой взгляд имплементации флакса хоть и неидеальны, концепция у него крутая и стоит того, чтобы стараться её везде придерживаться.

Насчет форм, если кому надо. Годная, простая, кастомизируемая и интуитивно понятная реализация: https://jquense.github.io/react-formal/docs

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

Плюс там же у него есть еще клевые react-widgets https://github.com/jquense/react-widgets

>какого черта это orders вообще не приходят вместе с юзером, если они так нужны, когда юзер авторизовался? :) Если юзер нужен на всех роутах, а заказы - только на одном, это логично:)

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

в редаксе в качестве контейнера как правило используют .connect(), метод в котором так и называется — map*State*ToProps — так что контейнер не получается пропсы, он берет state из стора. И передаёт уже пропсы.

контейнером в редаксе обычно называется компонент, который оборачиватся в connect

>какого черта это orders вообще не приходят вместе с юзером, если они так нужны, когда юзер авторизовался? :) Если юзер нужен на всех роутах, а заказы - только на одном, это логично:)

@Vogre вот если бы было именно так, то как бы ты решил? Учитывая, опять же, что делать запрос на orders можно только после авторизации юзера.

в map*State*ToProps ты не можешь следить за изменениями, потому что там недоступно предыдущее состояние и там ты не можешь рейзить новые экшены

контейнером в редаксе обычно называется компонент, который оборачиватся в connect

неа, connect это higher order component (то есть контейнер), который передаёт пропсы presentational компонентам

можно и так сказать. я не готов спорить о терминологии, потому что она так же молода как и концепция :)

но факт остается фактом, что mapStateToProps не поможет в решении задачи, потому что в ней нет предыдущего стейта приложения(то есть нельзя отследить, что изменился изер) и нельзя диспатчить экшен(то есть нельза запросить заказы)

я не использую флакс в этих местах. У меня все условные экшнкреейторы возвращают промисы. То есть у меня будет в том коде, где я использую флакс componentDidMount(){ fetchUser() .then(fetchOrders) .then(()=>...UserStore.getUser()...OrderPageStore.pages...) } // fetchUser и fetchOrders - экшнкреейторы Но я повторюсь, я не использую редакс и у меня самописный флакс в проекте и вообще я от него отказываюсь потихоньку и ухожу в фрп:)

но факт остается фактом, что mapStateToProps не поможет в решении задачи, потому что в ней нет предыдущего стейта приложения(то есть нельзя отследить, что изменился изер) и нельзя диспатчить экшен(то есть нельза запросить заказы)

Ага. Верно. Только в том и дело, что по флаксу не надо "следить", особенно в компонентах. Всю логику по изменению состояния берут на себя store, которые оповещают слушателей, если че-то изменилось. Контейнеру как раз нечего следить за тем, что там раньше было (хотя флаксовский контейнер всё же даёт prevState при подсчёте нового стейта https://facebook.github.io/flux/docs/flux-utils.html#container)

я не использую флакс в этих местах. У меня все условные экшнкреейторы возвращают промисы. То есть у меня будет в том коде, где я использую флакс componentDidMount(){ fetchUser() .then(fetchOrders) .then(()=>...UserStore.getUser()...OrderPageStore.pages...) } // fetchUser и fetchOrders - экшнкреейторы Но я повторюсь, я не использую редакс и у меня самописный флакс в проекте и вообще я от него отказываюсь потихоньку и ухожу в фрп:)

@Vogre Вот я так тоже было сделал. Но передумал потом — промисы в таком виде нарушают односторонний поток данных по флаксу.

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

Настроил boilerplate. Команда Webpack выдаёт сборку правильно в директорию. А node server.js на основе express хер знает куда его кидает