архитектурь как хочешь

Согласен. Я тут попробовал сделать драг и друп дерево на редаксе и поседел на профалинге

Вышло reselect на reselect и redux reduce-reducers - ад адский. Надо каждой ноде легко брать уровень, предыдущее, следующее, следующего родителя. Mobx решает, но, нормализация нужна тоже

@computed get childs если делать по записям ужасные тормоза будут из-за того что глубина сравнения большая.

@computed get childIds и только иды решило

А потом выбираем по getById

У кого были такие похожие задачи?

Refs не?

Refs не?

+

Щас представлю код, секунду

Тут выходит, у меня есть dragNode и hoverNode и мне надо брать при перетаскивании следующего родителя через refs?

ref Это модификатор для твоего Observable

observable.ref: Disables automatic observable conversion, just creates an observable reference instead.

Или @zuldare про другое?

Я про рефы, чтоб айдишниками не пользоваться

https://facebook.github.io/react/docs/refs-and-the-dom.html

<Node ref="child12" ?

Я так понял

Да

Конечно такой pure режим)

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

Конечно такой pure режим)

если по ссылкам сранивает всё равно тормозит?

@computed.struct childIds который высчитывает фильтром детей как-то оказался самым оптимальным, без головной боли и чистым по коду

И по скорости лучше

Был вариант при добавлении или правке менять просто массив у детей и не делать computed, пока его не проверил

Тут надо сеттер на parentId навесить

@computed.struct childIds который высчитывает фильтром детей как-то оказался самым оптимальным, без головной боли и чистым по коду

от чего он высчитывает? у детей внутри тоже надо следить за структурой?

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

это затратно конечно

А что собственно мешает нормализоваться с мобиксом?

Извините, что вмешиваюсь

Кто практикует нормализацию данных? Какую практику вытеснения данных из нормализованного хеша используете?

хороший вопрос, присоединяюсь, я не использую никакую, удаляю из ids, оставляю в entities

Кто практикует нормализацию данных? Какую практику вытеснения данных из нормализованного хеша используете?

Никакую. Не храни в сторе не справочную информацию.

Дольше, чем она нужна

Клади все в локалстордж

Оттуда бери мидлварой

Справочную тоже клади в локалстордж, бери ее при ините приложения

Кэшируем айдишники щас по ключу «нормализованная строка запроса»

С таймаутом

Несправочную с не очень большим таймаутом, справочную с большим. Плюс у нас по вебсокету приходят обновления

Дальше поле для маневра

Обсерайте, жду)

Добрый вечер, господа. Такой вопрос. Существует ли в природе роутер, удовлетворяющий таким вот требованиям: 1) history api, hash и серверный роутинг, 1) не зависит от view (react-router отпадает), 2) поддерживает базовый URL, то есть например способен обрабатывать url http://example.com/myapp/users/user как /users/user, 3) поддерживает переход через вызов определённой функции типа router.go('/users/user') ?

собственно react-router похоже удовлетворяет всем пунктам, кроме первого

http://router5.github.io

http://router5.github.io

а он умеет делать переход по определённому пути, а не по имени роутера?

http://router5.github.io

agnostic - как это понимать?

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

да, там нет специфичных моментов для определенного фреймворка

Всем привет! Подскажите как решить проблему. Есть лоадер { test: /\.p?css$/, use: ExtractTextPlugin.extract({ fallback: 'style-loader', use: 'css-loader?modules!postcss-loader', }), }, И теперь хочу использовать react-table. В нём есть свой css файл. Как его оставить в стандартном виде, а не прогонять через модули? Спасибо!

include/exclude

эту css'ку я подгружаю через import 'react-table/react-table.css'

да, include/exclude { test: /\.css$/, loader: getCSSLoader('app'), exclude: /node_modules/, include: [ paths.styles, paths.scripts, ], }, { test: /\.css$/, loader: getCSSLoader('vendor'), include: /node_modules/, },

можешь прописать include и папку со своими сорцами

либо exclude для исключения папок

Никакую. Не храни в сторе не справочную информацию.

не вполне все понял из сообщения. что надо хранить в сторе а что не надо. Я храню в сторе в нормализованном виде коллекции.

понял! Спасибо большое!

не вполне все понял из сообщения. что надо хранить в сторе а что не надо. Я храню в сторе в нормализованном виде коллекции.

а ты используешь normalizr или что-то еще/свое?

ERROR: S client not available

с сервера сразу гоню entities: {[collection]: {[id]: any}} и обновляю нормализованный стор. Там два вопроса 1) грамотный мердж partial 2) GC по записям в нормализованных коллекциях. refcount какой-нибудь придется выдумывать

их столько существует этих политик замещения кэша, но никто не заморачивается почему-то особо, либо я не могу ничего найти, либо не делятся, либо не парятся https://en.wikipedia.org/wiki/Cache_replacement_policies https://github.com/paularmstrong/normalizr/issues/47 https://github.com/gaearon/flux-react-router-example/issues/30 https://github.com/gaearon/flux-react-router-example/issues/18 поделись плиз, если реализуешь) (у меня просто нет таких требований и я даже не заморачиваюсь (но задавался этим вопросом тоже, на всякий случай))

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

или я вообще не понял о чем вы

это клево, это просто не всегда возможно)

а partial update как делаешь?

точнее про кэш и gc я точно не понял о чем вы. в каком это месте вообще нужно и зачем? я как то не задумывался о gc в реакте.

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

а partial update как делаешь?

ну в духе такого return {...state, data: [ ...state.data.slice(0, index), Object.assign({}, state.data[index], action.alert), ...state.data.slice(index + 1) ] } (надеюсь я правильно понял о чем мы)

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

в real-world примере в redux репке даже затронут этот кейс (но наивно, просто именно как пример)

ну я про разные практики спрашиваю. кто как делает

Ну так Object.assign именно это и делает же.

пример. a = { 1: 'ccc', 2: 'aaa' } b = { 1: 'ddd', 2: 'ggg', 3: '222' } c = Object.assign({}, a, b) Object {1: "ddd", 2: "ggg", 3: "222"} f = Object.assign({}, c, {1: '111'}); Object {1: "111", 2: "ggg", 3: "222"}

скоро relay2 выйдет) https://zeemee.engineering/relay-2-simpler-faster-more-predictable-128769e72318#.4xsj54582

я еще в прошлом году слышал про это, но в репозитории тихо было

Aug 18, 2016

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

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

да, мне тоже не зашел он, сложна (я про relay & graphql) + сервер свой

так orm работают

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

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

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

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

поэтому какая разница?

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

В последних проектах я эту проблему вообще решаю с помощью сокетов.

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

Весь блок данных пушишь?