t.me/joinchat/Be4rsT3Uyr1TjmSlrRc77g

спс

распетлял

лучше наверное к стору цеплять через .on иначе потом запутаешься в поисках логики его меняющего

Код на гист

лучше один раз изучить мат.часть

спасибо.так и поступлю

@ValeryKobzar Вы действительно мне очень помогли. спасибо

@ValeryKobzar Вы действительно мне очень помогли. спасибо

сегодня мы тебе, завтра ты нам :))

надеюсь дорасту, чтоб помогать)))

Код на гист

это мне?

гайс, а вот в чем проблема если поверх https://github.com/solkimicreb/react-easy-state, запилить что-то типа редукса ?

Чет херня мутирующая

Хотя в этом и смысл

По сути мы мутируем стор, а прокси нас возвращает изменения ? ?

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

Контейнеры не нужны

Ну хотя бы не надо разделять на два файла

Ну хотя бы не надо разделять на два файла

аа реюз, тестируемость, как же ?)

аа реюз, тестируемость, как же ?)

Я подключаю только страницы

У всех остальных компонентов реюзабельность огроменная

Я подключаю только страницы

ну вот я тоже уже стараюсь так делать

Я подключаю только страницы

А страницы невозможно реюзать by design

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

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

+

Вкладывать компоненты с коннектом

а как же апдейты, елементов по айдишке 7

Это конечно адок

а как же апдейты, елементов по айдишке 7

Што

ну пример с tree

редуксовский

ownProps?

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

редуксовский

Ты вообще о чём

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

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

Ты же понимаешь что это невозможно поддерживать

Тестировать тем более

Ибо высокая связанность

Ты же понимаешь что это невозможно поддерживать

да, но перфорформас vs реюз

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

да, но перфорформас vs реюз

Перформанса как раз нет

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

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

В родителе всё получить не ?

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

че ререндерить все дерево ?

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

Ну ты придумал себе проблемы

че ререндерить все дерево ?

Да + scu

И все быстро

че ререндерить все дерево ?

context api тот же юзать можно

context api тот же юзать можно

....

И все быстро

Ибо обновится только одна ветка

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

То есть у тебя все вложенные компоненты с коннектом ?

То есть у тебя все вложенные компоненты с коннектом ?

ну так там реализовывали

ну так там реализовывали

Ну это говно

Ибо флоу обновления становятся категорически сложным

согласен

Контейнеры для переиспользования тоже хороши

Контейнеры для переиспользования тоже хороши

хорошая шутка :))

Контейнеры для переиспользования тоже хороши

Покажите мне кейс где это реально используется

Ни разу не видел

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

Покажите мне кейс где это реально используется

ну вот какой-то серчбар, который работает с редуксом

как тут быть ?

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

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

А оказывается там 500+ компонентов приконнекчены

И обновляются независимо от остальных частей

ну вот какой-то серчбар, который работает с редуксом

Причем тут переиспользование?

Причем тут переиспользование?

он на двух разных табах, но выполняет одну и ту же функцию

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

Мы же вроде этого наоборот и хотим как раз

Или я что-то не так понял?

он на двух разных табах, но выполняет одну и ту же функцию

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

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

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

Тем что у людей мозг ограничен. И держать в памяти все коннекты не в состоянии

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

Обычная страница с чистыми организмами (вложенных) фич

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

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

Обычная страница с чистыми организмами (вложенных) фич

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

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

Затем что ты будешь писать код. Писать писать. А потом раз и охуеешь, что производительность в пизде. А оказалось что обновляется то, чего ты не предполагал

эдакий кадр в кадре

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

Забываешь о существовании sCU?

Забываешь о существовании sCU?

я очень не люблю этот метод

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

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

я очень не люблю этот метод

Сочувствую

насмотрелся всяких JSON.stringify/parse для сравнения стейтов в sCU :))

насмотрелся всяких JSON.stringify/parse для сравнения стейтов в sCU :))

Возьми recompose

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

И бОльший минус - это сложность тестирования

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

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

в смысле - вызовы функции рендера, а не перерисовку

Ну когда код каша тоже норм

Обновил кусочек стейта, перерендерилась половина сервиса

Норм

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

зато явно)

Короче, походу это больше от проекта зависит

Ну не знаю

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

оптимизациями должен заниматься фреймворк и браузер :))

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

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

ну вью жс так и сделал