да где угодно на самом деле

“Логика где угодно” - звучит хорошо

(нет)

Логика в сторе

А как там что-то типа мидлвары сделать ?

“Логика где угодно” - звучит хорошо

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

там батчинг бесплатный

Угу стараюсь так делать

А если надо где-то в другом сторе поменять ? То инжектить в компонент несколько сторов ?

Ну да, проблем нет.

ну как-то выглядит не очень удобно

если мне надо выполнить цепочку екшонов на какой-то кнопке

и эту же цепочку екшонов

где-то еще

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

Вот я лишь не вдуплил, на какой магии работает MobX. С Редуксом все понятно, это object.assign. А тут что? Простые объекты превращаются в объекты с геттерами-сеттерами, которые видимо и хукаются самим мобксом?

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

и строит граф зависимостей

как во вью жс

оборачивает сеттеры и геттеры

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

в ф-ю просто оборачиваешь. Сторов в мобксе как в редуксе нет, там все всегда реактивное

Где то был у Вестрйета видос

где он объясняет как оно работает

ща поищу

Прошло уже несколько лет, странно почему больше народу не пользуются мобксом

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

Прошло уже несколько лет, странно почему больше народу не пользуются мобксом

https://www.youtube.com/watch?v=TfxfRkNCnmk

Он появился раньше афаик

https://www.youtube.com/watch?v=TfxfRkNCnmk

зал прям ломится от зрителей

что думаете про webpack-blocks ? https://github.com/andywer/webpack-blocks

зал прям ломится от зрителей

И вообще, обзервабл звучит как выблювал

И вообще, обзервабл звучит как выблювал

юзерам rx сейчас должно быть обидно

как?! мутирует, создаё1т 100500 стэйтов, недопиленный и вообще не понятно зачем он нужен? да и обсёрвабл. звучит как выблювал

Да вот же все аргументы против mobx, чо вы

Но мобикс мутирует. Не, не так. МУТИРУЕТ

Абрамов не одобряе

Абрамов написал?

Похоже на него :3

Абрамов написал?

альберт эйнштейн

Абрамов написал?

Аккорды или табы есть?

imagine джона леннона же

Можно и под йестердей пропеть кстати

Ой, смотрю на мобх. Вроде бы прикольно, но что-то не то.

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

Можно сделать стор, внутри которого будут заинжекчены другие сторы, внутри которого будет вся логика, связанная с их композицией (только логика, без хранения), и всё, инжекти только его одного

https://github.com/mass3ff3ct/mobx-react-inject Вот товарищ кстати написал инжектилку для мобикса и реакта

Используем у себя, супер выходит

Инжектишь в проперти класса компонента и оно просто работает

А, ну смысл есть только с typescript, он там метаданные активно использует

А что делаете с мобх ?

А что делаете с мобх ?

Новую версию http://megaplan.ru

Кстати начинали с редаксом. Осознанно перешли на mobx. Отсутствие необходимости нормализовать/денормализовать данные от бека, производительность из коробки, куча возможностей для доп оптимизаций.

ДЛя себя решили только одно - не используем внутреннюю магию, типа observe, reaction и так далее

Кстати начинали с редаксом. Осознанно перешли на mobx. Отсутствие необходимости нормализовать/денормализовать данные от бека, производительность из коробки, куча возможностей для доп оптимизаций.

Больше мемоизированные селекторы не беспокоят?

Больше мемоизированные селекторы не беспокоят?

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

>reaction но ведь это основа mobx-react в чём проблема?

>reaction но ведь это основа mobx-react в чём проблема?

Да, и мы используем в юзер-ленд коде только observer, computed, observable. Если этого не хватает значит разработчик пытается сделать что-то сложное, и он должен подумать как это можно упростить

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

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

Кстати с редаксом появляется целый класс проблем - как переиспользовать один и тот же компонент в разных местах кода. Как писать компоненты, которые могут появляться в разных местах страницы одновременно (например супер крутой умный селектор данных, который и на бек сходит, и в кеш положит, и в локалсторейдж при необходимости)

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

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

Может конечно, и, возможно, для прототипа это и нормально. Зато когда появится необходимость вынести стейт выше (то, что называется lifting state up), легко выделяется класс с логикой и всё.

Кстати с редаксом появляется целый класс проблем - как переиспользовать один и тот же компонент в разных местах кода. Как писать компоненты, которые могут появляться в разных местах страницы одновременно (например супер крутой умный селектор данных, который и на бек сходит, и в кеш положит, и в локалсторейдж при необходимости)

А зачем такое надо??

Новую версию http://megaplan.ru

а SSR делаете?

Реакт - это отображение, а не логика.

а SSR делаете?

Пока нет, но в планах есть

Я вообще стараюсь все компоненты имутабельными делать, чтобы мороки меньше было.

ERROR: S client not available

Реакт - это отображение, а не логика.

В реальных приложениях хочется компонент, которому скажешь: хочу вот здесь автокомплит с сотрудниками (реальный кейз), а дальше он сам.

Этот спор по прежнему сводится к ооп vs фп. Каждый хвалит инструмент думая о тех возможностях, что он добавляет в его воркфлоу

В реальных приложениях хочется компонент, которому скажешь: хочу вот здесь автокомплит с сотрудниками (реальный кейз), а дальше он сам.

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

Естественно, собеседник в этот момент идеальную картину представляет себе совершенно иначе

Этот спор по прежнему сводится к ооп vs фп. Каждый хвалит инструмент думая о тех возможностях, что он добавляет в его воркфлоу

А истина как всегда посередине

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

На самом деле нужна: автокомплит и в кеш пойдёт, и на бек если кеша нет, и так далее

На самом деле нужна: автокомплит и в кеш пойдёт, и на бек если кеша нет, и так далее

И поиск на беке выполнит когда юзер вводит данные в него, а может и в кеше сначала поищет

На самом деле нужна: автокомплит и в кеш пойдёт, и на бек если кеша нет, и так далее

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

А в компоненте страницы это выглядит просто как: <EmployeeAutocomplete value={} onChange={} />

А истина как всегда посередине

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

Ну, такая простота фатальна, имхо.

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

Зачем её каждый раз передавать когда можно не передавать? Тут ещё такой момент - данный компонент, который я описываю, он не занимается отображением. Конечно внутри он использует некий <Select />, который уже иммутабельный, и работает только с пропсами

Слои абстракции

Зачем её каждый раз передавать когда можно не передавать? Тут ещё такой момент - данный компонент, который я описываю, он не занимается отображением. Конечно внутри он использует некий <Select />, который уже иммутабельный, и работает только с пропсами

Ну выбирай. Или тебе универсальный компонент или вытаскивай логику наружу)

Но вот такие "панели", из которых соибрается приложение, у нас есть, и с редаксом возникала проблема - как разделять их стейты, приходилось вводить идентификаторы, зубодробительные редусеры с фиксацией айдишника и так далее

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

Вопрос: клиент тянет данные из апи соц. графа - юзернайм, ид, имя и еще 100 параметров. Есть какая проверенная либа для кеширования уже зарезолвленных? Можно и lru-cache, но хотелось бы что-то интегрированное с mobx например

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

Так я и сделал обёртку. Но у обёртки получился стейт (то что пользователь ввёл в поиск как минимум), и с редаксом некомфортно иметь одновременно несколько таких видимых обёрток

Так я и сделал обёртку. Но у обёртки получился стейт (то что пользователь ввёл в поиск как минимум), и с редаксом некомфортно иметь одновременно несколько таких видимых обёрток

А в чём неудобство?

Но вот такие "панели", из которых соибрается приложение, у нас есть, и с редаксом возникала проблема - как разделять их стейты, приходилось вводить идентификаторы, зубодробительные редусеры с фиксацией айдишника и так далее

Ну откровенно говоря вы юзали инструмент не той стороной)) Редакс работает в орьатную сторону, добавляя возможностей для composition, убирая Inheritance

Вопрос: клиент тянет данные из апи соц. графа - юзернайм, ид, имя и еще 100 параметров. Есть какая проверенная либа для кеширования уже зарезолвленных? Можно и lru-cache, но хотелось бы что-то интегрированное с mobx например

apollo ))

Вопрос: клиент тянет данные из апи соц. графа - юзернайм, ид, имя и еще 100 параметров. Есть какая проверенная либа для кеширования уже зарезолвленных? Можно и lru-cache, но хотелось бы что-то интегрированное с mobx например

Ну и там кеширование заказов, инфо о продукте и так дале

А в чём неудобство?

Ну вот у тебя есть 2 автокомплита, каждый из которых - инстанс одного и того же компонента, но они в разных состояниях - какой-то откыт, какой-то нет, в каком то запрос на бек начался, и так далее. Очевидно что стейты у них разные. Вопрос: как именно разрулить это с редаксом?

Точнее, скорее это неизбежно — для вашей команды редакс однозначно развернут поперек)

apollo ))

не не для graphql а просто REST

Точнее, скорее это неизбежно — для вашей команды редакс однозначно развернут поперек)

Ну вот сверху кейз, скажи как надо

Так чтохорошо когда у всех есть выбор ?

Ну вот у тебя есть 2 автокомплита, каждый из которых - инстанс одного и того же компонента, но они в разных состояниях - какой-то откыт, какой-то нет, в каком то запрос на бек начался, и так далее. Очевидно что стейты у них разные. Вопрос: как именно разрулить это с редаксом?

Сделай 2 обёртки и раздели стейт.

Ну вот сверху кейз, скажи как надо

Никак, юзать мобикс

Мой поинт в том, что вам редакс противопоказан и в этом нет ничего такого

Сделай 2 обёртки и раздели стейт.

То есть как только разработчику надо будет в форму добавить третье поле с автокомплитом, он должен сделать ещё одну обёртку, делить стейт, и так далее

Сейчас разработчик просто такой: <EmployeeAutocomplete value={} onChange={} /> и всё