Но с появлением хуков, как мне кажется, все эти глобальные хранилища стали излишними. Функциональные компоненты и хуки способны решить большинство задач из коробки.
С помощью MobX это решается намного быстрее, проще, приятнее, гибче и красивее, про оптимизацию производительности из коробки я вообще молчу)
Поэтому у вас такие суждения, MobX делает из React'a вообще абсолютно другой инструмент, управление состоянием становиться эталонным. React это только лишь view слой и ничего больше.
Кстати, результат всё ещё не оптимален на больших массивах.
Ну когда речь именно о динамической фильтрации со всевозможными условиями, тем более на больших массивах абсолютно оптимальных результат быть и не может в принципе, тут нет ничего удивительного, только компромиссы.
Прекратите писать подобное! На этот код больно смотреть.
Без этого вы не додумались ни до чего сами.
Нормальный код должен выглядеть вот так:
Жаль что вы сами до всего этого не додумались изначально, пришлось вас к этому подталкивать раз за разом. В противном случае написали бы сразу рабочее решение и дело с концом.
Вот ваши слова
Но при изменении параметра, который участвует в фильтре, у пятого элемента массива вы будете заново проверять все остальные элементы, вот я к чему.
Причём если решить эту проблему, то получится сэкономить гораздо больше времени чем экономится от динамического нахождения зависимостей.
Взяли бы да и написали код сразу, и показали как надо, вместо если бы да кабы.
Мораль такая, можно разводить демогогию вокруг этой задачи долго, но факт таков — нечего сверх естественного в ней нет и если и правда есть нужда именно в таком поведении это можно реализовать, если не лень. Мне уже лень тут честно экономить на спичках)
Изначально писал с reaction, в итоге просто поленился вместо него в итоге autorun воткнуть, но сути это не меняет на работу задачи не влияет.
Э-э-э, нет, это как раз принципиально:
Вы ещё раз проверьте все, там все работает правильно и ровно так, как нужно да и реакции есть разумеется, не знаю почему вы думаете что их нет. Консоль логи для этого там пишутся. И для вас там специально написаны комментарии когда данные реально изменяются и когда нет, так вот когда они реально не изменяются никаких реакций нет и быть не должно.
Как бы вот:
только вот в итоге как раз жесть с промисами и получится
Я не вижу никакой жести в вашем прототипе, все читается сверху вниз и что делает предельно понятно и наглядно. Можно всё это оформить в классах вспомогательных и скрыть в них детали реализации.
из состояния есть фильтр и номер страницы;
при каждом изменении фильтра номер страницы должен сбрасываться в 1;
при каждом изменении фильтра и номера страницы надо делать два http-запроса для получения отображаемых данных (второй запрос использует данные первого);
слишком часто запросы делать нельзя, также надо отменять прошлые запросы если фильтр или номер страницы изменился.
Вы реализуйте по настоящему эту задачу на rx и скиньте ссылку на код в сэндбоксе, а вам реализуют эту задачу с MobX'ом или любитель $mol'a с $mol'ом.
И нет, ни тот ни другой вариант не являются эффективными, поскольку при любом изменении любого элемента массива происходит повторная фильтрация массива целиком.
Нет, не при любом изменении, любого элемента в массиве, а только если изменяются конкретно те параметры, которые участвуют в фильтре. Так всё же видно и проверки есть с console.log'ами.
Самый кайф что доступны вообще абсолютно все прелести и возможности языка, классы, функции, наследование, композиции и т.д. и т.п., никаких ограничений и рамок. Можно по настоящему делать крутые вещи.
Вы так говорите, как будто это какая-то проблема. Лично у меня 2 года работает эта штука в разных проектах и чувствует себя великолепно. Если вдруг произойдет немыслимое и оборачивание стороннего компонента в observer его сломает, и вот нужно именно его использовать, то можно зарегистрировать JSX фабрику кастомную и там это провернуть или добавить условие на проверку компонента по ссылке, и если его не надо заворачивать, то просто не заворачиваем, какие проблемы то?
Вы развели несуществующую «проблему» на ровном месте, смысл?
Я предпочитаю хороший и чистый код. Меня не волнует шанс 1 из миллиона, что что-то может пойти не так и ради этого шанса писать код более грязным.
Можно вообще из дома не выходить, а то вдруг кирпич на голову упадет, если до сих пор не упал, то это просто повезло и проканало из дома выйти да?)
Зачем манкипатчить реакт, потенциально ломая сторонние компоненты, если можно зарегистрировать кастомную jsx фабрику?
Если сторонний компонент сломается от HOC'a observer, то это похоже кривой компонент и я бы задумался о его использовании)
Я тоже патчил React.createElemnt схожим образом для того, чтобы автоматом все компоненты были observerver'ами, заодно автоматом заворачивал компоненты в ErrorBoundary чтобы вся страница не падала, а падал только конкретный компонент в котором возникла ошибка, и он показывал текст «Something went wrong».
Проблем не было ни разу с этим. в том числе со сторонним ant-design.
Пишешь чистый код и не думаешь об этих обертках, просто всё работает.
Страшно все же жить в мире, где каждые полгода мета меняется
Последние 4 года вообще без изменений, React + TS + MobX полет шикарный. Все максимально актуально, быстро и тп) А вообще с реактом уже 6 лет, первые 2 года с реактом были болью и страданиями из-за redux'a, но потом узнал что такое MobX и все как рукой сняло.
Не знаю что вы там учите каждые пол года)
С помощью MobX это решается намного быстрее, проще, приятнее, гибче и красивее, про оптимизацию производительности из коробки я вообще молчу)
Поэтому у вас такие суждения, MobX делает из React'a вообще абсолютно другой инструмент, управление состоянием становиться эталонным. React это только лишь view слой и ничего больше.
Ну когда речь именно о динамической фильтрации со всевозможными условиями, тем более на больших массивах абсолютно оптимальных результат быть и не может в принципе, тут нет ничего удивительного, только компромиссы.
Без этого вы не додумались ни до чего сами.
Жаль что вы сами до всего этого не додумались изначально, пришлось вас к этому подталкивать раз за разом. В противном случае написали бы сразу рабочее решение и дело с концом.
Вот ваши слова
Взяли бы да и написали код сразу, и показали как надо, вместо если бы да кабы.
Ну вот с явными обновлениями и с работающим autorun
stackblitz.com/edit/typescript-wgar48?file=index.ts
Мораль такая, можно разводить демогогию вокруг этой задачи долго, но факт таков — нечего сверх естественного в ней нет и если и правда есть нужда именно в таком поведении это можно реализовать, если не лень. Мне уже лень тут честно экономить на спичках)
Изначально писал с reaction, в итоге просто поленился вместо него в итоге autorun воткнуть, но сути это не меняет на работу задачи не влияет.
Вы ещё раз проверьте все, там все работает правильно и ровно так, как нужно да и реакции есть разумеется, не знаю почему вы думаете что их нет. Консоль логи для этого там пишутся. И для вас там специально написаны комментарии когда данные реально изменяются и когда нет, так вот когда они реально не изменяются никаких реакций нет и быть не должно.
Как бы вот:
Не надо, вырви глаз лапша не котируется и даже близко не стояла. Мы ведь говорим о человеческом коде(я надеюсь), а не write only одноразовых поделках.
Не надо, первый аргумент все равно каждый раз вызывается при изменении в нем данных.
Смотрите внимательнее, я же говорю, там все работает и все с проверками, все используется разумеется.
Он и не должен быть частью библиотеки.
Это было реализовано в других примерах) Да и смысл если эти данные нужны только по требованию.
Я не вижу никакой жести в вашем прототипе, все читается сверху вниз и что делает предельно понятно и наглядно. Можно всё это оформить в классах вспомогательных и скрыть в них детали реализации.
Вы реализуйте по настоящему эту задачу на rx и скиньте ссылку на код в сэндбоксе, а вам реализуют эту задачу с MobX'ом или любитель $mol'a с $mol'ом.
Если вы так настаиваете)) То вот решение — stackblitz.com/edit/typescript-zhgtnu?file=index.ts
теперь все кэшируется и только выполняется пересчет функции только для элемента который изменился.
Это понятно, чтобы сам алгоритм было видно. А так это в computed помещается и дело с концом — stackblitz.com/edit/typescript-y4hjir?file=index.ts
Нет, не при любом изменении, любого элемента в массиве, а только если изменяются конкретно те параметры, которые участвуют в фильтре. Так всё же видно и проверки есть с console.log'ами.
Я сделал ровно то, что нужно было в требованиях. И работает это именно так, как нужно.
С чего это по одному то? сколько угодно параметров засуньте в функцию фильтра и все будет работать.
Вот как как выглядит по настоящему работающее решение здорового человека, с проверками работоспособности и удовлетворяющие все требования задачи — stackblitz.com/edit/typescript-3huxim?file=index.ts
nin-jin
mayorovp
^
Если нет разницы, то зачем платить больше?
Вы развели несуществующую «проблему» на ровном месте, смысл?
Я предпочитаю хороший и чистый код. Меня не волнует шанс 1 из миллиона, что что-то может пойти не так и ради этого шанса писать код более грязным.
Можно вообще из дома не выходить, а то вдруг кирпич на голову упадет, если до сих пор не упал, то это просто повезло и проканало из дома выйти да?)
Если сторонний компонент сломается от HOC'a observer, то это похоже кривой компонент и я бы задумался о его использовании)
Я тоже патчил React.createElemnt схожим образом для того, чтобы автоматом все компоненты были observerver'ами, заодно автоматом заворачивал компоненты в ErrorBoundary чтобы вся страница не падала, а падал только конкретный компонент в котором возникла ошибка, и он показывал текст «Something went wrong».
Проблем не было ни разу с этим. в том числе со сторонним ant-design.
Пишешь чистый код и не думаешь об этих обертках, просто всё работает.
Спасибо за статью! Полезная информация!
Последние 4 года вообще без изменений, React + TS + MobX полет шикарный. Все максимально актуально, быстро и тп) А вообще с реактом уже 6 лет, первые 2 года с реактом были болью и страданиями из-за redux'a, но потом узнал что такое MobX и все как рукой сняло.
Не знаю что вы там учите каждые пол года)