ок понял, а почему?

есть отдельная группа для этого

Ну да, там примеры в ридми какие-то простые

Да, реселект он не про мемоизацию, а про построение графа зависимостей данных и их "перевыборку" если зависимости не изменились

как вам redux-act?

как вам redux-act?

я так и не понял, что он упрощает

как будто писать надо всё то же самое, что и без redux-act, только другим синтаксисом

Про реселлект в react-boilerplate было не плохо показано.

Да, реселект он не про мемоизацию, а про построение графа зависимостей данных и их "перевыборку" если зависимости не изменились

Надо было остальные 60 строчек исходника дочитать

Паш, а вы его используете у себя?

Из 61?))

Уже 85

Да, понастоящему вкурить реселект было сложнее чем весь редакс. Прочувствовать его так сказать)

Граф реселекта в итоге становиться похожим на некоторую immutable структуру, только в отличие от immutable реализаций и курсоров, где изменения распространяются по стору во время push данных, то в реселекте каскадно во время pull. Это очень мощный концепт. Малюсенький reselect в итоге уделывает монструозные immutable библиотеки, но при это конечно низкоуровневый, поэтому за графом надо следить очень аккуратно иначе все на смарку

Граф реселекта в итоге становиться похожим на некоторую immutable структуру, только в отличие от immutable реализаций и курсоров, где изменения распространяются по стору во время push данных, то в реселекте каскадно во время pull. Это очень мощный концепт. Малюсенький reselect в итоге уделывает монструозные immutable библиотеки, но при это конечно низкоуровневый, поэтому за графом надо следить очень аккуратно иначе все на смарку

Ты так это описываешь, будто там какой-то рокет саенс происходит

Нет, я и говорю что он очень простой. Но то что в итоге получается - очень мощно)

Но из-за кажущейся простоты его часто путают с мемоизацией

Но из-за кажущейся простоты его часто путают с мемоизацией

ну они похожи, но мемоизация менее эффективна, скажем так

Ну она как бы тоже там есть

Ну можно рассматривать это как мемоизацию с длиной 1)

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

Хотел было написать такое, но руки пока не дошли

Но опять же - это не главное, главное - граф зависимостей

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

но я бы советовал следующий learning curve: - vanilla flux dispatcher - redux - mobx

На самом деле mobx это некое продолжение флюкса - во флюксе есть сторы - например user, folder, board, компоненты подписываются на их изменения и обновляются. Сторы также подписываются на друг друга через шину акшинов. В мобиксе все самое, но сторы называются моделями и нет необходимости в диспатчере и общей шине событий потому что благодаря getter-ам и setter-ам компоненты и зависимые сторы прозрачно подписываются на изменения и обновляются когда надо

в мобиксе теже stores. а все остальное - да

я девелопер. я не хочу ничего решать. я хочу нг2 и на ручки

иногда хочется не изобретать велосипеды

нормальный роутер с резолвером данных в стор

уже готовый лейзи роутинг

и еще куча всего что нужно собирать в реакте самому

это с одной стороны очень круто

а с другой утомляет

подход Абрамова и react create app очень крут

нужно чтобы как у эмбера

хуяк хуяк и в продакшн

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

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

с mobx-ом данные данные не раскиданы по разным частям приложения - они просто связанны ссылками (one-to-one, one-to-many, many-to-many). И соотвественно если нужно добраться к каким-то данным (будь они хоть на несколько уровней вверх или вниз ) нужно просто простись по ссылкам через точку. Пример нужно получить аватарку юзера какого-то комментария для которого пишется ответ (модель древовидных комментариев как на хабре) - имеем такую структуру состояния приложения - class User { id; posts = []; } class Post { comments = []; user; } class Comment { comments = []; parentComment; user; post; } в самом начале мы инициализируем App компонент текущим юзером React.DOM.render(<App user={new User({id: 'guest', ....})}/>) и потом в компонентах просто рендерим структуру постов и комментов просто как обычные вложенные объекты <div> {user.posts.map(post=><Post post={post}/>)} </div> <div> {post.comments.map(comment=><Comment comment={comment}/>)} </div> при этом не нужно передавать текущего юзера в пропсах потому что текущий юзер всегда связан с сущностью - Post и Comment имеют ссылку на создателя - поле user (также как и user_id в базе данных) и мы можем где нужно (например глубоко в дереве комментариях) написать <div>{comment.user}</div> (кто написал комментарий) а также <img src={comment.parentComment.user.avatar} /> (аватарка комманта юзера на который отвечают) То есть мы моделируем данные в виде связей а компоненты просто рендерят нужную разметку получая информацию по ссылкам и таким образом не нужно передавать в пропсах кучу зависимостей и не нужно писать стену кода mapStateToProps в редаксе. И в обработчиках тоже достаточно просто изменить нужные данные какого-то объекта (например onClick=(e)=>{ this.props.comment.text = e.target.value } и не нужно парится с тем что нам нужно вернуть полностью иммутабельное дерево всех данных как в редаксе на каждое изменение

В редаксе тоже можно держать обычное дерево

Нормалайзр зло

мобикс можно узать также как редакс

1 в 1

но получать бенефиты от "умного" чендж детекта мобикса

и не писать свои костыльные scu

А мобикс можно без декораторов?

а еще есть как по мне пушка от создателя мобикса - https://github.com/mweststrate/mobx-state-tree

можно

https://mobxjs.github.io/mobx/best/decorators.html

про ненужность/нужность декораторов и мобикса

В редаксе тоже можно держать обычное дерево

в редаксе когда держим данные в виде дерева нельзя делать циклические ссылки а значит нужно передавать недостающие сущности в пропсах (или мапить через стейт) а это очень неудобно когда много many-to-many связей

кстати в случае с деревом комментариев (когда динамическая вложенность) без нормализации вообще не обойтись

А в чем проблема?

редакс вообще против деревьев, это же редюсер, а не tree traversal

Если ты можешь до редюсера включительно сделать дерево

в редаксе когда держим данные в виде дерева нельзя делать циклические ссылки а значит нужно передавать недостающие сущности в пропсах (или мапить через стейт) а это очень неудобно когда много many-to-many связей

Да, данные в сторе raw. Зависимость данных объявляется через reselect, вот там и можно что-угодно связывать с кешированием

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

хотя вроде разобрался, она с текстом делила место, задал тексту % места

реакт

Кто чем пользуется для удаления задержки 300ms на tap на touch девайсах? Нужно чтобы работало как вне, так и с реактом. Простые решения - это meta width=device-width и touch-action: manipulation;, но что делать с остальными браузерами? Дружит ли fastclick с реактом?

> an easier way to create websites Ну не

Кто чем пользуется для удаления задержки 300ms на tap на touch девайсах? Нужно чтобы работало как вне, так и с реактом. Простые решения - это meta width=device-width и touch-action: manipulation;, но что делать с остальными браузерами? Дружит ли fastclick с реактом?

да, дружит

а правильно ли вообще делать реакт приложение с некоторым html + div с реактом? вроде можно было не обращать внимание даже, но теперь Link не перекидывает на # ссылку в простом html ... как правильнее сделать?

да, дружит

спс. Подтверждаю. Но будьте внимательны при импорте с npm. Он не соответствует доке. В доке: import attachFastclick from 'fastclick'; attachFastclick(document.body); Должен быть import Fastclick from 'fastclick'; Fastclick.attach(document.body);

а правильно ли вообще делать реакт приложение с некоторым html + div с реактом? вроде можно было не обращать внимание даже, но теперь Link не перекидывает на # ссылку в простом html ... как правильнее сделать?

<a>?

Link с реакт роутера

на определенный id в простом html

import {LOGIN_USER_SUCCESS} from './constants' LOGIN_USER_SUCCESS дает undefined, при этом в constants.js такой код: export default { LOGIN_USER_SUCCESS: 'LOGIN_USER_SUCCESS' } кто-нибудь сталкивался с таким багом?

классика

ща

у тебя экспорт дефолт не экспортирует именованные экспорты

в последнем бабеле

http://stackoverflow.com/questions/33505992/babel-6-changes-how-it-exports-default

так вроде изменения в require? у меня es6-модуль

второй ответ прочитай

а так вот https://ponyfoo.com/articles/es6#modules

теперь без плагина значит никак для ес6-модулей?

export { hueta: 'hhh' }

export const LOGIN_USER_SUCCESS = ...

в общем когда-то неправильно понятый синтаксис отсекли

в целом ничего особо не изменилось

да кстати, теперь если ты делаешь просто export и хочешь импортировать как объект, то import * as someActionCreators from ...

да кстати, теперь если ты делаешь просто export и хочешь импортировать как объект, то import * as someActionCreators from ...

спасибо, заработало

в общем когда-то неправильно понятый синтаксис отсекли

молодцы какие, не дают заскучать ?

ок понял, а почему?

на Javascript Jobs надо идти, полагаю

ребят, почему на эту строку ругается? там где восклицательный [CHANGE_ROUTE]: (state, payload) => !{...state, currentType: payload}

реакт не желает компилиться

такую строку съедает без проблем [CHANGE_LAYOUT]: (state, payload) => { return {...state, currentType: payload} }

[CHANGE_ROUTE]: (state, payload) => (!{...state, currentType: payload})

[CHANGE_ROUTE]: (state, payload) => ({...state, currentType: payload}) ...

освежи знания про arrow functions немного

да, теперь порядок, спасибо ?

забыл про ({})

Граф реселекта в итоге становиться похожим на некоторую immutable структуру, только в отличие от immutable реализаций и курсоров, где изменения распространяются по стору во время push данных, то в реселекте каскадно во время pull. Это очень мощный концепт. Малюсенький reselect в итоге уделывает монструозные immutable библиотеки, но при это конечно низкоуровневый, поэтому за графом надо следить очень аккуратно иначе все на смарку

Можешь пример на гист выложить вот этого всего что ты тут завернул? Ты сейчас говоришь о случаях применения селекторов в селекторе?

Компонент для ретина-имейдж подскажите

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