Вообще говоря, я могу придумать 2 варианта справиться с этим.
- Сохранять состояние карты где-то за пределами карты, и любой переход к маршруту карты может воссоздать карту и использовать информацию о состоянии, чтобы вернуть ее в прежнее состояние. Это то, что мы делаем в Open Data (приложение Ember). Состояние карты поддерживается в параметрах маршрутизируемого URL-адреса, поэтому URL-адрес http://opendata.arcgis.com/datasets/CAPCOG::schools?geometry=-104.712%2C28.588%2C-90.649%2C31.909&selectedAttribute=INSTR_TYPE указывает маршрут набора данных, чтобы открыть карту в bbox, указанном в параметре «geometry», чтобы добавить слой «CAPCOG :: school», с помощью встроенного средства визуализации с интеллектуальным отображением на поле «INSTR_TYPE». Как вы можете себе представить, если бы у вас было много состояний карты для управления, это могло бы усложниться быстро. Мы избегаем w/that b/c, мы отслеживаем только несколько бит состояния.
- Переместите карту на некоторый
<div>, который находится за пределами маршрутизируемой области обзора, а затем добавьте пользовательскую логику в маршрут для управления картой (т.е. создавать, скрывать, показывать, уничтожать и т. д.). Это общая идея, но вам придется настраивать ее в зависимости от рабочего процесса вашего приложения. Выгода будет заключаться в том, что вам не нужно будет снова и снова разрушать/воссоздавать карту. Это означает, что вам не нужно будет отслеживать состояние карты, только независимо от того, должно ли оно быть видимым на любом заданном маршруте и/или независимо от того, было ли оно еще создано. Недостатком является то, что вы вводите пользовательский поток состояний с побочными эффектами и т. Д., Который идет «против зерна» типичного углового развития. Я не знаю никаких примеров, демонстрирующих такой подход.