У меня примерно так - layout состоит из 3х частей - sidebar, main, drawer. Sidebar и drawer пользователь может закрыть, оставаясь на той же странице. Но мне надо об этом знать, например надо скрыть внешний компонент drawer , если внутри ничего не смонтировано.
Я делаю это через query-params. Sidebar и drawer в mounted/destroy/click меняют их.
Но! Меня при этом преследует ошибка от router, что навигация в самого себя запрещена (path не меняется), и что хуже не работает replace, каждое изменение query попадает в историю :((
Передавай состояние через provide / inject, если данные не пришли менять состояние элементов
Они разве реактивные?
Не понял, как часть с сайдбарами связана с ошибкой роутера...
Ну когда юзер нажимает на крестик на сайдбаре, я делаю примерно так router.replace(route.fullPath,{ sidebar: 0 })
То есть всегда состояние сайдбаров завязано на query параметрах? И это намеренно (нужно именно как часть URL, а не просто так соединилось)?
А sidebar это компонент внутри которого находится router-view. И сам этот внешний компонент закрывается по этой опции в query
А зачем ты делаешь привязку роутера и компонентов, которые могут обойтись без него ?
Ну пока это единственное что я придумал, и кажется это не лучший вариант :)
Придумал для чего?
Поподробнее пожалуйста)
Ты вышел уже ответил, я понял)
Не понятно, намеренно ли связаны query параметр и сайдбар, или это было просто единственной идеей как управлять сайдбаром
Пока единственной идеей. Ну вообще изначально когда юзер заходит на страницу сайдбар заполняет роутер, это именнованный view. И тут все ок, мне надо только как-то понять что юзер его закрыл.
Так а почему не повесишь на крестик пользовательское событие , которое будет передавать его куда тебе нужно?
Хмммм :) а это идея. Попробую
Если не нужно иметь именно ссылку, именно URL на открытие сайдбара, то достаточно просто иметь "глобальную" реактивную переменную с состоянием открыто/закрыто (ну или event emitter) для управления его состоянием.
сайдбар через роутер - плохая идея
А почему? У меня в нем много разного монтируется
и в мобильном виде сайдбар навигационный через роутер?
роутер - для того, что связано с роутингом, состояние чего хранится в URL идентификаторе
У меня он не навигационный, а окошко с разной информацией информацией, не знаю, наверное это называется не sidebar. Но да, через роутер. В зависимоти от урл в нем отображается разное содержимое.
То есть когда он открыт и закрыт - разные url ? Можешь пример показать их
Показывать разный контент в зависимости от URL - нормально. Но редко нужно именно факт открытия хранить в адресе страницы
Нет ) Что-то мы не понимаем друг друга. Есть разные url, например /pages/page1 и /pages/page2, когда ты на них захожишь у тебя справа, в "сайдбаре" показываются два разных компонента. Но сам сайдбар юзер может закрыть. При этом мне надо знать что содержимое пропало, чтобы скрыть например остатки сайдбара.
Я бы такое хранил в каком нибудь useAppConfig и локал сторидже Это динамичная персональная настройка UI пользователя - открыто или закрыто А не часть роута
Эта идея не дружит с разными табами и не реактивная
useAppConfig - реактивно, с сохранением в ЛС
Собственно выше мне подсказали простое решение - посылать событие когда юзер жмет крестик, и кажется это полностью меня устраивает))
ЛС - перезтрет данные с разных вкладок
тогда sessionStorage естественно
если тебе вообще надо это запоминать между сессиями похоже, что нет
тогда один глобальный ref всё сделает
а вот интересно. Компоненты vue вроде не связаны с роутингом (в то время, как роутер связан). И вот они данные получают через пропсы, но некоторые из них используют useRoute, получают данные из роута. Откуда, из какого инсайта им знать, что данные надо получить из роута? Делая это, они связываются с роутингом также, как и сам роут. А если нет разницы, то какая разница: используются именованные представления или та же логика делается через компоненты с useRoute?
chatGPT не понял тебя Пожалуйста, переформулируйте свой промпт
Да, да
Если и то, и то связано с роутингом, то какая разница: используются именованные представления или та же логика делается через компоненты с useRoute?
с useRoute будет каша
Этот вопрос связан с обсуждением сайдбара выше?
да, если разницы нет, то сайдбар можно разместить в именованном представлении
предлагаешь через именованные представления?
именованные роуты удобны, они позволяют явно написать, что вот в этом роуте используется такой-то компонент. А в родителе просто рендерить "текущий компонент". Делать кучу v-if=route === route1 - некрасиво. Делать из этого красивый компонент = сделать копию RouterView
Там задача была с открытием/закрытием сайдбара
Ты не понял предыдущего обсуждения и залез не туда
там он может использовать именованные представления для любой цели - его дело. Лично мне интересно почему именованные представления - плохая практика
Они не плохая практика, просто редко встречаются задачи, в которых они подходят
Через именованные представления ты заменяешь компоненты обычно целиком Через useRoute ты всего лишь немного меняешь логику внутри компонента
и в компоненте с useRoute я тоже могу взять убрать какой-либо компонент в шаблоне, и на его место поставить другой. Также как и через именованные представления. Или какого рода изменения целиком имеешь ввиду?
Если ты в компоненте с useRoute убираешь какой-либо компонент в шаблоне, и на его место ставишт другой, то стоит подумать о то чтобы там использовать RouteView Причем, скорей всего он будет неименованный, а дефолтныц
Обсуждают сегодня