Robur

Развивайте умение искать информацию. Потренируйтесь на тостере и на вашем собственном вопросе.

Английский

Пока что я знаю html5, css3, sass, scss, flexbox, grids, кроссбраузерная адаптивная верстка, ssh, бэм, нативный javascript, Ajax, JSON, DOM, API, babel, es5, es6, gulp, ReactJS, npm, git, photoshop, zeplin, avocode.

Все вокруг считают меня махровым сеньором, первую работу во фронтенде взял годы назад. Не искал работу дольше двух дней. Не знаю и половины.

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

Выкиньте из этого списка 80% и действительно разберитесь в остальных 20%. По ним покажите какой-то опыт, уровень знаний, хоть что-то.

Для первой работы вам достаточно или действительно хорошо знать JS + базовый реакт, или хорошо знать HTML/CSS + базовый JS.

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

Удачи.

После сохранения токена, дальше ничего не происходит, получается нужно вручную сразу же переходить по новой ссылке

У вас код который получает токен, сохраняет его и больше ничего не делает, поэтому у вас больше ничего и не происходит.
Дальше токен надо использовать.

Как правильно написать код, чтобы клиент перешел по защищеному роуту с таким хэдером: < "Authorization", 'Bearer '+ localStorage.token) >

Используйте headers при вызове $.ajax
тут описаны детали:
https://api.jquery.com/jQuery.ajax/

Если вы ждете что дальше оно будет работать "как-то само" как с куками - не будет. Надо этот токен использовать "руками", добавляя в запросы к серверу.

Вкратце: Да.

Подлиннее:
Путались в определениях люди всегда и будут путаться. Да и сложно как-то взять определение которое было сделано давно для одних технологий и архитектур и натянуть на современные, другие реалии. Можно конечно и ежа на кактус натянуть, но лучше потратить эти усилия на что-то более полезное.
Даже термин SPA приложение уже не так актуален и не так хорошо ложится на то что сейчас пишут.

Называйте клиента клиентом, сервер сервером, и этого будет достаточно. Хотя конечно на нерд-вечеринке в конкурсе баззвордов вы возможно проиграете, если это для вас важно.

Как только этот вопрос перестанет беспокоить и вы вместо этого задумаетесь "а как переходить?" значит все, готов.

Нормально вам тимлид говорит, если сделать это грамотно. Single Source Of Truth рулит.

- разные проекты вполне могут оставаться разными проектами используя один и тот же общий для обоих код. Способов это сделать много. монорепа, модуль, реестр схемы например.
- у вас уже взаимная зависимость - общий GraphQL API. Вы вряд ли сможете поменять схему в одном проекте и оставить её старой в другом. Возможность хранить схему отдельно и менять независимо - это не гибкость, это прямая дорога к тоннам проблем и куче потерянного времени. Вас не смущает то что каждый раз меняя схему в одном месте надо обязательно сходить и поменять ее в другом чтобы они были всегда синхронизированы, и если вы этого не сделаете/забудете/опечатаетесь/не так скопипастите то что-то где-то обязательно сломается? Именно в этот момент стоило бы почувствовать что-то неладное.
- если вы не видели чего-то - это не значит что то, чего вы не видели плохо, а то что видели - хорошо.

В общем, делать стоит - главное делать грамотно. Если вы сейчас весь код в одну кучу свалите то конечно ничего хорошего не выйдет.

положите все общее в отдельный пакет, пилите там все и расшарьте между проектами.
Пакет можно хоть как организовать - от npm и bower до своего велосипеда

Самое сверхбыстрое - сохранить в JPG и на бэкграунд. Но с резиновостью будут некоторые проблемы.

Нет никакой проблемы в разделении на файлы и каталоги и подключении этих файлов. Если вас это напрягает - вам нужен нормальный редактор/IDE с навигацией и научиться им пользоваться. Есть много способов структурировать код - разложить по файлам, самый простой. Можно так же сделать все в духе ООП если это имеет смысл.
Для пользователей вашей библиотеки нет разницы как она внутри устроена до тех пор пока все работает, им важно API которое вы предоставляете, вот его надо продумать хорошо. Никому не интересно какие там префиксы у переменных, и запоминать какой префикс что значит тоже никто кроме вас не будет.
Если хочется лучше все очень четко структурировать и понимать что откуда пришло и что из себя представляет - можно взять Typescript.