К
подскажите по структуре проекта, плз ) Как лучше сторы хранить?
Size: a a a
2020 April 26
PM
ещё вопрос по структуре проекта. Сторы как удобнее хранить? Понятно, что тут вкусовщина, но мб какой-то принятый подход есть?
у меня все тупо разложено по папкам которые представляют из себя типы модулей
PM
actions
components
helpers
pages
views
stores
DB
а все просто, нужно мутировать объект и все сработает
Ну так значения в объекте поменялись переменной присвоил массив который в нём хранился этого для мутации разве не достаточно?
К
а внутри stores?
К
для каждого хранилища отдельный файл?
PM
для каждого хранилища отдельный файл?
по разному. скорее по смыслу. так как свелте сторы это атомик сторы, то я их стараюсь разбивать максимально мелко, но при этом использую иерархи/ файловой системы вместо иерархии объекта
PM
блин пример где-то давно писал уже, но могу и повторить
К
надо, мне кажется, отдельную статейку про это запилить )
PM
возьмем к примеру большой такой стор user
AY
actions
components
helpers
pages
views
stores
В чем разница между views и pages?
PM
а у него кроме самих данных юзера еще его товары, преференсы, карзина и тп
PM
в подходе single store, аля редакс, у нас будет один большой объект:
{
user: { email, name, phone, ... },
cart: {},
comments: [],
posts: []
....
}DB
заюзай .map со спредом тогда
PM
вподходе с атомик сторами все это разные сторы, но сущностью по сути одна. в этом случае я делаю так:
/stores/
/user/
user.js
cart.js
comments.js
posts.js
index.js
К
Denis Bazhenov
там выше тебе ссылку на опции кинули ) Скорее всего хватит просто 1 опцию поменять, чтобы свелт лез в объекты
К
либо ссылки на объекты в массиве замени. Просто новые объекты создай из текущих в массиве
PM
для удобвства внутри /stores/user/index.js просто реэкпорчу все содержимое и можно работать:
import { comments } from '@/stores/user';DB
там выше тебе ссылку на опции кинули ) Скорее всего хватит просто 1 опцию поменять, чтобы свелт лез в объекты
Спасибо - пойду ковыряться дальше.
PM
В чем разница между views и pages?
components - "глупые", переиспользуемые компоненты без бинес-логикиviews - конкретные блоки с конкретной имплементацией бинес-логики, то сути "умные" компонентыpages - страницы, если роутер требует именно связи роут => компонент, ну и в принципе если приложение логически разделено на страницы (не всегда так бывает)