https://codesandbox.io/s/vuex-form-via-proxy-zubpu

вот модальное окно с формой на vuetify, не смог воспроизвести проблему

@rafail_mamedov вопрос с авторизацией, если в куках лежит sessionId, но он протух, пользователю в любом случае вернется 401
тут одними куками не обойтись, в любом случае будет запрос на сервер

или я чего-то не понимаю

конечно не обойтись, я ж писал у 2 уровня

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

Но это 2 уровня
Сервер не решает «пусть ли на страницу», серыер решает «отдать ли данные», это 2 разных зоны ответствености, сервер не знает и не должен знать о структуре страниц вообще

Грубо говоря, сначала идет проверка токена в localstorage, если его нет - на страницу логина, если он есть - попытка запроса на сервер, а потом уже, в зависимости от ответа, решать, что рендерить - логин или дефолт лейаут?

ну если выбросить некоторые этапы, то да

но в вашем случае не надо выбрасывать логические этапы, ща опишу подробнее
и токен не надо хранить в local storage, но это другая тема

Спасибо

Кто знает как в vuex-orm при добавлении данных к модели, сделать так чтобы она добавлялась в начало массива а не в конец

===Наши основные слои
== router
совершает переходы между страницами (изменяет url) «хуки», «navigation guards», чтобы к нему можно было присоединить другое ПО, промежуточное ПО, которое будет выполняться между переходами (отсюда и название)

== router middleware
«промежуточное» ПО, встраивается в router и вызывается как минимум перед каждым запросом
это просто набор неких функций
на входе у этих функций информация, как минимум такая
-с какой страницы совершен переход
-на какую страницу производится переход
-функции управления роутером, в данном случае интересны next и redirect

-мы сами сюда же можем добавить информацию о «контексте», например доступ в Vuex или каким-то другим глобально доступным компонентам нашей системы, неважно

next - это переход к следующему middleware (промежуточному обработчику) (если есть)
когда все next выполнены (зарезолвлены), то роутер понимает, что можно завершать переход и переходить к конечному этапу, когда управление передается следующему слою и router-view начинает что-то рендерить

redirect - это перенаправление (кэп, да), означает, что текущий событийный цикл завершен, нас отправили на некую новую страницу и вся цепь событий должна пройти

==router-view
решает какой компонент показать, принимает это решение на основе текущего состояния router


===Пример работы
предположим у нас есть 3 страницы
/login - доступен только неавторизованным
/public - доступен всем
/secret - доступен только авториованным


Первый сценарий, неавторизованный юзер заходит на /login
1. Запрос обрабатывается роутером
2. Роутер вызывает свои middleware
3. Auth Middleware принимает на вход описанную выше информацию, нам интересно
4. то, что запрашивается /login
5. то, что этот роут доступен публично (как именно это настроить вариантов много, можно передавать некую мету информацию при насройке роутера)
6. то, что пользователь не авторизован
7. На основе этого он вызывает переданную функцию next(), «резолвится», разрешает дальнейший переход
8. Роутер успешно отрабатывает, router-view имеет возможность получить свой «активный» компонент для рендеринга

Тут пользователь может отправить форму на апи сервер, получить в ответ какой-то токен и записать его в Vuex или еще куда-то, пока неважно. Важно то, что наше приложение сможет знать о том, что пользователь «авторизовался»

Второй сценарий, авторизованный юзер заходит на /login
1. Запрос обрабатывается роутером
2. Роутер вызывает свои middleware
3. Auth Middleware принимает на вход описанную выше информацию, нам интересно
4. то, что запрашивается /login
5. то, что этот роут доступен публично
6. то, что пользователь авторизован
7. предыдущий пункт не дает этого промежуточному ПО разрешиться (зарезолвится), он не вызывает next, а делает что-то другой, например пользуется функцией redirect чтобы отправить куда-то пользователя, это может быть предыдущая страница или главная страница, неважно, пускай в нашем случае будет redirect на secret
8. redirect завершил текущий событийный цикл, далее начался новый «авторизованный пользователь запрашивает страницу /secret», можно его рассмотреть отдельно

1. Роутер успешно отрабатывает, router-view имеет возможность получить свой «активный» компонент для рендеринга

Третий сценарий, авторизованный юзер заходит на /secret
1-2 такие же
Auth Middleware теперь имеет другую информацию на входе
1. то, что запрашивается /secret
2. то, что этот роут не доступен публично
3. то, что пользователь авторизован
4. все сходится, вызывается next
5. router-view пытается отобразить страницу


запрошенная страница пытается получить некие данные для отображения себя
и тут может быть 2 варианта
1. Запрос возвращает данные и все хорошо, страница рендерится, данные показываются

2. Запрос возвращает ответ о том, что «недостаточно прав», это может быть наши расценено как ошибка в сохранении токена или подделка токена или что угодно другое, важно то, что сервер не считает этого пользователя авторизованным, тогда мы например в хуках нашего HTTP клиента или еще где-то где можно отслеживать ошибка запросов препринимаем какую-то логику, например очищаем нашу информацию о залогиненности и редиректим на /login,  а это опять уже описанный выше сценарий сценарий (как правильно прокинуть функцию роутера в хук http клиента сложный вопрос внедрения зависимостей, но не особо существенный в текущем контексте, на данном этапе разбора темы можно сделать как угодно, а затем вернуться к этой теме)

* оговорка -  хорошей практикой будет являться наличие «локальных middleware» и этап запроса данных будет выполняться тоже как «промежуточное ПО» без попытки рендеринга, в Nuxt для этого есть устаревший fetch у каждой страницы-компонента, но сейчас его предлагают заменить на «анонимные middleware», но то несколько другая тема опять же

Сценарий, когда пользователь запрашивает /public думаю очевиден, там вообще можно не применять Auth Middleware, потому что он всегда резолвится

Эта логика верна не только для Vue App, в том или ином виде она присутствует почти везде, лейтмотив всего этого - разделение зон ответственности

Воу, за такое развернутый ответ большое спасибо
С первого раза понял не все, конечно, но буду вчитываться)
респект!

@rafail_mamedov наркоман штоле?
Замути статью, зачем пропадать зря труду.
На хабр куданить.

сохранил себе в txt. Уже нет сил читать, но инфа огонб вроде

та нз

Теперь о слоях представлений

Теперь о слоях представлений

Это исключительно зона ответственности вашего «компонента-страницы»

Да, можно сделать структуру типа

<layout>
<some-component v-if=‘АВТОРИЗОВАН’></some-component>
<router-view></router-view>
</layout>

но то не особо красиво, в Nuxt у каждого «компонента-страницы» есть свойство layout, который определяет внутри какого layout себя отобразить, простейше это можно сделать примерно так

 <component :is=«currentLayout»>
   <router-view>
 </component>

currentLayout это название какого-то компонента, который является слоем
он может как-то задаваться, в еще одном Middleware или через какое-то глобальное состояние, любой транспорт который доставить значение указанное в «компоненте-странице»

неупрощенный вариант можно посмотреть в Nuxt

спс) та вроде это все уже где-то описано, но с ходу не помню где, поэтому и написал

ога, но я решил установить пакет управления слоями из npm

vue-extend-layout вроде бы называется

Про шаблоны отлично тут описано:
https://markus.oberlehner.net/blog/dynamic-vue-layout-components/

теперь в каждом слое есть роутер вью, но в дефолтном с навбарами всякими, а в auth только страничка авторизации
сейчас буду разбираться с доступами

благодарствую