Robur

ПО которое в любой соцсети удаляет все для чего есть доступ, а там где нет - оставляет либо ругательные сообщения, выражающие полное недовольство этим фактом, либо жалостливые просьбы поудалять за вас в стиле болгарского вируса.
Уверен что это будет что-то новое.

Я думаю что да.
Надеюсь это вам действительно поможет.

Для фокуса сделайте свои css- классы. И их же для скрытия/показа.
Ловите события мыши на меню - ховер, клик, работаете с дом элементами добавляя/удаляя эти классы как вам нужно.

Вам надо просто при переходе с registration на login не добавить а заменить роут

было: /main -> /solvation -> /registration
переходите на /login, становится: /main -> /solvation -> /login

в этом случае все работает как надо автомагически.

Заменить роут - смотря как вы его реализовали, если через то https://reacttraining.com/react-router/web/api/Lin...

должен ли я был хранить копию его магазина все эти годы?

Если договорились об этом то да, если не договорились то нет. Внимание - вопрос! как вы договорились?

И второй вопрос, а даже если бы и остался сайт, стоило бы его бесплатно отдавать, если заказчику было наплевать на твое творение и по сути, раз он профукал сайт, это его проблемы, пусть заново заказывает?

Это уж для себя каждый сам решает - вопрос больше этически-филосовский.

вам надо добавить в описание стейта свойство cartItems.
скорее всего в интерфейс myState:

interface myState {
cartItems: ItemType[]|
}

ItemType естественно надо правильный подставить

1. Генерируете совершенно случайную строку с нужными параметрами длины/символов
2. проверяете есть ли она в базе
3. если да - то п 1.
4. сохраняете в базу.

Пожалуйста!

Можно и в императивном стиле писать как в школе на паскале учили - и тоже будет "хватать".

Так как вы - можно писать, на govnocod.ru это конечно не тянет. Так же "на прототипах" есть еще 50 вариантов как сделать то же самое.

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

Вопрос стоит поставить так: по какой причине вы все еще пишете тот вариант у которого объективно больше недостатков?
Я знаю только одну - лень/некогда/нежелание разобраться в новых возможностях и переучиться. Она не очень весомая.

Зачем стейт сделан так как сделан - хорошо описано в доках и всевозможных гайдах.

Однако же, если на странице мы хотим иметь массив из 20 элементов, то мы должны их всех добавить в state по одному, как поля, иначе при изменении одной буквы в одном объекте придется менять весь массив, что представляется весьма неэффективным.

По какому критерию "неэффективности"? как вы это померяли, какие-то цифры есть? В современных аппах столько всего происходит что создать массив из 20 элементов ничего не значит. Заметьте что элементы массива вам не надо пересоздавать, только сам массив в котором 20 каких-нибудь ссылок. Сложить две строки в одну может быть затратнее.

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

Для хранения данных "вообще" есть сторы уровня приложения, откройте для себя mobx - он позволяет хранить объекты любого уровня сложности, и при этом обновлять компоненты на сколько угодно малой области изменений. В примере выше, если у вас есть массив из 20 объектов, и вы поменяли какое-то поле в одном из них - то при желании можно сделать так чтобы перерендерился и обновился только тот div который это поле рисует и ничего больше. Если вы пришли с Vue то вам будет это совсем близко.

насчет "сложные структуры и легко сделать ошибку" - возьмите тайпскрипт и забудьте о 99% опечаток.

вот тут есть пара вариантов, попробуйте

нормальное.
Удачи вам в яваскрипте с таким перфекционизмом.

Почитать что такое this в JS и как оно работает.

Кратко - там дальше наверняка self используется внутри функций которые вызываются откуда-то извне и для них this будет меняться, поэтому в self просто хранится ссылка на нужный объект, чтобы не потерять.

Вообще так писали лет 5 назад, сейчас можно и без этого.
для vue есть vue-class-component который делает код заметно лучше.

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

Определитесь с нарузками.
Хотя бы RPM.

не знаю переписывали ли вконтакт на С, но можно посмотреть и по другому - до определенной точки им вполне хватало php. И вам до этой точки хватит.
Вы уже точно знаете когда вы достигните этой же точки и вам перестанет его хватать?

Если у вас больше академический интерес - "понятия не имею какое это имеет значения, но просто приятно будет знать что оно на 0.00001 мс в среднем быстрее", то возьмите GO - он модный и по слухам быстрый. как будет по факту - вам на самом деле не важно, вы вряд ли увидите эту разницу.

https://microservices.io/ - много полезных мыслей про микросервисы.

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

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

Если вам не надо отвечать за продукт, а надо сделать именно архитектуру - то идете к тому кто отвечает, и составляете с ним хоть какой-то роадмап на пару лет. На его основе уже будете думать что от чего будет зависеть, в каком порядке делать, и вообще какие функциональные блоки вам нужны.
Пока продукт не описан - архитектуры не получится, разве что какие-то совсем базовые штуки. Даже выбор БД или протокола общения между сервисами зависит от бизнес - требований

Как лучше распределить нагрузку между членами команды, и т.п.

это уже про управление командой.

Если на вас взвалили вообще все от проекта до архитектуры и управления командой, то удачи. Если не завалите все полностью - будет крутой опыт.