1. Ещё раз повторяюсь, это не инпут, это обертка, внутри которой в том числе лежит инпут.
2. Нет, т.к. это просто обертка, подставил туда другой инпут и все.
3. Это обертка
Вообще не понимаю чего вы из тривиальной задачи делаете проблему, в React + MobX есть все инструменты чтобы сделать максимально круто и в различных исполнениях.
Так у вас инпут отвечает за вывод ошибок, а надо наоборот
С чего это вдруг должно быть наоборот?? Компонент инпута формы (точнее обертка для простого <input />) для того и компонент, что может показать ошибку, если его не корректно заполнили, так вообще-то правильно, и должно быть именно так.
Большая проблема MobX, это оборачивание в Proxy для реализации observable, собственно это ещё грозит потерями ссылок, в итоге объекты уже не сравнить по ссылкам после MobX.
Вот как бы и всё, о какой ещё потери ссылок вы говорите? Вы должны работать с someStore.items.
Если уже и смотреть, то лучше в сторону MST (MobX State Tree), он не оборачивает в Proxy, но требует строгого описание типов, что на деле другая, совсем не маленькая проблема.
Ну уж нет, MST это убожество, тем более если речь идет о производительности, то у MST она самая худшая.
Почему в нашем случае MobX не подойдёт, у нас хранятся таблицы, временами на сотни тысяч строк, если это ещё заворачивать в Proxy, аааа, будет кошмар, оно и без этого сильно тормозит при обработке таблиц. В нашем случае иммутабельность даже является спасением.
1) Хоть на миллион, с чего вдруг они все должны быть разом добавлены в DOM дерево, если пользователь их не видит глазами, пока не начнет скролить?
2) Да вы можете вообще без стейт менеджеров обойтись и будет у вас максимум производительности. Вот наводка и рабочий пример, вообще без стейт менеджеров и на любой объем данных: codesandbox.io/s/adoring-nightingale-5m227?file=/src/App.tsx
Суть приема думаю ясна.
В нашем случае иммутабельность даже является спасением.
Иммутабельность всегда медленее мутабильности и прожорлевее по памяти, сейчас речь не о MobX, а вообще в целом.
Ну давай, расскажи, как же готовить Redux для работы с древовидными данными? Когда конечное приложение — дерево.
Как минимум не использовать Redux. Вообще в приложениях любого типа его нельзя использовать, но с другой стороны если хочется ныть как все плохо, то используйте конечно.
Я конечно понимаю, если взять MobX, то больше не будет проблем и жизнь станет легка и непринужденна, но ведь тогда не получится ныть и искать адовые пути решения элементарных задач.
Вот к примеру ваша, абсолютно элементарная «проблема» — древовидная структура данных, и что? Где проблема-то? Mobx просто создан для этого. Посмотрите на досуге что такое javascript Proxy, уже древняя штука по меркам 2021 года.
state.cars[0].passangers[4].name = 'new name'; и все, перендерится только один конпонент, вот прям только тот, который читает «name» у объекта этого пассажира.
Но нет же, это же так легко и просто, вы лучше пройдете адовый путь впаре с RxJS и/или Effector'ом и заодно разорите работодателя, заведомо обреча код проекта на провал и полное переписывание с нуля.
И уж MobX не надо тут рекламировать, я понимаю, он вам нравится, но минусов у него достаточно.
Какие минусы? Перечислите пожалуйста, и желательно реальные минусы, а не бред сивой кобылы или джунов которые что-то где-то прочитали/увидели и решили что раз так написали, значит это не просто так и действительно так оно и есть.
Например периодически встречаю псевдо «минус» — «он мутабильный», смешно и абсурдно конечно, но реально кто-то так думает.
Вообще в нашей архитектуре куда лучше подойдёт RxJS, хотя смотрим сейчас на Effector и потихоньку рефакторим приложение
Сочувствую, боль, разочарование и кандидат номер один на полное переписывание с нуля из-за невозможности дальнейшего развития/поддержки будущего «чуда», а так же невозможность нанять адекватных разработчиков т.к. разумеется с такой белебердой никто иметь дел не будет.
P.S. выше вы писали:
изначально я не хотел выбирать React + Redux для этой задачи, но сверху сказали.
Что я могу сказать, прогибаться и потом страдать, при том что сразу же знаешь наперед что будешь страдать, так себе жизненная позиция… Вы сами себя так поставили и на этом месте работы на вас будут ездить.
У меня например все просто, как только приходит какой-то неадекватный ультиматум или проект на котором я «должен теперь работать» «сверху», я просто перехожу на другую работу. Зачем страдать если можно не страдать? Благо предложений на рынке завались. Другое дело если бы у вас была такая профессия где предложений нет вообще, то от безисходности придется потерпеть т.к. тут уже вопрос умереть с голоду или нет)
делая правильные зависимости через DI, по всем канонам.
О ужас, DI во фронтенде редкостная дичь. Ещё и расписали это как «правильное» и «по всем канонам», хахах,
Возможно для тех, кто любим тебе усложнять жизнь на ровном месте да, им подойдет эта дичь и не только, надо идти глубже и брать ещё и Redux и т.п. для полного «кайфа».
Все правильно, я тоже использую MobX ещё с 2016 года. Благо мазахизмом не страдаю и с Redux слез при первой же возможности и больше никогда к нему не возвращался и не вернусь ни за какие кавришки)
Самый большой плюс Angular — на нем сложнее говнокодить.
Так это потому что там весь код со старта говно, поэтому на этом фоне вам кажется что уже особо хуже вы не пишете. К сожалению обычная иллюзия и не более.
Такая же иллюзия есть и с реаком, 99% проектов на связке React + Redux, так же старта уже говно, поэтому люди плодят говно дальше т.к. на фоне остального когда то, что они пишут особо не выделяется, плюс можно по тупому конечно оправдываться, ссылаясь на то, что в пример redux'a такой код и т.п., но конечно очень сложно подумать своей головой и понять, что код в промерах Redux'a как бы и есть говно. Но это очень сложно для обычных разработчиков.
О боже, всё ясно, удачи. Хотите пройти путь через говно, боль и страдания, пожалуйста. Не хотите срезать дорогу и выйти сразу к правильной, пожалуйста.
import { cloneDepp } from 'lodash';
import { toJS} from 'mobx';
lalala.push(cloneDeep(toJS(yourState)));
// Или
function pushToHistory(state) {
lalala.push(cloneDeep(toJS(state)));
}
pushToHistory(yourState);
Вы запушите в массив полную честную копию состояния
Нет, то, что в этой статье мне не нравится от слова совсем. Подход усложнять все элементарное на ровном месте и делать все сразу максимально универсальным и на все случаи жизни я призираю. Более того автор ссылается на каких-то других разработчиков(можно например посмотреть в комментариях выше) как на пример для подражания — это вообще смешно и абсурдно, ведь есть же своя голова на плечах.
Меня удивило что вы говорите " с Redux-thunk жить как-то проще.".
Серьезно?) Вы не знаете?) MobX разумеется ваше лекарство (и моё тоже).
2. Нет, т.к. это просто обертка, подставил туда другой инпут и все.
3. Это обертка
Что сводится к
вот условно в таком духе.
Вообще не понимаю чего вы из тривиальной задачи делаете проблему, в React + MobX есть все инструменты чтобы сделать максимально круто и в различных исполнениях.
С чего это вдруг должно быть наоборот?? Компонент инпута формы (точнее обертка для простого <input />) для того и компонент, что может показать ошибку, если его не корректно заполнили, так вообще-то правильно, и должно быть именно так.
Вот как бы и всё, о какой ещё потери ссылок вы говорите? Вы должны работать с someStore.items.
Ну уж нет, MST это убожество, тем более если речь идет о производительности, то у MST она самая худшая.
1) Хоть на миллион, с чего вдруг они все должны быть разом добавлены в DOM дерево, если пользователь их не видит глазами, пока не начнет скролить?
2) Да вы можете вообще без стейт менеджеров обойтись и будет у вас максимум производительности. Вот наводка и рабочий пример, вообще без стейт менеджеров и на любой объем данных: codesandbox.io/s/adoring-nightingale-5m227?file=/src/App.tsx
Суть приема думаю ясна.
Иммутабельность всегда медленее мутабильности и прожорлевее по памяти, сейчас речь не о MobX, а вообще в целом.
Как минимум не использовать Redux. Вообще в приложениях любого типа его нельзя использовать, но с другой стороны если хочется ныть как все плохо, то используйте конечно.
Я конечно понимаю, если взять MobX, то больше не будет проблем и жизнь станет легка и непринужденна, но ведь тогда не получится ныть и искать адовые пути решения элементарных задач.
Вот к примеру ваша, абсолютно элементарная «проблема» — древовидная структура данных, и что? Где проблема-то? Mobx просто создан для этого. Посмотрите на досуге что такое javascript Proxy, уже древняя штука по меркам 2021 года.
state.cars[0].passangers[4].name = 'new name'; и все, перендерится только один конпонент, вот прям только тот, который читает «name» у объекта этого пассажира.
Но нет же, это же так легко и просто, вы лучше пройдете адовый путь впаре с RxJS и/или Effector'ом и заодно разорите работодателя, заведомо обреча код проекта на провал и полное переписывание с нуля.
Какие минусы? Перечислите пожалуйста, и желательно реальные минусы, а не бред сивой кобылы или джунов которые что-то где-то прочитали/увидели и решили что раз так написали, значит это не просто так и действительно так оно и есть.
Например периодически встречаю псевдо «минус» — «он мутабильный», смешно и абсурдно конечно, но реально кто-то так думает.
Сочувствую, боль, разочарование и кандидат номер один на полное переписывание с нуля из-за невозможности дальнейшего развития/поддержки будущего «чуда», а так же невозможность нанять адекватных разработчиков т.к. разумеется с такой белебердой никто иметь дел не будет.
P.S. выше вы писали:
Что я могу сказать, прогибаться и потом страдать, при том что сразу же знаешь наперед что будешь страдать, так себе жизненная позиция… Вы сами себя так поставили и на этом месте работы на вас будут ездить.
У меня например все просто, как только приходит какой-то неадекватный ультиматум или проект на котором я «должен теперь работать» «сверху», я просто перехожу на другую работу. Зачем страдать если можно не страдать? Благо предложений на рынке завались. Другое дело если бы у вас была такая профессия где предложений нет вообще, то от безисходности придется потерпеть т.к. тут уже вопрос умереть с голоду или нет)
О ужас, DI во фронтенде редкостная дичь. Ещё и расписали это как «правильное» и «по всем канонам», хахах,
Возможно для тех, кто любим тебе усложнять жизнь на ровном месте да, им подойдет эта дичь и не только, надо идти глубже и брать ещё и Redux и т.п. для полного «кайфа».
Так это потому что там весь код со старта говно, поэтому на этом фоне вам кажется что уже особо хуже вы не пишете. К сожалению обычная иллюзия и не более.
Такая же иллюзия есть и с реаком, 99% проектов на связке React + Redux, так же старта уже говно, поэтому люди плодят говно дальше т.к. на фоне остального когда то, что они пишут особо не выделяется, плюс можно по тупому конечно оправдываться, ссылаясь на то, что в пример redux'a такой код и т.п., но конечно очень сложно подумать своей головой и понять, что код в промерах Redux'a как бы и есть говно. Но это очень сложно для обычных разработчиков.
Вы запушите в массив полную честную копию состояния
Нет, то, что в этой статье мне не нравится от слова совсем. Подход усложнять все элементарное на ровном месте и делать все сразу максимально универсальным и на все случаи жизни я призираю. Более того автор ссылается на каких-то других разработчиков(можно например посмотреть в комментариях выше) как на пример для подражания — это вообще смешно и абсурдно, ведь есть же своя голова на плечах.
Меня удивило что вы говорите " с Redux-thunk жить как-то проще.".