как видно из комментариев, у автора нет цели как-то реально использовать информацию, у него цель её складировать как можно больше так чтобы создать иллюзию того что у него её много и что он может ей "удобно управлять и всегда найти если вдруг понадобится". Все через это проходили.
Пока что наболее близко к этому решению пришли платформы поисковиков, но конечно под остальные требования (опенсорс, развернуть на своих серверах, чтобы была лично для меня) это решение не очень подходит.
С роутингом все еще проще - вы просто в login делаете history.pusр() на какую-то другую страницу, на что у вас в соответствующем месте происходит рендеринг, роут с Login не рендерится (и соответственно удаляется), а какой-то другой компонент рендерится вместо него.
Но я бы советовал сначала сделать без него, для лучшего понимания как оно вообще все в реакте работает.
Например - чтобы поменять стейт родительского компонента - передайте в login колбек, который будет вызван когда надо логин скрыть (вы залогинились или нажали на крестик или еще что) в этом колбеке уже делаете setState() в родительском компоненте.
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
Хотя все конечно зависит от цели, если нужно эффективно работать с конкретным результатом и доходом - то все просто - не заплатил, подвел, кинул и т.п. - в черный список без снисхождения.
Если хочется жить со всеми дружно, тешить самолюбие, избегать конфликтов и все такое - то конечно можно давать вторые (третьи, десятые) шансы, тратить свое время и терять деньги и хороших клиентов которые можно было бы найти вместо этого и все такое.
Пока что наболее близко к этому решению пришли платформы поисковиков, но конечно под остальные требования (опенсорс, развернуть на своих серверах, чтобы была лично для меня) это решение не очень подходит.