Kentavr16

Роли чаще всего это группа привилегий. Почему используют их вместе - зависит от системы. Иногда достаточно ролей. Например, если у вас одна админка и пользоваться ей могут только админы. Но если у вас один UI на несколько пользователей, то обойтись одной ролью будет сложно. Если вы будете в коде везде делать проверку, что пользователь админ и ещё сотрудник и ещё менеджер, то это будет сложно. К тому же при добавлении новой роли вам нужно будет по всему коду добавлять проверку ещё и на другую роль. Вместо этого используют разрешения, которые выдаются пользователю. В коже вам нужно проверить это разрешение/привилегию и вам без разницы какая это роль. Добавляете новую роль и привязываете новые разрешения. Пользователь сразу сможет использовать систему в зависимости от прав.

То есть роли используют чаще для чего-то глобального и/или объединения разрешений. А сами разрешения уже позволяют гибко настраивать проверки.

Ещё можете почитать статью: Smoother & sharper shadows with layered box-shadows.

Получите ВСЕ данные и потом выводить один раз.
XMLHttpRequest меняем на fetch, для параллелизации запросов используем Promise.all. И когда всё загружено - рисуем DOM.

Да, параметризовать можно только значения но не наименование полей и таблиц (мало того ты и prepared запрос так не сможешь сделать, с каждым новым значением $(column) будет новый запрос).

Да, тебе придется валидировать значение в $(column) но это не сложно так как там допускаются только латинские буквы (оба регистра), цифры и подчеркивание. Конечно если ты не используешь идентификаторы_в_ковычках (там любые символы, но зачем тебе стрелять себе в ногу), ну в крайнем случае как разработчик ты знаешь что у тебя в запросе и какие допустимые наименования полей там могут быть

Стилизация элементов<select> и <option> с помощью CSS в некоторых аспектах ограничена. Это связано с тем, что рендеринг выпадающего списка и его пунктов (<option>) веб-браузерами в значительной степени зависит от нативного операционной системы интерфейса пользователя (OS UI). В результате многие аспекты этих элементов, такие как ширина выпадающего списка, оформление выпадающего списка, и стилизация пунктов списка, могут оказаться сложными для полного контроля с помощью обычных CSS.

Для стилизации можете воспользоваться например select2

Не работаю с react, но есть проекты на inertia+vue. Думаю, общий подход от этого не изменится.

Вы уже используете inertia state (`props.auth.user.name`) - можно использовать и для popup. Props реактивные. Добавьте нужные значения (textPopup,isVisiblePopup,typePopup) в shared-data.
Изменяете значение на странице с кнопкой - в шаблоне отобразится popup.
function showPopup можно вынести в отдельный файл и импортировать на нужных страницах. showPopup изменяет prop.popup.textPopup и прочие.

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

Посмотрите на Beacon API. Он как раз предназначен для аналитики.
А обычные запросы браузер имеет полное право обрывать потому что полагает что в нём уже нет никакого смысла раз вы покидаете страницу.

А ещё в MDN прелагают использовать событие visibilitychange вместо beforeunload.
https://developer.mozilla.org/en-US/docs/Web/API/N...

происходит перерендер Wrapper, рендерится второй Inner. После этого запускается onUnmount первого Inner, в консоли вижу null,

- происходит перерендер Wrapper, рендерится второй Inner, в который попадает функция update в котором state равен null, после запускается onUnmount первого Inner и т.д

демо

и вообще не советую в функции возврата обновлять какой-то стейт кроме глобального стора который относится ко всему приложению

если компонент размонтируется, и вызовится функция возврата из useEffect например которая обновляет какой-то там стейт верхнего компонент который там же размонтировывается, а пользователь просто открыл другую страницу в SPA, то будет сбой

https://codesandbox.io/s/divine-water-32g3k8?file=...

Даже не знаю с чего начать...
Ну начну с определений объектов Number и String (сами почитаете).

У объектов есть методы, объекты можно вызывать как функции.
Первый пример
Number(Math.pow(2, 4));
Здесь мы имеем два объекта Number и Math. У объекта Math вызывается метод pow, который возвращает некое значение. Это значение передается в качестве параметра в Number, вызываемый как функция для приведения переданного значения к числу.
То есть Number() ожидает параметр, и мы его туда передаем.

Второй пример.
str.toLowerCase().includes(s);
Здесь вы имеем объект String (строка в переменной str). У этого объекта куча методов, которые можно использовать. Здесь вызывается метод toLowerCase(). Этот метод НЕ принимает никаких параметров (смотрите документацию) и возвращает новый объект String. Затем у этого нового объекта String вызывается еще один метод includes(s)

Посмотри на nestjs - там вполне opinioated архитектура.
Правда если понравится nest - не понятно, зачем вообще нода (ибо можно тогда на какой-нибудь из "более взрослых" языков перейти. Типа того же C# + asp net core)

Для будущих поколений кто будет искать решение этой проблемы. Так и должно быть. И это не ошибка работы )))))