Нет

Распечатай строку в консоль

Чтобы без стилей

спасибо, я решил

без шаблонных строк

обычными)

Норм))

Давайте обсудим использование и хранение селекторов. Селекторы нужны, чтобы компоненты не знали о структуре нашего store. В очередной раз пересмотрел видос Дэна Абрамова https://egghead.io/lessons/javascript-redux-colocating-selectors-with-reducers Тут у него есть редюсер todos. И раньше его контейнер в mapStateToProps брал часть дерева, ответственную за todos: state.todos. Чтобы инкапсулировать знание о структуре дерева в файлах редюсеров Дэн делает следующее: 1. В файле с TodoReducer он объявляет селектор getVisibleTodo(todos, filter), который принимает первым параметром срез сторы с данными о тодушках 2. В файле с главным редюсером он объявляет функцию getVisibleTodo(state, filter) => fromTodosReducer(state.todos, filter) В итоге в компоненте мы можем использовать просто getVisibleTodo(state, filter) и при изменении стора нам нужно будет поправить только файлы редюсеров. Все вроде бы красиво, но это только при одном селекторе. А что если у нас 10 редюсеров, каждый из которых содержит по 10 селекторов. Тогда нам нужно будет в нашем файле с rootReducer создать 100 функций, которые пробросят нужный срез дерева в нужный селектор. Как вы решаете эту проблему? Или вооще не паритесь и используете в контейнерах конструкции типа state.todos ...

Давайте обсудим использование и хранение селекторов. Селекторы нужны, чтобы компоненты не знали о структуре нашего store. В очередной раз пересмотрел видос Дэна Абрамова https://egghead.io/lessons/javascript-redux-colocating-selectors-with-reducers Тут у него есть редюсер todos. И раньше его контейнер в mapStateToProps брал часть дерева, ответственную за todos: state.todos. Чтобы инкапсулировать знание о структуре дерева в файлах редюсеров Дэн делает следующее: 1. В файле с TodoReducer он объявляет селектор getVisibleTodo(todos, filter), который принимает первым параметром срез сторы с данными о тодушках 2. В файле с главным редюсером он объявляет функцию getVisibleTodo(state, filter) => fromTodosReducer(state.todos, filter) В итоге в компоненте мы можем использовать просто getVisibleTodo(state, filter) и при изменении стора нам нужно будет поправить только файлы редюсеров. Все вроде бы красиво, но это только при одном селекторе. А что если у нас 10 редюсеров, каждый из которых содержит по 10 селекторов. Тогда нам нужно будет в нашем файле с rootReducer создать 100 функций, которые пробросят нужный срез дерева в нужный селектор. Как вы решаете эту проблему? Или вооще не паритесь и используете в контейнерах конструкции типа state.todos ...

Отказываемся от редакса )

мапСтейтТуПропс недостаточно инкапсулирован ?

Давайте обсудим использование и хранение селекторов. Селекторы нужны, чтобы компоненты не знали о структуре нашего store. В очередной раз пересмотрел видос Дэна Абрамова https://egghead.io/lessons/javascript-redux-colocating-selectors-with-reducers Тут у него есть редюсер todos. И раньше его контейнер в mapStateToProps брал часть дерева, ответственную за todos: state.todos. Чтобы инкапсулировать знание о структуре дерева в файлах редюсеров Дэн делает следующее: 1. В файле с TodoReducer он объявляет селектор getVisibleTodo(todos, filter), который принимает первым параметром срез сторы с данными о тодушках 2. В файле с главным редюсером он объявляет функцию getVisibleTodo(state, filter) => fromTodosReducer(state.todos, filter) В итоге в компоненте мы можем использовать просто getVisibleTodo(state, filter) и при изменении стора нам нужно будет поправить только файлы редюсеров. Все вроде бы красиво, но это только при одном селекторе. А что если у нас 10 редюсеров, каждый из которых содержит по 10 селекторов. Тогда нам нужно будет в нашем файле с rootReducer создать 100 функций, которые пробросят нужный срез дерева в нужный селектор. Как вы решаете эту проблему? Или вооще не паритесь и используете в контейнерах конструкции типа state.todos ...

Проходил через это в несколько стадий: 1) сначала не парился и использовал в контейнерах state.todos. 2) потом читая Дэна в твиттере и посмотрев его видео решил запариться и сделать всё "по уму". 3) Запарлися настолько, что отказался от Redux в пользу MobX

збс

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

А есть отдельные селекторы, которые зависят только от других селекторов

getVisible будет как раз там

Ребят, как задизеблить eslint плагин jsx-a11y в airbnb?

Хранить селекторы рядом с редьюсером имхо так себе идея

Я его снёс и удалил из плагинов, но он видимо где - то в airbnb используется

Потому что можно быстро напороться на циклисеские зависимости

Хранить селекторы рядом с редьюсером имхо так себе идея

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

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

А вот часто бывает ситуация, когда у нас вроде как чистый компонент, но рисует внутри контейнер

Вот куда его?

Есть идея ввести новую папку layouts

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

Скорее всего потому, что этот селектор зависил от структуры стора и его легко было исправить

Я и говорю, что сторозависимые селекторы у меня рядом с редьюсером, а вот селекторы, которые зависят только от селекторов - отдельно

Я и говорю, что сторозависимые селекторы у меня рядом с редьюсером, а вот селекторы, которые зависят только от селекторов - отдельно

У меня таких селекторов нету

Есть идея ввести новую папку layouts

Изучи AtomicDesign

У меня таких селекторов нету

Значит это хреновая структура селекторов, потому что от них нет профита почти)

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

@atomicdesign

Значит это хреновая структура селекторов, потому что от них нет профита почти)

+

Фишка селекторов в том, что можно строить дерево зависимостей

Значит это хреновая структура селекторов, потому что от них нет профита почти)

Хз, они у меня фильтруют, сортируют и.д.

Ну строй дальше

Я не против)

И типа если предки не меняются, то и ребенок не меняется

И это дает ускорение

getVisibleTodos из таких

Он берет тудусы из селектора и фильтр из селектора

Всё ровно не понимаю как и зачем это работает

И если ни тудусы не меняются, ни фильтр, то и висиблТудус не меняются

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

Если так, то я бы написал один слектор, который всё это делает

https://github.com/Day8/re-frame/blob/master/docs/SubscriptionInfographic.md

Если так, то я бы написал один слектор, который всё это делает

Проблема в том, что селекторы, которые зависят от стора, пересчитывается при КАЖДОМ измении стора

Reselect?

А селекторы, которые зависят от селекторов, только если один из селекторв меняется

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

Я на рефрейме раньше писал

Идея интересная, но у меня не возникало таких сложных зависимостей, чтобы до 5 слоя

Максимум 2 слоя

Это повезло значит)

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

Да, потому что часто требуются селекторы от других редьюсеров

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

И начнется цикл

Я бы создал для таких селекторов отдельную папочку в редьюсерах

Да и куда отнести селектор getVisibleTodos

типо hos - hight ordered selectors )

Он же зависит и от тудус, и от фильтра

В эту папочку

я сейчас склоняюсь к такому варианту. В TodoReducer описыватся редюсер getVisibleTodos(todos, filter). В рутовом редюсере описывается getTodosState(state) => state.todos Тогда в mapStateToProps мы юзаем так: { todos: getVisibleTodos(getTodosState(), filter) } Тогда и структура стора изолированна в селекторах и в рутовый редюсер не надо выносить все селекторы из всех редюсеров.

Все mapStateToProps я создаю через структурный селектор в reselect

Я на рефрейме раньше писал

а сейчас как?

Все mapStateToProps я создаю через структурный селектор в reselect

можно подробнее?

че с кложи ушел

ERROR: S client not available

А сейчас я перешел с фриланса на офис и нужно на реактн

https://github.com/reactjs/reselect/blob/master/README.md#createstructuredselectorinputselectors-selectorcreator--createselector

mapState - тоже селектор, который генерит объект

Вот этот createStructured и создает объект из селекторов

Как combineReducers, только Selectors

Круто. Типа такого? export default connect( (state) => structuredSelector(todosSelector, projectSelector, (todos, project) => ({todos, projects})) )(Root)

Круто. Типа такого? export default connect( (state) => structuredSelector(todosSelector, projectSelector, (todos, project) => ({todos, projects})) )(Root)

какая же каша...

Во, Сова пришел! Научи как правильно

ща надо весь тред читать

Проходил через это в несколько стадий: 1) сначала не парился и использовал в контейнерах state.todos. 2) потом читая Дэна в твиттере и посмотрев его видео решил запариться и сделать всё "по уму". 3) Запарлися настолько, что отказался от Redux в пользу MobX

?

Круто. Типа такого? export default connect( (state) => structuredSelector(todosSelector, projectSelector, (todos, project) => ({todos, projects})) )(Root)

нет

совсем не круто

просто чувак от организации пришел к каше

но только в мобикс

и думает это решение

потому что там каша

это официальный подход

што

поинтфри же, эта-редукция, убираем лишние аргументы

Красота, люблю, когда так аккуратно)

ага, понял

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

Есть знатоки yarn? как поставить package-name@^1.2.3 ?

В npm это npm install package-name@1

а в ярн не получается так поставить :c

Или это взаимоисключающие штуки в yarn?

Да, я ответил сам себе на вопрос...

Окей, тогда новый вопрос, как поставить последнюю версию мажорного пакета, типо package-name@1.X.X, где X.X. последняя версия

@kana_sama, в твоем кейсе getIsMessagesFetching имеет вид getIsMessagesFetching = state => state.messages.isFetching ?

Лол, я проспал релиз вебпака 3.0.0