Для этого и придумали - чтобы отслеживать явное присвоение значения свойству value и ничего кроме этого
Меняться будет только весь список целиком, а не ключи каждого товара
прмименил бы ref, т.к. с большой вероятностью нужно отслеживать изменения на всем уровне вложенности
Я не знаю всей задачи, и предположил, что отдельные свойства элементов массивов могут меняться независимо от получения данных с сервера. В моей практике такое встречалось часто.
(Пример - в списке товаров приходит базовая цена, но при заказе нескольких экземпляров к ней должна применяться скидка. Хотя глупый пример получился. Ладно, у меня рабочий день закончился. Спасибо за дискуссию)
А каким образом все живое живо до сих пор, если в клетке есть предел количеств делений? Половые клетки же тоже не с нуля берутся, а точно так же в результате деления
Да и раньше нормальные (а другие я не использовал) фреймворки и библиотеки имели подробную документацию с примерами реального использования. И для минимального запуска достаточно было скопипастить их к себе в проект в нужное место.
Сейчас это делает llm-ка.
Только вот до реального продукта далеко в обоих вариантах.
Единствнный вопрос - вы бы для этой переменной типа Map использовали ref или shallowRef? И вообще в сторах вы списки и объекты в каком виде храните - в виде ref или shallowRef?
Для этой задачи прмименил бы ref, т.к. с большой вероятностью нужно отслеживать изменения на всем уровне вложенности
А так, смотря что требуется. Иногда достаточно shallowRef, если меняется весь объект целиком, а не отдельные поля (элементы массива)
Я бы не делал отдельный стор для каждой сущности. Собственно, я изначально это и имел в виду, как преимущество единого стора на все приложение (ну, как минимум для тесно связанных сущностей). В данном случае, навскидку, я бы сделал два: UserStore и ProductStore.
Соответственно, после аутентификации загружаем данные пользователя вместе с его историей заказов в userStore. Или изначально без истории заказов, но загружаем ее при первом обращении.
Точно так же создаем новый заказ, вызовом метода (экшна) у стора пользователя userStore.createOrder(productList);
Далее пришла задача получать не только основной список products и отображать его, но одновременно с этим отображать список поменьше - featured products.
Можно внутри productStore сделать переменную типа Map, где ключ - тип списка, а значение - собственно список. Тогда можно вообще не волноваться за появление/удаление вариантов списка товаров. Новый тип списка будет создан компонентом, нуждающемся в нем
Т.е. запрос для получения идет в сервис, а данные приходит из стора. Логичнее было бы Сервис откуда-то их берет (бэк, кэш, его дело) и отдает компоненту.
Пиление сука, на котором сидят пилящие его законотворцы, продолжается
Как можно удалить учетку после блокировки сервиса? Он же недоступен.
Убили волчицу, подобрали и вырастили волчат, нет?
Пусть и дальше экономит. Кто только будет пользоваться его услугами, если всех уволят?
И при крепостном праве жили и было хорошо. Некоторым
потому что будущее - за молодыми
Для этого и придумали - чтобы отслеживать явное присвоение значения свойству value и ничего кроме этого
Я не знаю всей задачи, и предположил, что отдельные свойства элементов массивов могут меняться независимо от получения данных с сервера. В моей практике такое встречалось часто.
(Пример - в списке товаров приходит базовая цена, но при заказе нескольких экземпляров к ней должна применяться скидка. Хотя глупый пример получился. Ладно, у меня рабочий день закончился. Спасибо за дискуссию)
А разве белые списки будут мешать прямым обращениям по IP внутри страны? Они же только для трансграничного трафика
По просьбам трудящихся подтверждение по смс будет отменено. Хватит и Мах :-D
(забыл, что надо /s обязательно писать - уже минус влепили)
Вот кстати это же отличная аналогия!
Почему то некоторые люди, включив автопилот тумблером, внезапно стали считать себя опытными пилотами международных линий
А сиамские близнецы имеют формально одно тело, а считаются двумя людьми.
(напоминаю, это спор не всерьез)
А каким образом все живое живо до сих пор, если в клетке есть предел количеств делений? Половые клетки же тоже не с нуля берутся, а точно так же в результате деления
А при использовании shallowRef я вообще никакие изменения не смогу отследить. Map создается вместе со store и более не меняется.
А списки то как раз будут меняться - при пагинации, смене фильтров на странице, и тому подобного
Что это и, главное, зачем?
Да и раньше нормальные (а другие я не использовал) фреймворки и библиотеки имели подробную документацию с примерами реального использования. И для минимального запуска достаточно было скопипастить их к себе в проект в нужное место.
Сейчас это делает llm-ка.
Только вот до реального продукта далеко в обоих вариантах.
Да сто раз уже об этом писали, вакансии висят как имитация развития компании, а на самом деле никого они не ищут, а то и сокращают имеющихся
Разница в том, что вайбкодер вообще не пишет код. Это разновидность менеджера, а не инженера
Многие в качестве хобби (и чтобы отвлечься от умственной работы) что-то делают именно руками. Столярка, металлообработка, и тп. Вполне себе вариант.
А вот продавцу шин скорее всего не нужны никакие отчеты помимо уже имеющихся "коробочных" в используемой им системе
А еще можно открыть курсы вайбкодинга )
Для этой задачи прмименил бы ref, т.к. с большой вероятностью нужно отслеживать изменения на всем уровне вложенности
А так, смотря что требуется. Иногда достаточно shallowRef, если меняется весь объект целиком, а не отдельные поля (элементы массива)
Я бы не делал отдельный стор для каждой сущности. Собственно, я изначально это и имел в виду, как преимущество единого стора на все приложение (ну, как минимум для тесно связанных сущностей). В данном случае, навскидку, я бы сделал два: UserStore и ProductStore.
Соответственно, после аутентификации загружаем данные пользователя вместе с его историей заказов в userStore. Или изначально без истории заказов, но загружаем ее при первом обращении.
Точно так же создаем новый заказ, вызовом метода (экшна) у стора пользователя userStore.createOrder(productList);
Можно внутри productStore сделать переменную типа Map, где ключ - тип списка, а значение - собственно список. Тогда можно вообще не волноваться за появление/удаление вариантов списка товаров. Новый тип списка будет создан компонентом, нуждающемся в нем
И эти данные потеряли реактивность