В draft нельзя сделать отображаемые через compositedecorate элементы immutable? то есть чтобы при удалении символа удалялся весь элемент

Господа, вкратце скажите плиз, насколько действительно резонно отказываться от redux в пользу mobx? По первым впечатлением прям все классно у mobx, но на счет скорости и удобства в практике - не знаю, хотелось бы услышать как + так и критику, если есть таковая естественно в рамках отдельного реакт приложения

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

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

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

Меня он приклек своей системой, что сейчас на хайпе(как мне кажется), а это декораторы и наблюдатели

Меня он приклек своей системой, что сейчас на хайпе(как мне кажется), а это декораторы и наблюдатели

тебе кажется ) Он был на хайпе немного раньше. Декораторы вообще хз где сейчас. Я бы не начинал изучение реакта с него, лучше потом.

тебе кажется ) Он был на хайпе немного раньше. Декораторы вообще хз где сейчас. Я бы не начинал изучение реакта с него, лучше потом.

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

при remote debug андроид телефона через хром react dev tools недоступны((( можно пофиксить?

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

это браузер подставляет а не девсервер

покажи output

publicpath скопируй туда такой же как в wds

помогло, спс

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

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

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

ну, для реализации прототипа - скорость очень неплохо

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

Мобх реально проще и яснее

Редукх нужен на больших проектах, чтобы понять что куда идет

ну, для реализации прототипа - скорость очень неплохо

Вот вот

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

Господа, вкратце скажите плиз, насколько действительно резонно отказываться от redux в пользу mobx? По первым впечатлением прям все классно у mobx, но на счет скорости и удобства в практике - не знаю, хотелось бы услышать как + так и критику, если есть таковая естественно в рамках отдельного реакт приложения

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

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

и соотвественно прощай object assign в редьюсерах, правильно я понял посыл?

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

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

ну а если не нужно, можно сделать immutable.js не?

просто через get и setработать

эт чет про теплое и мягкое немного

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

Ой чувак, с реактивностью можно так проебатся

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

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

Тем более можно лучше это паттерн юзать

Ой чувак, с реактивностью можно так проебатся

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

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

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

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

с этим никто не спорит

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

кстати в mobx как раз нет необходимости мапить какое либо состояние из стора на пропсы в mapStateToProps, ты свободен в рендере компонента достучаться до любого объекта данных из состояние по цепочке - например имея некий объект можно спуститься по дереву вниз <div> comment : {props.user.folders[0].projects[0].tasks[0].comments[0].text} </div>или наоборот по цепочке вверх имея объект комментария <div> comment's folder name: {props.comment.task.project.folder.name} </div>и мобикс способен понять что тот или иной компонент зависит не только от последнего свойства а и от всех предыдущих и будет обновлять компонент каждый раз когда изменится не только свойство .name а и свойтсво .folder у проекта (проект могут переносить из одной папки в другую) а также свойство .project у задачи (задачу тоже могут переносить из одного проекта в другой) и т.д

с этим никто не спорит

так я это и сказал в прошлом сообщении))

так я это и сказал в прошлом сообщении))

так я обращаю внимание на то, что фишка флакса не иммутабельности)

а фишка редакса в свою очередь в описании изменений редьюсерами

так я обращаю внимание на то, что фишка флакса не иммутабельности)

так я не про флакс, а про редакс и мобх)

так я не про флакс, а про редакс и мобх)

ну редакс основан на идеях флакса

ну редакс основан на идеях флакса

оч отдаленно имхо

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

а остальное по-другому

кстати в mobx как раз нет необходимости мапить какое либо состояние из стора на пропсы в mapStateToProps, ты свободен в рендере компонента достучаться до любого объекта данных из состояние по цепочке - например имея некий объект можно спуститься по дереву вниз <div> comment : {props.user.folders[0].projects[0].tasks[0].comments[0].text} </div>или наоборот по цепочке вверх имея объект комментария <div> comment's folder name: {props.comment.task.project.folder.name} </div>и мобикс способен понять что тот или иной компонент зависит не только от последнего свойства а и от всех предыдущих и будет обновлять компонент каждый раз когда изменится не только свойство .name а и свойтсво .folder у проекта (проект могут переносить из одной папки в другую) а также свойство .project у задачи (задачу тоже могут переносить из одного проекта в другой) и т.д

спасибо за разъяснение, на счет мапов я был в курсе, но такие детали по mobx не знал. спасибо

а остальное по-другому

а там "остального"-то не так много)

Ребята, как в пропТайпах дописать к этому или еще тайтл может быть объектом ? title: _propTypes2.default.string,

вообще хуйня это все

данные в редакс вообще нехрен складывать

тем более сложные

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

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

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

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

нахуя tho

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

несколько сторов

несколько сторов

ну разве что так, да

но это тоже ебень

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

потому что connect

кстати connect принимал стор через prop а потом это сломали

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

и отказываются чинить

А еще такой вопрос: Это нормально в реакт редаксе хранить состояни 3 табов, дабы при инициализации один показывать, а остальные по переключению? Мне просто подобное "переключение" интерфейса немного кажется не целесообразным для стора, не? Или я дурень и пока не понимаю реакт-редакс?

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

То есть несколько сторов нужно ради увеличения производительности?

То есть несколько сторов нужно ради увеличения производительности?

да

А еще такой вопрос: Это нормально в реакт редаксе хранить состояни 3 табов, дабы при инициализации один показывать, а остальные по переключению? Мне просто подобное "переключение" интерфейса немного кажется не целесообразным для стора, не? Или я дурень и пока не понимаю реакт-редакс?

нечего этому делать в редаксе)

ERROR: S client not available

табы хранишь либо в стейте, либо если важен персистенс, то этот стейт переносишь в урл

ну, т.е. вот кусок редьюса: const tabs = (state = {}, action) => { switch (action.type) { case 'SET_VISIBLE': let tabs = { blocks: false, common: false, options: false, }; tabs[action.tab] = true; return Object.assign({}, state, tabs); default: return state; } } export default tabs; не мой код, просто думаю перепилить все к чертям, и вот изучаю

Object.assign({}, state, tabs); какой-то очень старый код

ну, т.е. вот кусок редьюса: const tabs = (state = {}, action) => { switch (action.type) { case 'SET_VISIBLE': let tabs = { blocks: false, common: false, options: false, }; tabs[action.tab] = true; return Object.assign({}, state, tabs); default: return state; } } export default tabs; не мой код, просто думаю перепилить все к чертям, и вот изучаю

пиздец)))

ну и есть в createStore 'tabs': { 'blocks': true, 'common': false, 'options': false, }

ну, т.е. вот кусок редьюса: const tabs = (state = {}, action) => { switch (action.type) { case 'SET_VISIBLE': let tabs = { blocks: false, common: false, options: false, }; tabs[action.tab] = true; return Object.assign({}, state, tabs); default: return state; } } export default tabs; не мой код, просто думаю перепилить все к чертям, и вот изучаю

я бы через роутер сделал

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

let tabs = { blocks: false, common: false, options: false, }; tabs[action.tab] = true; return Object.assign({}, state, tabs); это все пишется так: return { ...state, [action.tab]: true}

let tabs = { blocks: false, common: false, options: false, }; tabs[action.tab] = true; return Object.assign({}, state, tabs); это все пишется так: return { ...state, [action.tab]: true}

а на false текущий таб сбросить?)

let tabs = { blocks: false, common: false, options: false, }; tabs[action.tab] = true; return Object.assign({}, state, tabs); это все пишется так: return { ...state, [action.tab]: true}

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

а на false текущий таб сбросить?)

бля точняк

наебланил((

пиздец)))

чем плох Object.assign?

чем плох Object.assign?

код плох тем, что за каким-то хуем он в редаксе

чем плох Object.assign?

тем что есть спред

здесь енам проще типа activeTab: TAB_NAMES.blocks

код плох тем, что за каким-то хуем он в редаксе

это в редусере, а задача редусера как раз менять часть стейта? не?

это в редусере, а задача редусера как раз менять часть стейта? не?

в стейте эта дичь-то зачем?

Если ожидать зовершение промиса в middleware то как скрывать модалки О.О

жсу 20 лет, посоны обсуждают как сделать табы)

тем что есть спред

let tabs вынести наружу и сделать из него initialState

let tabs вынести наружу и сделать из него initialState

да и вообще let => const

let нужен-то раз в полгода

в стейте эта дичь-то зачем?

в целом конкретно приведенного выше примера согласен

жсу 20 лет, посоны обсуждают как сделать табы)

да как бы есть своя реализация сайдбаров на нативе, но вот сижу и думаю как правильно вообще сие на реакте делается.. ? сижу, смотрю на реакци., понимаюЭ, что моя 5-я точка правильно подсказывала, что что-то здесь нечисто

let нужен-то раз в полгода

let же существует только в текущей области видимости => меньше работы для gc?

let же существует только в текущей области видимости => меньше работы для gc?

const тоже

тогда ок

хотя при транспиляции один хрен все в var хреначится

хотя при транспиляции один хрен все в var хреначится

Говорят, что можно не транспилировать.

модно когда модные браузеры