pink2floyd, вы находитесь не только в Login, но еще и "в" том компоненте который рендерит Login.
вам надо что-то поменять чтобы он перестал это делать. Что поменять - вариантов масса.
например в стейте заведите переменную showLogin и ставьте ее в true когда надо показать и false когда надо скрыть окно логина, и в зависимости от этой переменной либо рендерите login либо нет.
Можно и роутинг, как вам ниже сказали.
ttywizard, Когда выкинете все лишнее (реально лишнее) тогда оставшееся систематизируете без особых проблем, и инструменты найдутся которые вам подходят.
Stockholm Syndrome, вполне себе нормальный неймспейсинг.
Тут он конечно нафиг не нужен но один факт того что автору такие варианты решения приходят в голову - большой плюс.
Автор, удачи.
yaroslav195, язык ничего не догадывается, в нем строго определенный набор конкретных конструкций.
Которым вы описываете что вы хотите чтобы было сделано.
И когда движок уже это делает, он не переписывает за вас программу - он делает то что сказано.
Если совсем по простому - то
Получается, в функции myFunc делается следующая вещь - (now)=>{return now*10}(10);
нет, не получается. в функции myFunc происходят совсем другие вещи.
Которые лично вы можете отдаленно представить как то что вы написали. А чтобы ваше представление было корректным и можно было это запустить (с похожим результатом но другими процессами), вам нужно добавить скобочки вокруг описания функции.
Николай, не видел чтобы тут грамотно помогали по юридическим вопросам :) А мнения рандомных девелоперов можно лет 50 собирать - у каждого свое, ответственность все равно на вас.
По технической части - это да, имеет смысл спросить.
IDONTSUDO,
1) вы как раз какой-то велосипед и изобретаете.
2) то что вы называете сессией пользователя - это не сессия, это просто его данные.
Микросервисы не значит что у вас одни и те же данные должны бессвязно лежать где попало, и каждый сервис для пользователя делает новые ID.
Микросервисы значат что у вас авторизацией пользователя занимается один сервис - он же делает id, он же создает JWT токен. Данными занимаются другие сервисы - но только этими данными, id пользователя они никак не генерят, не делают под него новые коллекции и все такое.
Если пользователя надо как-то обработать в сервисе лайков - то сервис лайков идет в сервис авторизации/личного профиля и получает там инфу пользователя, в том числе его id. Он не должен придумывать для пользователя какой-то новый ID.
То при первом обращении, пользователя. Генерируется снова Object Id.
нет, при первом обращении пользователя остальные сервисы отправляют его на localhost:8080, который генерит JWT токен в котором лежит id= qwe9102j0fjkfqweka0, этот jwt приезжает обратно на другие сервисы, которые его просто используют.
И ни как не связаны. В этом моя проблема.
Ваша проблема что вы за одни и те же данные хотите сделать ответственными разные сервисы. Не надо так делать.
id для "сессии" пользователя должен создавать ТОЛЬКО сервис авторизации/профиля. Остальные его берут из JWT токена и используют.
Почитайте OAuth/OpenID - они как раз сделаны для подобных схем взаимодействия
dollar,
Речь шла о том что плохой клиент, который уже кинул на оплату может стать хорошим. Это вряд ли. Хоть за 5 минут вы это выяснили, хоть за неделю. И пользы с таких клиентов всегда заметно меньше чем вреда.
dollar, Вы так говорите как будто с людьми не работали и живете в мире розовых единорогов.
1) бывает на 1 случай из 100, остальные 99 попьют вам столько крови и потратят столько усилий что лучше сразу всех 100 вычеркнуть и найти 20 нормальных за это время. Да и в этом одном вы еще долго будете сильно не уверены.
2) Может. Теоретически. Я даже думаю что когда-то это реально может произойти. Это тот же случай №1
Хотя все конечно зависит от цели, если нужно эффективно работать с конкретным результатом и доходом - то все просто - не заплатил, подвел, кинул и т.п. - в черный список без снисхождения.
Если хочется жить со всеми дружно, тешить самолюбие, избегать конфликтов и все такое - то конечно можно давать вторые (третьи, десятые) шансы, тратить свое время и терять деньги и хороших клиентов которые можно было бы найти вместо этого и все такое.
Впечатление что автор (или её контора) просто хочет сделать как привычнее, без каких-то аргументов и ищет поддержки в интернете.
Когда есть взвешенная оценка ситуации таких вопросов не возникает.
браузер отправляет запрос тогда когда ему говорят отправить запрос, а то что вы из этого как-то берете промис и что-то с ним делаете потом - ваше дело. Можете начать ждать его сразу (и в это время можно тоже что-то еще делать "параллельно") можете что-то поделать и ждать его потом, а можете вообще проигнорировать. Запрос в этот момент уже выполняется.
вам надо что-то поменять чтобы он перестал это делать. Что поменять - вариантов масса.
например в стейте заведите переменную showLogin и ставьте ее в true когда надо показать и false когда надо скрыть окно логина, и в зависимости от этой переменной либо рендерите login либо нет.
Можно и роутинг, как вам ниже сказали.