тебе их нужно обернуть в другой компонент и поднять state с методами в него

это первое что в голову пришло, я ищу более простой вариант

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

это первое что в голову пришло, я ищу более простой вариант

это самый простой вариант. есть еще dispatch из redux, но тебе оно пока не надо точно )

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

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

версия 16.2 нужна

теперь на это <React.Fragment>{children}</React.Fragment> ругается Cannot read property 'toLowerCase' of undefined

это первое что в голову пришло, я ищу более простой вариант

это react way

теперь на это <React.Fragment>{children}</React.Fragment> ругается Cannot read property 'toLowerCase' of undefined

ищи где у тебя в children есть вызов toLowerCase

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

redux

ищи где у тебя в children есть вызов toLowerCase

нет, это вроде из этой оперы https://github.com/zeit/next.js/issues/3019#issuecomment-335052394

у меня toLowerCase нигде нет

для такой ерунды не охота хранилище подключать

для такой ерунды не охота хранилище подключать

обернуть в общий компонент

обернуть в общий компонент

ну только только так получается

нет, это вроде из этой оперы https://github.com/zeit/next.js/issues/3019#issuecomment-335052394

ну тогда посмотри как ты делаешь export компонента. если с default, то в import без скобок, если просто export, то со скобками

ну тогда посмотри как ты делаешь export компонента. если с default, то в import без скобок, если просто export, то со скобками

да вот вроде всё окей

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

для такой ерунды не охота хранилище подключать

Почему бы нет?

Хоть один аргумент против?

Почему бы нет?

потому что это как совать везде jQuery, когда надо querySelector заюзать

потому что это как совать везде jQuery, когда надо querySelector заюзать

вообще не аргумент

есть кейс, который покрывается редаксом

есть редакс

всё

есть редакс

а есть задача, которая прекрасно решается без него

Почему бы нет?

потому что его (редакс) придется потом убирать т.к. это нужно только мне для отладки

а есть задача, которая прекрасно решается без него

Смотря какой уровень вложенности будет

потому что его (редакс) придется потом убирать т.к. это нужно только мне для отладки

Тогда юзни контекст и не парься

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

Смотря какой уровень вложенности будет

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

?)

ща нарисую зачем мне это

давай

делать всё равно нехуй

)

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

надо чтобы в нее кастовалось все что в объеуте происходит

сделай hoc

прикрути его везде, где надо

профит

чёт я про хок не подумал

годная мысль

Хоки, ловящие баги

Хок, скрывающий боль

Хок, скрывающий боль

ВГОЛОС

https://github.com/salfetkin/task_manager Плиз хелп)

https://github.com/salfetkin/task_manager/blob/master/src/tasks.js плохо так делать

такая кострукция условностей нужна, когда нужна очень краткая форма, иначе надо использовать if

такая кострукция условностей нужна, когда нужна очень краткая форма, иначе надо использовать if

просто массив надо вынести в переменную, тогда всё будет норм

просто массив надо вынести в переменную, тогда всё будет норм

тогда такая конструкция будет, да, уместна)

но опасна

тогда такая конструкция будет, да, уместна)

здесь вообще можно написать: const exampleTasks = []; const tasks = (localStorage.tasks && JSON.parse(localStorage.tasks)) || exampleTasks;

const tasks = tryLoadTasks() || initTasks; function tryLoadTasks() { try { return JSON.parse(localStorage.getItem("tasks"); } catch(e) { console.warn('in loading got error'); } return null; }

не стоит забывать об эксепшене у парсера

не стоит забывать об эксепшене у парсера

я про общий стиль, а не про конкретный пример с JSON.parse

ну мы тогда одно и тож написали)

Всем привет! Я только пришел в React-мир и реализую первые вещи! Пришел поздороваться с сообществом!:)

https://scrimba.com Прикольно! Смотришь скринкаст, ставишь на паузу, форкаешь текущий код, играешься с ним, смотришь дальше

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

Подождите, кто работает с 4 операциями на беке через одну функцию? У них орм...

А над этим у них стоят контроллеры

А под контроллером модели у которых помимо орм методов еще куча кастом логики

четыре подхода есть 1. мой нелюбимый let new; if (value) { new = 1; } else { new = 2; } 2. иногда приемлемо const new = value ? 1 : 2; 3. лучший имхо function getOneOrTwo(value) { if (value) { return 1; } else { return 2; } } const new = getOneOrTwo(value); 4. через do-notation бабель-плагин по пропосалу const new = do { if (value) { 1 } else { 2 } };

5) const { true: result} = { [true]: 'else', [value]: 'if value === true', } ?

Microfrontends не про это ли?

про это но опыта внедерения поддержки и разработки нигде нет(

А там откуда ты эту картинку достал тоже монолитный бандл в коде?

А, там нет даже reference implementation?

Нет исходников

Даже

Да-а, представляю, какой будет зоопарк фреймворков у конечного юзера на странице...

В описание загляните

Да-а, представляю, какой будет зоопарк фреймворков у конечного юзера на странице...

почему зоопарк?

В описание загляните

Описание чего?)

Описание чего?)

А что ближе всего?

(описание чата)

(описание чата)

А ок, ну бывает ...? А вдруг кого бы нашел)

Правила для всех)

Подскажите, есть какая-нибудь библиотека, которая редьюсеры позволяет задать просто как объект {action: function}? Что-то типа такого { user: { ADD_USER: (state, action) => {...}, REMOVE_USER: (state, action) => {...}, }, } вместо классического { user: function (state, action) { switch (type) { case 'ADD_USER': ... case 'REMOVE_USER': ... default: return state; } }, }

Подскажите, есть какая-нибудь библиотека, которая редьюсеры позволяет задать просто как объект {action: function}? Что-то типа такого { user: { ADD_USER: (state, action) => {...}, REMOVE_USER: (state, action) => {...}, }, } вместо классического { user: function (state, action) { switch (type) { case 'ADD_USER': ... case 'REMOVE_USER': ... default: return state; } }, }

Я не вникал что тебе нужно, но можешь посмотреть сюда http://npmjs.com/redux-symbiote

Да, что-то похожее, спасибо

Есть еще redux-box но там setup сильно меняется

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

Попробую объяснить поподробней - я когда писал проект на редаксе решил не дублировать редюсеры и не создавать кучу отдельных экшенов. Потому что в таких редюсерах непременно будет дублирование функционала подобно такому case "CREATE_PROJECT": { return {...state, projects: {...state.projects, [action.id]: action.data} } case "CREATE_TASK": { return {...state, tasks: {...state.tasks, [action.id]: action.data} } case "CREATE_COMMENT": { return {...state, comments: {...state.comments, [action.id]: action.data} } case "UPDATE_PROJECT": { return {...state, projects: {...state.projects, [action.id]:{...state.projects[action.data.id], ...action.data}} } case "UPDATE_TASK": { return {...state, tasks: {...state.tasks, [action.id]:{...state.tasks[action.data.id], ...action.data}} } case "UPDATE_COMMENT": { return {...state, comments: {[action.id]:{...state.comments[action.data.id], ...action.data}} }Из всего этого меняется только имя таблицы и логично не дублировать функционал и передать имя таблицы параметром case CREATE: { return {...state, [action.table]: { ...state[action.table], [action.id]: action.data}} } case UPDATE: { return {...state, [action.table]: { ...state[action.table], [action.id]: {...state[action.table][action.id], ...action.data}}} }Когда с редаксом мы вынуждены нормализировать стор то все данные будут организованы в плоском списке айдишников в хеш-таблицах. И для того чтобы не дублировать код как выше где дублируется весь код кроме имени мне кажется вполне логичным сделать передачу таблицы параметром и тогда (в идеале) количество экшенов и редюсеров у нас сведется к 3 (плюс еще GET но он обработается в миддлварке). Дальше естественно есть некая бизнес-логика которая не затрагивает добавление, удаления или изменение не одного а много объектов. Эту логику можно конечно оставить в редюсерах и создавать отдельные экшены и редюсеры но почему тогда вообще не использовать редакс как базу данных а логику из редюсеров вынести в отдельные функции вроде thunk-ов или обычных функции. Например тот же редюсер и экшен которы можно назвать как UPDATE_POST_AND_CREATE_TASK а можно просто вынести в thunk который задиспатчит экшен UPDATE передав параметром таблицу "posts" и задиспатчит экшен "CREATE" и передаст параметром таблиу "tasks". И таким образом можно реализовать любую бизнес-логику и не ограничивать себя в невозможности выполнять сайд-эффекты как в редюсерах

логично юзать combineReducers для одинаковых редьюсеров

логично юзать combineReducers для одинаковых редьюсеров

combineActions? Или я что-то не знаю о combineReducers? ?

может вам просто нужен НЕ редакс?

Ээээ

Вот

а actions зачем?)

Всегда будет много одинакового кода

Зато очень легко трекаются все имения стора