Зато пример явный :D Понятно что есть примеры получше, просто сходу не пришли. Неявность и правда чаще всего является основной сложностью (потому что много контекстов нужно переключить, для того чтобы разобраться)
Привет, не очень понял на какой сути ООП пляшет React)
Основная суть статьи в том, что то как ПЛОХО и как ХОРОШО зависит только от конкретного проекта, и выделены критерии по которым можно для себя этот вектор оценки построить. Я понимаю что очень хочется готового решения, но тут серебрянной пули нет, и надо думать в рамках конкретных проектов и задач.
BTW спасибо за коммент, он очень хорошо отражает ожидания :)
Композицию точно можно и нужно использовать. Я в основном пытался раскрыть то, что не стоит бояться больших компонент, которые композиционно состоят из разных кусочков логики (скрываем много разного под одной абстракцией). Про композицию мне ещё нравится подход с хуками примерно как тут. Про подход с композицей нужно помнить одну вещь - чтобы на проекте в куче соседних мест не делали композицию по другому (и везде начиналось разное поведение, пользователи не любят неконсистентность из-за возникающего когнитивного диссонанса). Если возвращаться к истокам, то в таком случае стоит использовать фасад, чтобы потом не страдать в порыве унификации)
Зато пример явный :D
Понятно что есть примеры получше, просто сходу не пришли. Неявность и правда чаще всего является основной сложностью (потому что много контекстов нужно переключить, для того чтобы разобраться)
Привет, не очень понял на какой сути ООП пляшет React)
Основная суть статьи в том, что то как ПЛОХО и как ХОРОШО зависит только от конкретного проекта, и выделены критерии по которым можно для себя этот вектор оценки построить. Я понимаю что очень хочется готового решения, но тут серебрянной пули нет, и надо думать в рамках конкретных проектов и задач.
BTW спасибо за коммент, он очень хорошо отражает ожидания :)
Скорее DRY :)
Привет, спасибо за классное дополнение к статье!
Композицию точно можно и нужно использовать. Я в основном пытался раскрыть то, что не стоит бояться больших компонент, которые композиционно состоят из разных кусочков логики (скрываем много разного под одной абстракцией). Про композицию мне ещё нравится подход с хуками примерно как тут. Про подход с композицей нужно помнить одну вещь - чтобы на проекте в куче соседних мест не делали композицию по другому (и везде начиналось разное поведение, пользователи не любят неконсистентность из-за возникающего когнитивного диссонанса). Если возвращаться к истокам, то в таком случае стоит использовать фасад, чтобы потом не страдать в порыве унификации)
Ещё я вдохновлялся докладом про трейдоффы при написании фреймворка от создателя Vue Evan You on Vue.js: Seeking the Balance in Framework Design | JSConf.Asia 2019. Написание компонент тоже часто связано с нахождением подобного баланса