Robur

Вы в компоненте yandex-map рендерите этот же компонент yandex-map, который внутри рендерит этот же компонент yandex-map.. ну я думаю вы поняли.

Сделайте не на скорую руку а вдумчиво.

window.onblur = () => console.log('noo')
так же вот эта ссылка полезна: https://developer.mozilla.org/en-US/docs/Web/API/P...

Вашему фронтендщику стоит посоветовать сначала изучить как это делается а потом огород городить.
но судя по тому что вы вместо него это выясняете, его все устраивает а вас - нет.

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

Не очень понятно что значит "запрос для входа пользователя" и "запрос для входа менеджера" -
у вас предполагается что пользователь будет нажимать на разные кнопки "войти как менеджер" и "войти как пользователь" или что?

Нормально так:
Кнопка для логина - одна.
запрос аутентификации - один.
сервер отвечает ошибкой или успешным ответом. Сама сессия ставится кукой, эта кука по хорошему должна быть httpOnly и из js кода не доступна. С ней работает исключительно бэкенд и так как хочет.
Аппа из ответа сервера (в body) либо сделав отдельный запрос (типа /currentUser) понимает что это за пользователь - менеджер или обычный и сохраняет это куда-то себе. В случае реакта это с большой вероятностью стор. Можно в localStorage чтобы при перезагрузке читать сразу оттуда.

Дальше аппа просто смотрит в стор в нужные моменты чтобы понять что пользователю показывать что нет.
Все права на запросы бекенд разруливает на основе сессионной куки которая приходит с каждым запросом автоматически. То есть сессии как таковой фронт вообще никак не касается - его дело - вызывать login/logout, получить от бэка инфу о текущем юзере и правильно обрабатывать 401.

Можно сделать и более сложные варианты - без куки, с каким-нибудь токенами и прочим, но скорее всего вашему фронтэндщику еще рано.

a.addEventListener('click', function () {
	setTimeout(() => history.replaceState({}, '', locationWithoutHash))
})

после этого ссылка при наведении мыши вместо http://site.ru/#portfolio покажет http://site.ru/portfolio#portfolio но с этим можно жить (и даже нужно чтобы анкоры продолжали работать), зато страница проскроллится куда вам надо и в адресной строке будет http://site.ru/portfolio

Можно.
Apollo в своем кэше может хранить все данные приложения относящиеся к серверу (фактически это все кроме состояния UI и еще пары мелочей типа сессии пользователя)

Так что в mobx просто становится меньше смысла, но совсем он не пропадает - если вам нужно зачем-то шарить состояние компонент друг между другом.

Ребята в Apollo предлагают его же использовать как стор и обращаться к локальному состоянию с помощью gql так же как и к удаленным данным. Не уверен насколько такой подход реально удобен в работе с состоянием компонентов, но возможность добавить какие-то локальные свойства к данным весьма неплоха.
вот тут можно почитать: https://www.apollographql.com/docs/react/essential...

^(?:мини)\s([^]+)?
поиграться и проверить можно тут https://regexr.com

с помощью "--"

"start": "npx webpack --config ./configs/webpack.config.js --watch --"

детали тут https://docs.npmjs.com/cli/run-script

Если вы уж по такой махровой классике, то в 2005-м принято было делать так:

function CountDownTimer(dt, id)
    {
    jQuery('.'+id).each(function(){
       var self = this;
        function showRemaining() {
        console.log(jQuery(self));
               jQuery(self).children('.timetoend').innerHTML = 'EXPIRED!';
            }
        }
      });
    }