2017-02-07 3 views
2

Этот вопрос касается проектирования магазинов ngrx.Проектирование магазина ngrx для шкалы

У меня есть тип станции и подстанции. когда подстанция расширяется на основном экране, я показываю ее подстанции, и ТОЛЬКО одна станция может быть расширена за раз.

Так думать о том, что я делаю мое приложение состояние как

export interface AppState { 
    public stations: { [id: string] : Station }; 
    public selectedStation: string; 
    public substations: { [id: string] : SubStation }; 
} 

Так в основном каждый раз, когда selectedStation изменяется так же подстанции через действие нагрузки, которая сбрасывает данные из индексированных. НО, тогда я получаю требование переместить подстанцию ​​на другую станцию, для которой требуется загрузить целевые подстанции станции; Теперь проще всего сделать, это добавить в

public targetSubstations: { [id: string] : SubStation }; 

но это кажется неправильным и не кажется, хорошо масштабируется, что, если нужно загрузить 4 комплектов подстанций? Затем я продолжаю добавлять targetSubstations1...4?

Альтернативный я думал только о том,

type SubstationHierarchy = { 
    [stationId: string]: { 
    [substationId: string]: Substation 
    } 
} 
public substations: SubstationHierarchy; 

Это, кажется, хорошо масштабируется, но мое беспокойство здесь является то, что ПОКА нам не нужно загружать все подстанции за станции сразу это будет сделано, когда пользователь каждый раз расширяет новую станцию. Таким образом, иерархия будет ТОЛЬКО расти и не уменьшаться.

Помня о том, что я не проводил ни одного надлежащего стресс-тестирования того, сколько памяти может быть использовано магазином ngrx, и я разрабатываю для мобильных устройств, что было бы самым рекомендуемым при разработке магазина.

Редактировать

Поэтому мы используем pouchdb для асинхронной синхронизации данных с индексированной, вы можете думать об этом, как WebSocket для IndexedDB соединения.

Для НАЧАЛЬНЫХ требований В одной станции есть много подстанций. Пользователь может просматривать только одну станцию ​​(и это подстанции) в то время, на главном экране

Основываясь на этой I структуре мой AppState как этот

export interface AppState { 
    public stations: { [id: string] : Station }; 
    public selectedStation: string; 
    public substations: { [id: string] : SubStation }; 
} 

Где каждый раз, когда selectedStation меняется Я также меняю подстанции для станции THAT. Это работает отлично для большинства случаев.

Проблема возникает, когда пользователь загружает отдельный экран (а не главный экран, скажем, модальный), в котором он может переместить подстанцию ​​из selectedStation на целевую станцию.

Так что я мог изменить appstate к

export interface AppState { 
    public stations: { [id: string] : Station }; 
    public selectedStation: string; 
    public substations: { [id: string] : SubStation }; 
    public targetStation: string; 
    public targetSubstations: { [id: string] : SubStation }; 
} 

теперь, что если мне нужно, чтобы подстанция быть скопирована в двух отдельных целей, это потребовало бы мне делать что-то вдоль линий

export interface AppState { 
    public stations: { [id: string] : Station }; 
    public selectedStation: string; 
    public substations: { [id: string] : SubStation }; 
    public target1Station: string; 
    public target1Substations: { [id: string] : SubStation }; 
    public target2Station: string; 
    public target2Substations: { [id: string] : SubStation }; 
} 

Один из вариантов я думал был структурирование substations как этого

type SubstationHierarchy = { 
    [stationId: string]: { 
    [substationId: string]: Substation 
    } 
} 

export interface AppState { 
    public stations: { [id: string] : Station }; 
    public selectedStation: string; 
    public substations: SubstationHierarchy; 
} 

Теперь я могу хранить несколько подстанций для нескольких станций. Единственная проблема заключается в том, что я разрабатываю для мобильных устройств, а метод PREVIOUS с target1, target2 приведет к уменьшению объема памяти. Я заменяю подстанции, target1Substations ... каждый раз, когда нажимается другая станция и т. Д. Однако в новая структура Я не удаляю никаких данных в иерархии подстанций.

+0

Это почти невозможно дать рекомендацию __useful__ о том, как структурировать свой магазин без зная все требования и способы отображения данных - в этом есть так много переменных: сколько станций/подстанций будет для пользователя? Как часто изменяются данные/должны ли данные быть переназначены каждый раз, когда они отображаются? Вы упомянули _indexedDB_, означает ли это, что данные просто хранятся локально, и даже нет соединения с сервером? Какие операции должны выполняться для каждой модели? Просто имя __few__ факторов, которые все должны учитывать. – olsn

+0

Не зная об этом, вам, вероятно, лучше всего взглянуть на пример ngrx-example-app и то, как они структурируют свой магазин, у них есть немало хороших практик, которые можно использовать и во многих других проектах: https: //github.com/ngrx/example-app – olsn

+0

Итак, я редактировал исходный вопрос, надеюсь, более понятным образом. Кроме того, что касается indexeddb, я фактически использую pouchdb, который асинхронно синхронизирует данные прозрачно. Поэтому, если кто-то изменит данные на бэкэнд, он будет синхронизирован с клиентом. ГДЕ, если мне нужно будет поместить их в магазин. – MilindaD

ответ

0

Что я сделал для сценария, в котором у вас есть зависимые данные, чтобы нормализовать его. Вы можете использовать библиотеку, например normalizr, если это помогает, но в основном вы пытаетесь сгладить данные, а затем потяните их вместе с селекторами, когда вам это нужно.

Я хотел бы сделать что-то вроде:

export interface AppState { 
    public stations: { [id: string] : Station }; // all stations 
    public selectedStation: string; 
    public substations: { [id: string] : SubStation }; // all substations 
} 

Где Станция:

export class Station { 
    id: string; 
    ... 
    subStationIds?: string[]; 
} 

Затем, когда вам нужно загрузить станцию, можно использовать селектор, чтобы объединить станцию ​​с ее подстанциями и в этот момент загрузите SubStations в магазине, если их там нет.

Когда дело доходит до IndexedDB и производительности, я думаю, что это будет зависеть от того, насколько велик ваш набор данных, сколько вы кэшировать и т.д.

Смежные вопросы