Но в целом я не против названия “селектор”, оно вполне подходит
У меня лично нет неудобств от того что это дополнительный термин

Это выборка, маппинг это преобразование. Если у тебя есть класс и в нем геттер поле и доступ к нему будет маппинг?

Селектор название идеальное

Маппер как по мне это функция которая получает что-то на вход и с помощью этих данных дает что-то на выход

Геттер в классе на вход ничего не получает, по сути там маппер внутри зашит

Так что не вижу противоречий)

При чем createSelector делает часто разные преобразования и тем не менее называется селектором)

Создай функцию, в ней при вызове через параметр получи экземпляр класса и верни геттер ))

Нууу...спорно, короче

Ну тут да ))

Что спорно-то?) Главное чувствительные данные не хранить там

Вообще не о том разговор

А о чем?

Зови Климого старшего ))

Можно ли на клиенте получать id юзера из jwt токена

У нас речь как раз о том, когда юзер залогинен и допустим обновляет страницу
Там 2 варианта:
- токен не протух, все норм
- токен протух
Узнать не можем пока не отправим запрос на сервер

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

А если он во 2 варианте не был залогинен - у нас собственно нет никаких данных, ничего проверять и не нужно, сразу понятно что никто не может быть авторизован

ура, вышло

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

Если пользователь залогинен, статус ответа 200, ловит свой контент

Если пользователь не залогинен, статус ответа 401, ловит контент

то есть рендеринг происходит только после прохождения асинхронного запроса, а если он еще не завершен рендерится null и пользователь больше не ловит баг где сначала один вид а потом другой

Зато белую страницу ловит, и TTI больше)

а на React + TypeScript часто пишут? хочу понять стоит ли в TypeScript погружаться react разр. джуну