ебучий mobx, как он меня бесит

удали

нет

+

удали

упрости себе жизнь

npm install redux-most most

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

всего одну ночь

у тебя их ещё столько в жизни будет, уххх

закачаешься

npm install redux-most most

вот кстати redux-most меня разочаровал

нужно его форкать

чтобы пробрасывать объект с апишками

Как я это пропустил

топ 3 фреймворков для реакта)

Аааааааааааааааааааааа

Реакт это фреймворк ?

чшш

пусть Сергей ответит

без гуглежа

react библиотека

Красава ?

flux/redux фреймворки, ты спросил для верстки или для чего фреймворки?

блядь

нет

Че это за челик лол

чтобы пробрасывать объект с апишками

Я уже к себе форкнул

ебучий mobx, как он меня бесит

А что он там кстати?) Какие-то проблемы?

какие бывают кейсы, что computed не перевычисляется, если стор обновился?

Если мы знаем, что ни один из его источников не обновлялся

Или у автора просто беспощадная мемоизация

предположим я инжекчу некий объект X и имею проп Y и делаю компутед Z = X[Y] потом вызываю Z.F(), экшон котоый меняет поле в Z ререндер будет? По сути наш источник - это только X, он изменился?

Ох, чёт загонистое

пока читал захотелось повеситься...

предположим я инжекчу некий объект X и имею проп Y и делаю компутед Z = X[Y] потом вызываю Z.F(), экшон котоый меняет поле в Z ререндер будет? По сути наш источник - это только X, он изменился?

че значит меняет поле в Z

а

это мобх?

да

/pidorstats@SublimeBot

Топ-10 пидоров за текущий год: 1. Ilia — 3 раз(а) 2. Dmitry_Kovbasa — 2 раз(а) 3. goodmind — 1 раз(а) 4. Adsumus — 1 раз(а) 5. jqueryisamonad — 1 раз(а) 6. defaultvoice — 1 раз(а) 7. kelin2025 — 1 раз(а) 8. tetris0k — 1 раз(а) 9. vlastachu — 1 раз(а) 10. reeei — 1 раз(а) Всего участников — 20

/pidor@SublimeBot

Согласно моей информации, по результатам сегодняшнего розыгрыша пидор дня - ZeroBias!

Топ-10 пидоров за текущий год: 1. Ilia — 3 раз(а) 2. Dmitry_Kovbasa — 2 раз(а) 3. goodmind — 1 раз(а) 4. Adsumus — 1 раз(а) 5. jqueryisamonad — 1 раз(а) 6. defaultvoice — 1 раз(а) 7. kelin2025 — 1 раз(а) 8. tetris0k — 1 раз(а) 9. vlastachu — 1 раз(а) 10. reeei — 1 раз(а) Всего участников — 20

лол

Выглядит странно

Выглядит странно

что именно? isFetching - нода с двумя сеттерами и одним геттером значений этой ноды comments - генерация бойлерплейта ноды (редьюсер и селекторы) для { ids, entities }, используя переданные экшоны (сеттеры) и селекторы. merge - ну это просто reduce-reducers, слияние двух нод так, чтобы они работали над одним куском стейта правильно было бы написать const isFetching = createNode(); const commentsTable = createTable(); const commentsExtra = combineNodes({ isFetching }); export const comments = mergeNodes( commentsTable, commentsExtra ); но .merge - небольшой хелпер для упрощения

массива элементов

А можешь кинуть Линк на кодакс?

А че это вообще

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

это все для редакса

А можешь кинуть Линк на кодакс?

https://github.com/kana-sama/coredux/blob/master/example/nodes/comments.js

https://www.npmjs.com/package/coredux

https://github.com/kana-sama/coredux/blob/master/example/nodes/comments.js

сэнкс

но чет я не въехал в проблематику

что решает пакет?

https://github.com/kana-sama/coredux/blob/master/example/nodes/comments.js

оооо дуальность

что решает пакет?

ща

Ридми напиши

Их тяжело писать

Ридми напиши

лень, когда-нибудь в будушем

что решает пакет?

редьюсеры по сути представляют собой композируемые сеттеры. Если мы имеем некий редьюсер, который изменяет свой стейт по экшону, то мы можем этот редьюсер скомбайнить с другими в более сложный редьюсер и этот экшон все еще будет менять только тот нужный кусок стейта, где бы он не находился то есть редьюсеры свободно комбинируются, им не нужно знать структуру стора и где они находятся относительно других редьюсеров с другой стороны, если мы в одном модуле с редьюсерами объявляем селекторы, то они уже зависят от структуры и должны точно знать, где находятся редьюсеры в сторе const getPostsIds = state => state.tables.posts.ids; const getPostsEntities = state => state.tables.posts.entities; const getPosts = createSelector( getPostsIds, getPostsEntities, denormalize ); В коде выше getPostsIds и getPostsEntities зависят от структуры стора и при перемещении редьюсеров в сторе нам придется их менять. Подход "базовые селекторы/сложные селекторы" выше помогает уменьшить количество правок, но не убрать. Ну и собственно я решил, что это какая-то чушь, почему бы вместо write-only редьюсеров нам комбинировать сущности, дающие нам возможность и писать (редьюсеры), и читать (селекторы), линзы по сути. Такую сущность я временно назвал нодой. Имея две ноды со своими сеттерами и геттерами мы можем их скомбинировать в одну ноду со стейтом-объектом (как в combineReducers), которая будет иметь все сеттеры и геттеры обоих нод, причем гететры и сеттеры будут знать как добраться до именно нужных полей. Сеттинг и геттинг происходит с помощью специальных объектов, экшоны (как и ранее) для записи и запросы (query) для чтения. После этого мы можем такие модули комбинировать как угодно и селекторах не нужно будет явно указывать, в каком месте они находятся.

что решает пакет?

https://github.com/kana-sama/coredux-example/tree/master/src Вот нормальный пример без всяких createTable, два популярных способа строить редьюсеры

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

+

ну вообще это мягко говоря так и есть)

И у мобикса тоже

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

сначала подумал, что сейчас будет что-то про топологии, гомотопии, гомологии

К счастью это всё же дискретка а не топология))

нужно вернуться к теории групп, чет я на неделю в редакс ушел

И у мобикса тоже

Интересно почему? - насколько я знаю в mobx используется самый оптимальный алгоритм. Mobx можно представить как 2д-редакс - из-за того что mobx observable-декоратором создает по redux-стору (обзервабл-объекту) на каждое после-ячейку состояния приложения то компоненты могут подписываться на эти ячейки независимо и будут обновляться только когда изменится та ячейка от которой они зависят и не будет такого как в редаксе - проход в цикле и вызов mapStateToProps на всех подключенных к общему стору компонентов. А для того чтобы не было лишних вычислений зависимых мемоизированных computed-декоратором функций тут как раз таки и может подойти топологическая сортировка по глубине при вызове подписчиков но только это не самый оптимальный алгоритм - есть более эффективный алгоритм которого я описал в этой статье https://habrahabr.ru/post/349022

Интересно почему? - насколько я знаю в mobx используется самый оптимальный алгоритм. Mobx можно представить как 2д-редакс - из-за того что mobx observable-декоратором создает по redux-стору (обзервабл-объекту) на каждое после-ячейку состояния приложения то компоненты могут подписываться на эти ячейки независимо и будут обновляться только когда изменится та ячейка от которой они зависят и не будет такого как в редаксе - проход в цикле и вызов mapStateToProps на всех подключенных к общему стору компонентов. А для того чтобы не было лишних вычислений зависимых мемоизированных computed-декоратором функций тут как раз таки и может подойти топологическая сортировка по глубине при вызове подписчиков но только это не самый оптимальный алгоритм - есть более эффективный алгоритм которого я описал в этой статье https://habrahabr.ru/post/349022

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

Ну ок, тут я соглашусь - mobx действительно не эталон потому что автор раздул его до трех с половиной тысяч строчек кода в которых сложно разобраться и добавил кучу ненужны хелперов. То тем не менее алгоритм там реализован правильно, а разные хелперы можно и не использовать. А этот алгоритм, основную идею, реализацию и весь механизм обновлений mobx можно вместить в 85 строчек кода (и в той статье есть эта реализация) и легко понять как mobx работает

да он не про то что сорцы сложно читать

кто вообще сорцы читает

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

опять мобикс

Интересно почему? - насколько я знаю в mobx используется самый оптимальный алгоритм. Mobx можно представить как 2д-редакс - из-за того что mobx observable-декоратором создает по redux-стору (обзервабл-объекту) на каждое после-ячейку состояния приложения то компоненты могут подписываться на эти ячейки независимо и будут обновляться только когда изменится та ячейка от которой они зависят и не будет такого как в редаксе - проход в цикле и вызов mapStateToProps на всех подключенных к общему стору компонентов. А для того чтобы не было лишних вычислений зависимых мемоизированных computed-декоратором функций тут как раз таки и может подойти топологическая сортировка по глубине при вызове подписчиков но только это не самый оптимальный алгоритм - есть более эффективный алгоритм которого я описал в этой статье https://habrahabr.ru/post/349022

лол там чувак из мол

ну так винтаж довольно популярен

почему никто не берет cyclejs? 100 строк кода ядра, остальное потоковые библиотеки (RxJs), простой VDOM не медленне чем react уж точно

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

почему никто не берет cyclejs? 100 строк кода ядра, остальное потоковые библиотеки (RxJs), простой VDOM не медленне чем react уж точно

потому что стримы невозможно дебажить

не обоснованно) что сложно там? фукнциональный код в принципе сложнее "дебажить" чем императив

потому что стримы невозможно дебажить

console.log не понятно когда вызвался, да

не обоснованно) что сложно там? фукнциональный код в принципе сложнее "дебажить" чем императив

эта конфа раньше была про cycle.js

как видишь...

началось

)

Еее

Здравствуйте, это чат по аниме?