Угловая архитектура: как управлять сохранением состояния с помощью нескольких HTTP-служб?

Мне было интересно, как вы должны структурировать приложение, которое обращается к бэкэнду.

Обертывание HTTP-вызовов в сервисе кажется естественным способом, но как / где вы храните данные для согласованности? Например, у меня есть компонент, который отображает какой-то список Todo, который извлекается из бэкэнда.OnInit. Теперь при маршрутизации от этого компонента и повторной маршрутизации все его данные сбрасываются. Конечно, вы можете снова вызвать бэкэнд, но не будет ли выгоднее хранить данные в каком-то сервисе (даже в HTTP-сервисе) для дальнейшего использования?

Чтобы уточнить:

class Service {

    storedData: number[] = []
    allObjects: BehaviorSubject<any> = new BehaviorSubject()

    ...


    getObj(id) {
        if (!this.storedData.includes(id)) {
            this.getDataFromServer(id)
        }
        return this.allObjects.pipe(
            map(objects => objects.find(obj => obj.id === id)),
            filter(obj  => obj && true)
        )
    }

    getDataFromServer(id) {
        return this.http.get(id).pipe(
            tap(obj => {
                this.storedData.push(id)
                this.allObjects.put(id, obj)
            })
        )
    }
}

Будет ли это жизнеспособным подходом или есть другие способы разрешения таких ситуаций?

Кроме того, как лучше всего использовать объект, которому требуется несколько служб для заполнения всех его полей. (Obj:{a: number, b: number}, a извлекается AService а также b по BService).

Где бы вы хранили эти объекты? AService в BService и хранить его в BService / внедрение обоих в третью службу, которая предоставляет данные запрашивающим компонентам)?

И как лучше всего его хранить?

Источник

2 ответа

Решение

Виктор Савкин, бывший член основной команды Angular в Google, создавший модули внедрения зависимостей, обнаружения изменений, форм и маршрутизатора, написал отличную статью об управлении состоянием в приложениях Angular.

Он выделил шесть общих типов состояний для веб-приложений:

  • Состояние сервера
  • Постоянное состояние
  • URL-адрес и состояние маршрутизатора
  • Состояние клиента
  • Переходное состояние клиента
  • Состояние локального пользовательского интерфейса

Ключевые моменты

  • Состояние сервера хранится на сервере и предоставляется, например, через конечную точку REST.
  • Постоянное состояние - это подмножество состояния сервера, которое хранится на клиенте в памяти.
  • Состояние клиента (например, фильтры, используемые для создания списка элементов) не сохраняется на сервере
  • РЕКОМЕНДАЦИЯ: Это хорошая практика, чтобы отражать как постоянное и клиент состояния в URL.

Это означает, что компонент обновит параметры URL, чтобы отразить постоянное состояние (то есть состояние сервера, которое кэшируется на клиенте в памяти), а также состояние клиента, например выбранные фильтры. Параметры URL-адреса могут быть добавлены для каждой службы, состояние которой сохраняется.

Постоянное состояние хранится в службах Angular, где часто бывает одна служба на функциональную единицу, например службу списка задач, службу пользователя и службу ведения журнала. Каждая из этих служб будет негласно обрабатывать сохранение состояния. Например, при запросе данных служба сначала проверяет, были ли данные уже получены с сервера, и только в случае отсутствия данных выполняет HTTP-вызов.

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

Источник

Итак, в первую очередь всякий раз, когда вы возвращаетесь к этому конкретному URL-адресу с любой страницы, поскольку ваша служба находится в вашем OnInit, поэтому будет вызываться ваш бэкэнд.

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

Источник
Другие вопросы по тегам