Я не очень помню React.JS классовый, боюсь ошибиться.
Поэтому могу просто порекомендовать пример с хуками:
https://github.com/kentcdodds/react-hooks/blob/mai...
Здесь описание:
https://github.com/kentcdodds/react-hooks/blob/mai...
Классовый React.JS сейчас не используется (используется только в поддержке старых компонентов).
И вообще, я думаю, вам определенно стоит пройти курс
https://epicreact.dev/ , а классовый React.JS миновать.
На github есть репозитории с *.md материалами, их и блога более чем достаточно, и то, все не нужно.
Предупреждаю, у меня нет коммерческого опыта разработки React.JS.
Несколько позже, если нужно, скину статьи из документации, которые, на мой взгляд, необходимо изучить после курса Кента Доддса.
Отрывки по Software Design:
https://www.livelib.ru/book/1003548149-refaktoring...
Фундаментальное практическое правило гласит: то, что изменяется одновременно, лучше хранить в одном месте.
Мы структурируем программы, чтобы облегчить внесение в них изменений;
Планируя изменение, мы хотим иметь возможность перейти в определенную точку программы и внести изменения именно в ней.
Когда я сталкиваюсь с кодом, который имеет дело с двумя разными задачами, я ищу способ разделить его на отдельные модули. Я стараюсь выполнить такое разделение, поскольку, если мне нужно будет вносить изменения в программу, мне придется иметь дело с каждой задачей в отдельности и не потребуется держать их обе в голове. Если мне повезет, то, возможно, будет достаточно внести изменения только в один модуль без необходимости запоминать детали другого.
модульность, которая обеспечивает возможность вносить множество изменений в программу, в то же время понимая лишь небольшую ее часть. Чтобы добиться этой модульности, я должен убедиться, что связанные программные элементы сгруппированы и связи между ними легко найти и понять.
Если у меня хороший набор структур данных, соответствующих поставленной задаче, то реализующий поведение код прост и понятен. Плохие структуры данных приводят к большому количеству кода, работа которого заключается просто в обработке плохих данных. И это не просто сложный код, который трудно понять; это также означает, что структуры данных скрывают то, что делает программа.
И главы 1 - 4.
Из книги
https://www.ozon.ru/context/detail/id/136939101/
Очень важна легкость внесения изменений в систему при изменении требований. Для этого нужно использовать наиболее простые решения:
программная сущность (класс, модуль, метод) должна по возможности решать лишь одну задачу, но делать это хорошо.
Чем меньше у метода, класса или модуля вспомогательных задач, тем ниже вероятность случайных изменений.
Но нужно спрашивать себя:
не приведут ли меня принципы и паттерны в мир ненужной сложности (overengineering): стал ли мой дизайн после внесения изменений проще? Не решаю ли я проблему, которой на самом деле не существует?
Не попал ли я в сети преждевременного обобщения (premature generalization)?
Полезно будет пройти часть 4.
https://kentcdodds.com/blog/when-to-break-up-a-com...
Совершенный код С. Макконнелла, я читал с с. 76 по с. 152, про остальное ничего сказать не могу.
Р. Мартин Чистый код, я читал Функции, Содержательные имена и Обработка ошибок, про остальное аналогично, не знаю. SOLID у него плохо объяснен.
Понравившиеся проекты:
UI библиотека для CMS Sanity
https://github.com/sanity-io/design
CMS Sanity (Фронтенд код сейчас в процессе перехода на @sanity/ui. Наверное, будет лучше изучать по pull request'ам)
https://github.com/sanity-io/sanity
По чтению кода: https://www.youtube.com/watch?v=6J4ZejMsKKY
P.S. Не знаю, что из этих книг нужно для Junior Frontend разработчика. Мое мнение лучше воспринимать на половину серьезно, т. к. я где-то между Junior и Middle). Работал к этому времени только в бэкенде.
