Конечно можно много что сделать на коленке, однако для индустрии лучше когда подобные вещи стандартизированы, так новички быстрее становятся полезными в конвеерной разработке.
Наоборот. Иммутабельность позволяет сравнивать данные просто по ссылке, вместо глубокого сравнения, что позволяет быстро пропускать ненужные тяжелые операции (как правило это отрисовка). Пересоздавать объекты на пути от дочернего поля до самой верхушки объекта нужно чтобы ссылки на объект поменялись, тк потребители стора / компоненты могут подписываться на изменения любого уровня вложенности на пути к дочернему изменяемому значению, а все что вложено в объект это его часть. Очевидно очень желательно делать структуру стора как можно более плоской.
Взять что-то вроде github.com/pelotom/unionize для экшенов и их матчинга + github.com/mweststrate/immer для имутабельности (и то и другое дружит с TypeScript) + что там у вас в риактовом мире для сайд эффектов и асинхронности используется и должно быть проще.
2. состояние иммьютебельно и едино (библиотеки и combineReducers конечно помогают, но код читать и отлаживать довольно тяжело)
C github.com/mweststrate/immer можно менять стейт императивно, как-будто напрямую, а библиоетка сделают грязную работу за вас обрабатывая прокси дифф.
Иммутабельность помимо прочего позволяет выполнять сравнение по ссылке при ченж детекшене, что при правильном использовани позволяет избежать лишних отрисовок и в целом значительно увеличить производительность.
Для крупных развивающихся приложений идея центрального стора довольно полезена. Особенно принцип single source of truth. Несколько раз бывало делал по-быстрому без стора некоторую часть функционала и каждый раз в итоге приходилось потом переделывать на стор (что сложнее чем изначально сделать на сторе), тк со временем стало сложно развивать и поддерживать штуковины где состояние изолированно хранилось в самих компонентах или где-то в разбросанных сервисах.
Современные фреймворки пропагандируют компонентный подход к разработке (что хорошо), и это влияет на количество файлов в проекте. Классический компонент это 3 файла (js/ts + html + css/sass) и сами компоненеты могут часто быть совсем небольшими и без особой логики (dump которые, просто отрисовка допустим из центрального redux-like стора).
PS 1к файлов не проблема сгенерировать двум толковым фронтендерам за год.
И читают, когда в этом действительно есть необходимость
При этом явно оттадавая себе отчет в том что рефлексия медленная и в том что даже следующий минорный релиз допустим библиотеки которая «хакается» рефлексией может сломать их хаки тк приватные поля не являются частью контракта.
Довольно разноплановый подкаст, ведущие и гости которого обсуждают языки программирования, новости рынка IT и различных компаний, делятся практическими советами и подходами, обсуждают методики и инструментарий.
Там почти одна Java, никакой не разноплановый, а скучный.
«Радио-Т» если ты здесь, предлагаю в каждом выпуске упоминать какой-нибудь новый или просто малоизвестный открытый гитхаб проект, как отдельная рубрика. Желательно проект «наших» разработчиков. Это привлекло бы к подобным проектам больше внимания.
Поддерживаю, «Подлодка» хороший подкаст. Как правило выпуски тематические, а не просто трепля о событиях произошедших на неделе. Приглашают обычно людей которые действительно работали с обсуждаемыми технологиями или имеют релевантный опыт относительно темы выпуска, а не просто рассказывают свое теоретическое мнение.
Frontend Weekend тоже неплохой, бывают интересные гости.
И в этом огромная пробелема. Лучше выбрать пускай даже менее функциональное решение, но изначально написанное на TypeScript, чем использовать сторонние файлы деклараций.
Даже если файлы декларации пишут сами авторы JS библиотеки, что случается не часто, это далеко не всегда гарантирует их полноценность и валидность.
Иммутабельность помимо прочего позволяет выполнять сравнение по ссылке при ченж детекшене, что при правильном использовани позволяет избежать лишних отрисовок и в целом значительно увеличить производительность.
PS 1к файлов не проблема сгенерировать двум толковым фронтендерам за год.
При этом явно оттадавая себе отчет в том что рефлексия медленная и в том что даже следующий минорный релиз допустим библиотеки которая «хакается» рефлексией может сломать их хаки тк приватные поля не являются частью контракта.
— github.com/tc39/proposal-class-fields/issues/100
— github.com/tc39/proposal-class-fields/issues/144
— github.com/tc39/proposal-class-fields/issues/177
— github.com/tc39/proposal-class-fields/issues/203
— и тд
Frontend Weekend тоже неплохой, бывают интересные гости.
Даже если файлы декларации пишут сами авторы JS библиотеки, что случается не часто, это далеко не всегда гарантирует их полноценность и валидность.