У тебя сработает componentWillUpdate два раза. На второе срабатывание будут и пропс, и стейт новые

setState - асинхронный метод. 2 аргументом идет колбэк, ты это знаешь?

да всё это известно, разумеется. Я не спрашиваю, почему так :)

Интересно, как выкрутиться правильнее

например в sCU не давать апдейт, если состояние не то, что ты ожидаешь) Но фиддл сделай, да)

Ну очевидно, что рендер сработает два раза подряд, и на второй раз все будет ок, если ты логику в componentWillUpdate опишешь. Или тебе принципиально, чтобы эта логика стаботала один раз с новыми пропс и стейтом?

в componentWillReceiveProps происходит так же setState, который не стоит пихать в willUpdate

А, ну тогда да, коллбэком в setState() вызывай функцию из родителя на изменение пропс. Ну или пересмотри реализацию этих компонентов )

уффф

в общем как-то так https://jsfiddle.net/69z2wepo/51669/

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

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

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

а где тут средний элемент? ты сохранил изменения в fiddle ?

hello world

блин )

https://jsfiddle.net/69z2wepo/51669/

в общем как-то так https://jsfiddle.net/69z2wepo/51669/

Слишком сложно как-то все

сорри )

вроде упростил по максимуму

из-за этого может цель перестала быть ясной

проблема в общем внутри <SomeComponent />

а <RecursiveComponent /> слушает клик

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

средний это <SomeComponent />

че-то вообще не приходит в голову, как правильно сделать или переиграть (

можно тупо к компоненту свойство прицепить ) но это именно тупо )

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

эээ не, чайлд о родителе ничего не должен знать

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

не, ты не так интерпретируешь )) Когда компоненту что-то передаётся через пропсы, это не называется "компонент знает о родителе". На то и пропсы )

SomeElement получает информацию isActive он или нет Иерархия правильная

@everdimension он не про имплементацию говорит а о том что на самом деле здесь происходит.. он при этом прав.

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

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

Где именно?

@everdimension он не про имплементацию говорит а о том что на самом деле здесь происходит.. он при этом прав.

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

Где именно?

а, ну да, в componentWillReceiveProps собственно

Где именно?

у тебя RecursiveElement1 рендерит SomeElement, который рендерит RecursiveElement2. Проучается что SomeElement создает себе стейт из пропсов RecursiveElement1, вот RecursiveElement2 и дергается 2 раза

блин, если убрать рекурсию, то гораздо проще будет же

у тебя RecursiveElement1 рендерит SomeElement, который рендерит RecursiveElement2. Проучается что SomeElement создает себе стейт из пропсов RecursiveElement1, вот RecursiveElement2 и дергается 2 раза

RecursiveElement не дёргается два раза и проблема вообще не в этом

Так, насчёт того, что стейт выводится из пропсов. Да, нехорошо, но логика такая — компонент, став активным, имеет право выставлять стейт того, какой именно чайлд будет активным

хм, еще RecursiveComponentы прокликиваются, наверное так не задумывалось?

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

в общем-то бабблинг тут работает прекрасно

И вообще всё получалось очень складненько вплоть до вот этого момента

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

Я :) import { keyBy } from ‘lodash’; var list = []; const z = { list, listById: keyBy(list, ‘id’) };

Вот так нагляднее: import { keyBy } from 'lodash'; import { ITEMS_LOADED } from '../constants/actionsTypes'; const initialState = { items: [], itemsById: {} }; const reducer = (state = initialState, action) => { if (action.type === ITEMS_LOADED) { return { items: action.payload, itemsById: keyBy(action.payload, 'id') }; } return state; }; export default reducer;

Используй handleActions из redux-actions

https://github.com/paularmstrong/normalizr

@azrael25 add/remove делаешь Object.assign({} itemsById, obj) ?

Ага, чтоб новый объект каждый раз возвращался

Ок, спасибо

Что-то лень руками поддерживать сразу и items и itemsById на каждое действие

а зачем вообще это нужно? если не сикрет

Чтобы массив каждый раз не переберать. O(1) доступ к айтемам

Чтобы массив каждый раз не переберать. O(1) доступ к айтемам

так при переключании сортировки всеравно его сортировать.. хоть убей пока не понимаю где тут экономия

Как думаете, а что если написать кастомный класс, унаследованный от массива, который будет возвращать новый массив на действия addAt(), removeById, removeByIndex и будет реализовывать поддержание byId?

@Ai_boy сортировки — да, не поможет. Но когда есть несколько хранилищ данных и для отоюражения нужно бегать в соседнии — это облегчит жизнь. Например, у тебя есть массив юзеров и массив публикаций этих юзеров. Ты рендеришь 100 публикаций от 100 юзеров, тебе нужно взять из массива юзеров имена авторов. В одном случае ты переберешь 100 раз массив из n айтемов, в другом — прост сто раз заберешь byId

для упрощение примера, естесственно. Представь что там if какой-нибудь, в чем проблема)

@Ai_boy сортировки — да, не поможет. Но когда есть несколько хранилищ данных и для отоюражения нужно бегать в соседнии — это облегчит жизнь. Например, у тебя есть массив юзеров и массив публикаций этих юзеров. Ты рендеришь 100 публикаций от 100 юзеров, тебе нужно взять из массива юзеров имена авторов. В одном случае ты переберешь 100 раз массив из n айтемов, в другом — прост сто раз заберешь byId

есть же dataloader например

есть же dataloader например

Годится для простых коллекций. Для списка, содержащего данные из разных источников уже не покатит

Годится для простых коллекций. Для списка, содержащего данные из разных источников уже не покатит

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

> @gkuznetsov В одном случае ты переберешь 100 раз массив из n айтемов, в другом — прост сто раз заберешь byId А о каких величинах идет речь? В этой ситуации IndexDB, его враппер или https://github.com/agershun/alasql выглядит логичнее

> @gkuznetsov В одном случае ты переберешь 100 раз массив из n айтемов, в другом — прост сто раз заберешь byId А о каких величинах идет речь? В этой ситуации IndexDB, его враппер или https://github.com/agershun/alasql выглядит логичнее

Тысячи, иногда 10-ки тысяч элементов

Тысячи, иногда 10-ки тысяч элементов

Ну тогда почему не AlaSQL какойнибудь ? // B) SQL on array of objects var data = [{a:1,b:10}, {a:2,b:20}, {a:1,b:30}]; var res = alasql('SELECT a, SUM(b) AS b FROM ? GROUP BY a',[data]); console.log(res); // [{"a":1,"b":40},{"a":2,"b":20}]

Ну тогда почему не AlaSQL какойнибудь ? // B) SQL on array of objects var data = [{a:1,b:10}, {a:2,b:20}, {a:1,b:30}]; var res = alasql('SELECT a, SUM(b) AS b FROM ? GROUP BY a',[data]); console.log(res); // [{"a":1,"b":40},{"a":2,"b":20}]

Посмотрю в эту сторону, спасибо

ERROR: S client not available

Посмотрю в эту сторону, спасибо

FYI - у них очень хорошая WIKI https://github.com/agershun/alasql/wiki/Data-manipulation и вот к примеру пример :) https://github.com/agershun/alasql/wiki/How%20to%20add%20own%20keys%20for%20grouped%20output

Посоветуйте хороших книжек по реакту, желательно на английском. А то на амазоне столько мусора и сложно найти что-то стоящее

Актуальный проект самая лучшая книга

Посоветуйте хороших книжек по реакту, желательно на английском. А то на амазоне столько мусора и сложно найти что-то стоящее

мне хватает статей и видео из https://github.com/enaqx/awesome-react

Ну и всякие бойлерплейты

Актуальный проект самая лучшая книга

А как писать не зная, что пишешь?

Смотришь готовый код, повторяешь, думаешь, пишешь свой

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

а что не так?

если реф - простой тег, возвращается нода. если сложный компонент - возвращается компонент, ну и все это если не депрекейтед, то легаси

ну не так что неединообразно

что когда смотришь в коде на this.refs.someRef, надо выяснять, что там вообще

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

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

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

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

Может есть у кого примеры склейки изоморфного приложения react + redux + universal-router. Интересно что получилось.

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

что за намёк?

Ну, всегда можно версию зафиксировать :)

Note: Although string refs are not deprecated, they are considered legacy, and will likely be deprecated at some point in the future. Callback refs are preferred.

выпиливать хотят ref="string", но ref={this.handleMount} вроде никуда не собирается

ну вот не очень ясно, зачем выпиливать ref=string, простите

коллбэк удобная штука тем, что если её правильно написать (а именно n => this.node = n), то не надо следить, есть ли в доме чайлд — this.node станет null, если компонент-реф анмаунтился

А в остальном разницы использования никакой, так что в чем проблема

То, что реф может быть и чисто дом-элементом, и реакт элементом — актуально для обоих способов (вроде?)

То, что реф может быть и чисто дом-элементом, и реакт элементом — актуально для обоих способов (вроде?)

Кажется да, но не проверял

То, что реф может быть и чисто дом-элементом, и реакт элементом — актуально для обоих способов (вроде?)

Да

ну вот )

Проблема в том, что опять горы кода лопатить

Ладно, к проблемам этого дня. Как благородные доны решают такой кейс: при нажатии кнопки в некоторое место страницы подгружаются данные и в это место необходимо проскроллить окно?

В редуксе, это важно

В редуксе, это важно

Скролл выполнять прямо в редуксе? Чего то не понял мб