Зря вы так, так бывает очень часто, за большими командами не уследишь, особенно когда работы аврал.
А вот если бы это контролировалось на уровне фреймворка, то такой проблемы не возникло бы в принципе
Я не придумываю и я бы не писал, если бы не столкнулся сам. Я использую только строгий Typescript и один из последних апдейтов react script просто повалил полностью проект при том, что именно react script должен взять на себя ответственность инкапсуляции настроек пакета и лёгких обновлений. Почитав ветки было очевидно, что Typescript темплейт они даже не тестировали. До этого нельзя было сделать из-за баги оверрайд настроек eslint и много других багов, например после обновления deprecated модули были еще включены...
По моему скромному мнению такой уровень качества недопустим. В этот же момент миграции Angular с 6 до 10 версии были абсолютно безболезненны с минорными изменениями и взамен давали производительность и уменьшение пакета и мне все-равно какая версия там eslint или tslint, это не должно стопорить работу команды на неделю.
Вы мягко говоря неправы, композиция ничего не дублирует, вы все-равно выносите дубликаты в отдельные методы, которые к тому часто становятся без сайд эфектов и успешно их внедряете с DI.
"Но на самом деле наследование — это и есть композиция с автоматическим делегированием. "
О боже, конечно нет, вы упускаете ключевые различия. вы не можете независимо внедрить часть наследованной иерархии, код сильно связан и тестировать композицию намного проще, так как вы имеете независимые куски и нежно инициировать всю иерархию.
То что я написал очевидно после любого Энтерпрайз уровня проекта. Начните использовать шаблоны с композицией и вы убедитесь сами.
Я видел у них там есть симуляторы, было бы интересно почитать насколько они проработаны. Наверное очень тяжело просчитать все правильно, ведь играет роль разная плотность атмосферы, положение топлива в баках, порывы ветра (если они влияют на столь тяжёлую машину)
Не только в стилях, там и сам фрейморк пестрит проблемами.
Например, в Angular есть план миграции между версиями и поддержка CLI, в React это месяц ковыряния и хаков, чтоб старый код работал после апдейта. Например тима реакт пыталась взвалить это на свои плечи с их react scrip, но там критические вещи весят годами.
Проблема не в том, что React нарушает принципы .NET или Java, а в том, что вообще нарушает правила хорошего тона выработанные годами! Эти приципы чисто утилитарны — служат для разработки в команде, для легкой поддержки кода, для тестирования.
Это не решение для enterprisе и тем более не для ускорения разработки.
Любой проект с хуками вне tutorial превращается в нечитаемое спагетти. Нужны хорошие знания JavaScript и отличное абстрактное мышление, чтоб вообще знать и понимать когда и что там происходит и обновляется. Вместо декларации переменных громоздкий — useState, оборачивание всех if в useEffect. Во множестве случаев новички React нагромождают огромое количество ошибок даже не понимая этого, им кажется все простым. Для них загадка когда и почему идут обновления и сколько объектов создается при каждом рендере.
Множество проблем как сильное связывание кода, невозможность атомарно тестировать хуки, нет нормального dependency injection.
Недавно была статья-разъяснение useCallback. Это очень печально, что для базового кирпичика фреймворка нужны статьи чтоб объяснить базовые понятия.
Все должно быть понятно с первого взгяда, но этого к сожалению это не про React.
Разница в том, что некоторые из официальных трактовок потенциально проверяемы, а также несут философские изыскания. То есть в целом двигают науку вперед, а не просто переливают из пустого в порожнее.
Внутри там простая версия чата есть, а еще есть chat.google.com и meet.google.com
Можно шарить экран, не нужно устанавливать, можно вести трансляцию на 100 человек, можно записывать уроки и сразу получить их в облаке.
Вообще рассмотрите, это полноценный офисный пакет.
Я думаю для школы и университета там есть специальные условия, возможно даже бесплатно: edu.google.com/products/gsuite-for-education
Тяжело супортить, тяжело расширять, тяжело тестировать. Очень плохая поддержка от команды реакт. Просто тот же Angular проще и лишен этих недостатков. (я говорю про проекты Энтерпрайз уровня, может для одностраничников ситуация другая)
Везде так, но с Dependency Injection сборка сервисов cтановится пустяком в отличии от наследования.
Да, кроме вершины и середины иерарихии.
Что правда? Тогда ясно.
Зря вы так, так бывает очень часто, за большими командами не уследишь, особенно когда работы аврал.
А вот если бы это контролировалось на уровне фреймворка, то такой проблемы не возникло бы в принципе
Когда вырастет и почитает архитектурные паттерны первое поколение школьников их писавших и использовавших? ;)
Мой выбор React hooks + Strict Typescript, RXJS, SCSS.
Может за это и любят, что "свобода"?
Я не придумываю и я бы не писал, если бы не столкнулся сам. Я использую только строгий Typescript и один из последних апдейтов react script просто повалил полностью проект при том, что именно react script должен взять на себя ответственность инкапсуляции настроек пакета и лёгких обновлений. Почитав ветки было очевидно, что Typescript темплейт они даже не тестировали. До этого нельзя было сделать из-за баги оверрайд настроек eslint и много других багов, например после обновления deprecated модули были еще включены...
По моему скромному мнению такой уровень качества недопустим. В этот же момент миграции Angular с 6 до 10 версии были абсолютно безболезненны с минорными изменениями и взамен давали производительность и уменьшение пакета и мне все-равно какая версия там eslint или tslint, это не должно стопорить работу команды на неделю.
Вы мягко говоря неправы, композиция ничего не дублирует, вы все-равно выносите дубликаты в отдельные методы, которые к тому часто становятся без сайд эфектов и успешно их внедряете с DI.
"Но на самом деле наследование — это и есть композиция с автоматическим делегированием. "
О боже, конечно нет, вы упускаете ключевые различия. вы не можете независимо внедрить часть наследованной иерархии, код сильно связан и тестировать композицию намного проще, так как вы имеете независимые куски и нежно инициировать всю иерархию.
То что я написал очевидно после любого Энтерпрайз уровня проекта. Начните использовать шаблоны с композицией и вы убедитесь сами.
Спасибо за грамотное развёрнутое объяснение.
Наследование на практике хуже чем композиция, не буду расписывать как автор выше, но это проверено на опыте и опробовано во множестве контекстов.
Расскажите про тыкву ребятам из .NET или Java Enterprise которые поддерживают проекты часто больше 7 лет.
Я видел у них там есть симуляторы, было бы интересно почитать насколько они проработаны. Наверное очень тяжело просчитать все правильно, ведь играет роль разная плотность атмосферы, положение топлива в баках, порывы ветра (если они влияют на столь тяжёлую машину)
Если что-то нужно доносить, это уже проблема.
Не только в стилях, там и сам фрейморк пестрит проблемами.
Например, в Angular есть план миграции между версиями и поддержка CLI, в React это месяц ковыряния и хаков, чтоб старый код работал после апдейта. Например тима реакт пыталась взвалить это на свои плечи с их react scrip, но там критические вещи весят годами.
Это не решение для enterprisе и тем более не для ускорения разработки.
Любой проект с хуками вне tutorial превращается в нечитаемое спагетти. Нужны хорошие знания JavaScript и отличное абстрактное мышление, чтоб вообще знать и понимать когда и что там происходит и обновляется. Вместо декларации переменных громоздкий — useState, оборачивание всех if в useEffect. Во множестве случаев новички React нагромождают огромое количество ошибок даже не понимая этого, им кажется все простым. Для них загадка когда и почему идут обновления и сколько объектов создается при каждом рендере.
Множество проблем как сильное связывание кода, невозможность атомарно тестировать хуки, нет нормального dependency injection.
Недавно была статья-разъяснение useCallback. Это очень печально, что для базового кирпичика фреймворка нужны статьи чтоб объяснить базовые понятия.
Все должно быть понятно с первого взгяда, но этого к сожалению это не про React.
Можно шарить экран, не нужно устанавливать, можно вести трансляцию на 100 человек, можно записывать уроки и сразу получить их в облаке.
Вообще рассмотрите, это полноценный офисный пакет.
Я думаю для школы и университета там есть специальные условия, возможно даже бесплатно:
edu.google.com/products/gsuite-for-education
У этой платформы огромное число минусов, рассмотрите документы гугл.
Там же есть совместная работа, чаты и многое другое и сделано это намного лучше.
FastAPI?
Тяжело супортить, тяжело расширять, тяжело тестировать. Очень плохая поддержка от команды реакт. Просто тот же Angular проще и лишен этих недостатков. (я говорю про проекты Энтерпрайз уровня, может для одностраничников ситуация другая)
Не все, например, React незаслужено популярен.
Подходы и решения в нем больше похожи на костыли чем на обдуманные решения.
Сложности тестирования, на каждый простой чих нужно написать тонну кода, отсуствие внятной архитектуры, отсутсвие two way binding и многое другое.