Привет, было бы интересно про Apollo - как правильно хранить данные, кешировать, как сделать аналог useSelector. Так как в доке не достаточно ясны эти моменты. Спасибо!)
Спасибо за видео. Но, КМК, Redux Toolkit (без RTK Query) всего лишь синтаксический сахар над Redux и не меняет изначальной парадигмы Redux'а, а MST привносит совершенно другой подход (имутабельность, сингл-стору и др.) отличный от чистого MobX, поэтому считаю что чистый MobX нужно сравнивать как раз с Redux Toolkit (так как в 2021 никто в здравом уме не будет писать на чистом Redux).
Не вижу смысла сравнивать только обертку над Redux в виде иммера и пары функций. Сравнивать есть смысл с RTK и его кодогенерацией. MST не привносит иммутабельность и другого нового тоже ничего не даёт. Он устанавливает связи между классами, что мы можем сделать и в mobx (и делаем в большинстве случаев), а так же набор функций для удобного доступа по вторам этого дерева.
@@wisejs В том и дело, что в этом видео куча однотипного кода в redux примере. И может сложиться мнение, что редакс мега-избыточный (так оно и есть, если писать на чистом редаксе, но в 2021 так никто не пишет). Зачем это "видеть" новичкам (а я так понимаю видео как раз для них)? Даже со-мейнтейнер redux говорит/пишет везде о том, что начинать знакомство нужно именно с тулкита и это сейчас единственный "тру-вей". ИМХО, MST выглядит для меня избыточным и убивает всю гибкость mobx'а, поэтому чистый mobx мне нравиться больше.
Фильтровать данные после удаления из БД я бы не стал. Надо делать fetch из БД. Параллельно могут удалять записи другие пользователи, пока ваш список висит на экране.
list должен быть observable.shallow потому что сам post отслеживает свои значения. Еще не учтен момент с показом лоадера при загрузке данных. Еще биндить не нужно, иначе наследоваться нельзя будет. Мне Мобх очень нравится, очень гибкий и из-за этого многим он не нравится.
observable.shallow более подходит, но и использовавшийся observable.deep отработает точно так же - не станет лезть внутрь постов, потому как у них кастомный класс (кастомный прототип)
Немного не понял... А почему в конце редактируемые данные не меняются на сервере? По идее при редактировании данные поста должны загрузиться обратно в форму и из нее обновиться в базе....
Печальное видео. Не нужно сравнивать библиотеки для управления клиентским состоянием на примере где этого состояния нет. Новички потом так и будут делать, не понимая в чем разница между клиентским состоянием и серверные кэшем
@@wisejs Потому что так это является обычным классом, инстанс которого мы экспортируем. Мы все так же можем сделать новый экземпляр тем самым перезаписав данные в нем. А синглтон по определению, это класс экземпляр которого может быть всего один. Мне кажется вы немного напутали причину и следствие. При определенных обстоятельствах - работает так же, но это не делает из гриба грибной суп
@@artempronenko5105 Каким образом мы создадим новый инстанс, если класс сам собой не экспортируется? А из модуля (коим является файл) экспортируется только инстанс! Вот он и синглтон.
@@wisejs Еще раз. Проблема в том, что мы можем создавать экземпляры класса, по этому класс не может быть синглтоном... То что вы сделали, это просто экспорт инстанса. Я согласен с тем что это бюудет работать как синглтон при опредленных условиях, но это не делает класс синглтоном)
