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

++

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

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

или поменять структуру редьюсеров

экшоны не поменяются

экшоны это как API твоего хранилища

интерфейс

У меня с таким подходом вышла небольшая проблема

Слишком много екшонов диспатчатся в редукс

это решается через трандьюсер filter

решается - это круто сказано конечно)

на самом деле это будет много бойлерплейта. Но перформанс возрастет

типа третим аргументом

А что может вытворять коннект из react-redux — ууу?

А что может вытворять коннект из react-redux — ууу?

А нук

А нук

За этим лучше в доку.

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

зашел полгода назад, а там пиздец

Ага

Невероятноек количество вариантов работы)

За этим лучше в доку.

Та я шарю, но просто иногда интересные подходы кто-то использует

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

экшон - не модификатор, это просто какое-то сообщение, он может и стейт не менять в принципе

На заметку взял приём когда мы в коннекте забираем id из initialProps и возвращаем функцию, чтобы делать выборку из стейта больше не сверяясь с ownProps вообще

пример пожалуйста, на словах я ничего не понял

да пример

Ну типичный кейс такой, ща

А типа рантайм селектор от айди

Наоборот не рантайм

(

жаль, а то мне пригодилось бы

А то я фигачу селекторы через пропсы (

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

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

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

Кстать мне еще вот такой концепт понравился const initialState = createState({ users: [], genderFilter: null, filteredUsers({ users, genderFilter }) { return users.filter(user => !genderFilter || user.gender === genderFilter); }, totalPosts({ filteredUsers }) { return filteredUsers.reduce((sum, user) => sum + user.postsCount, 0); } }) // Create a new state, updating 'users' value const newState = initialState.copy({ users: [ { name: 'John Doe' , gender: 'M', postsCount: 10 }, { name: 'Jane Doe' , gender: 'F', postsCount: 5 }, { name: 'Alan Turing' , gender: 'M', postsCount: 15 }, { name: 'Ada Lovelace' , gender: 'F', postsCount: 16 } ] })

с селекторами

ух

экшон - не модификатор, это просто какое-то сообщение, он может и стейт не менять в принципе

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

ну так экшоны может слушать не только стор

а всякие мидлвары типа thunk/saga, а стор их можно игнорить

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

пример пожалуйста, на словах я ничего не понял

Есть какой-то список в стейте и в компонент прокидываются его id чтобы он сидел там себе выбирал что ему нужно Обычный вариант const connect(({ list }, { id }) => ({ data: list.get( id ) }) Минусы — постоянно сверяется с ownProps Альтернатива const connect((initialState, initialProps) => { const { id } = initialProps return (state) => ({ data: list.get( id ) }) }

Многим знакомо по идее но почему то в реальности почти никогда не используется)

ну, тут есть учет, что id никогда не поменяется)

А профит только в том что проверки с ownProps не будет ?

ну, тут есть учет, что id никогда не поменяется)

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

по сути, у меня всё тот же экшон, но reducer in action, я всегда знаю как изменится стор, вместо того чтобы подписывать сторы на экшены, я меняю стор там где это нужно за 1 раз. Как это может стать боком в будущем?

ну как можно сделать, вроде // selectors const itemById = createSelectors( items, (state, props) => props.id, (items, id) => items[id] ); // component const mapStateToProps = createStructuredSelector({ item: itemById });

Самая жесть дальше)

connectAdvanced

хм, а создавать сдесь селекторы

решает проблему с динамическими селекторами

и не надо как пропсы их

@reactnative_ru

там уже) спасибо!

и не надо как пропсы их

Во во

блин, я даже не знал что есть такое

Спасибо

Кстать мне еще вот такой концепт понравился const initialState = createState({ users: [], genderFilter: null, filteredUsers({ users, genderFilter }) { return users.filter(user => !genderFilter || user.gender === genderFilter); }, totalPosts({ filteredUsers }) { return filteredUsers.reduce((sum, user) => sum + user.postsCount, 0); } }) // Create a new state, updating 'users' value const newState = initialState.copy({ users: [ { name: 'John Doe' , gender: 'M', postsCount: 10 }, { name: 'Jane Doe' , gender: 'F', postsCount: 5 }, { name: 'Alan Turing' , gender: 'M', postsCount: 15 }, { name: 'Ada Lovelace' , gender: 'F', postsCount: 16 } ] })

но все же в 70% кейсов мне вот так бы селекторы хотелось обьявлять

Почему по центру не встает селектор? Куда уже только не вставлял justifyContent: 'center' <div style={{ flex:1, justifyContent: 'center' }}> <form style={{ width: 87 }}>

А что за датабейс и почему ты это делаешь в селекторе ?

Почему по центру не встает селектор? Куда уже только не вставлял justifyContent: 'center' <div style={{ flex:1, justifyContent: 'center' }}> <form style={{ width: 87 }}>

если селектор inline, то не встанет

если селектор inline, то не встанет

селектор из этой либы https://www.muicss.com

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

датабейс это обёртка для извлечения данных, структура стейта примерно такая { database:{ faculties[]; lecturers[]; } } так же обёртка сохраняет типы и я могу рефакторить бд по всему коду без копипаста

если бы юзал раньше

это все равно не решение для пропсов, которые меняются

Там есть mergeProps

Третий параметр

шарпера видно издалека

это все равно не решение для пропсов, которые меняются

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

Третий параметр

так мердж вызывается постоянно же ?

как решить добавление / удаление я не понял, видимо онли полным ре-рендером

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

так мердж вызывается постоянно же ?

Ну строго говоря не обязательно)

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

как решить добавление / удаление я не понял, видимо онли полным ре-рендером

ну шуд апдейт для елемента

в теории ты должен в елемент только айди передать

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

речь о том, что будет перерендер элемента-списка

а это цикл по элементам, и суть в том, что добавив 1 элемент, придётся пройтись по всему списку

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

Есть какая-нибудь хорошая ui библиотека для реакта?

semantic-ui

semantic-ui

Какой-то он страшненький

React semantic-ui :)

Какой-то он страшненький

¯\_(ツ)_/¯

Какой-то он страшненький

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

Ant как-то по-приятнее....

Ант?

Уахахахха