Хук от этого не спасёт, он просто нужен для реализации. И получается, что в общем случае выносить вызовы хуков в HOC - достаточно безблагодатное занятие. Возможно, есть исключения, но их немного
Я сейчас работаю над проектом, в котором некоторое время фанатично применялся mobx. Настолько фанатично, что у каждого чекбокса есть свой presenter, store, HOC, который связывает store, presenter и компонент. И там, где можно было написать одну строку кода с useState или коротенького хука useToggle, внезапно появляется целых двадцать, плюс тесты на них. А потом глаза лопаются от монструозности происходящего.
Вообще, по мне, так мораль в том, что надо знать где лучше делать максимально просто и тупо, а где стоит применять разничные паттерны, включая все эти M\s+(P|C) и понимание это приходит с опытом.
Я попросил показать пример, потому что вы рассуждаете чисто теоретически, а теория хороша только тогда, когда она подтверждается практикой, иначе она превращается в ненужные абстрактные рассуждения.
Например, в теории может возникнуть необходимость шарить между командами, работающими на разных фреймоворках, бизнес-логику, а на практике если логика изначально написана под React и хуки, то переиспользовать её скажем в Svelte врагу не пожелаешь.
Поэтому я всё же настаиваю чтобы вы задумались и попробовали привести пример из реальной жизни, где один и тот же хук, реализующий сложную бизнес-логику, может быть повторно использован с разными слоями представления. И думаю, что у вас это не получится, потому что в результате окажется, что логика и представление так плотно свяжутся, что их почти невозможно менять независимо друг от друга. А мелкие изменения типа изменения формы кнопочек или иконок продуктивнее делать инжекцией реализаций мелких компонентов через пропсы.
За догму лучше вообще ничего не брать, потому что то, что хорошо работает в одной ситуации - может плохо работать в другой ситуации. Можно рассмотреть ваш эксперимент ещё с точки зрения распределения ответственности и того, какие могут быть причины для изменения:
Исходный вариант: есть компонент, который знает как отрендерить интерфейс и какой хук вызвать чтобы отработала бизнес-логика. Делаем себе пометочку, что вообще-то ему не очень стоило бы знать про эту бизнес-логику. Но с прагматической точки зрения проблемы от этого бывают крайне редко. Если вдруг это ПРОБЛЕМА, то можно передавать ссылку на хук как один из пропсов с дефолтным значением. Это попахивает странностями, но поможет динамически менять поведение в широких пределах. Всё, после этого компонент знает какая там бизнес-логика по умолчанию и позволит поменять её при большой необходимости.
Ваш усовершенствованный подход: есть компонент, который знает как отрендерить пропсы. Неплохо. Есть хук, который умеет в нужную бизнес-логику. Тоже неплохо. Но теперь нам нужен способ, чтобы их связать и а) нам по-хорошему надо делать это в другом файле и б) вся ответственность получившегося HOC в вызове хука и другого компонента, то есть просто сшивание простейших вещей. Если возвести подобный подход в ранг корпоративного правила в крупной компании, кодовая база получит по десятку лишних строк и лишний файл на каждый компонентик, плюс необходимость прыгать глазами между файлами. С точки зрения принципа бритвы Оккама -- это излишнее усложнение, так как существует более простой способ.
Вы объявляете развязку представления и логики как преимущество, взяв за догму что это хорошо само по себе. Однако нет никаких доказательств что это всегда так (я лично из опыта сказал бы, что это в большинстве случаев совсем даже не так). В данном случае вы обменяли простоту и производительность (а HOC в реакте раздувают VirtualDOM и снижают производительность кода и отладки) на достаточно субъективную "читаемость". Можно было достигнуть почти того же, просто вынося всю логику в большой хук и замокав его для тестов рендеринга. Это намного проще читается и отлаживается, а заодно не создаёт соблазна вынести HOC в отдельный модуль и получить еще оверхед времени выполнения на резолвинг дополнительных модулей. В общем, ваше намерение понятно, но результат скорее отрицательный.
Я так понимаю, ответ на поставленный в заголовке вопрос - потому что автор так и не научился эти принципы применять на практике. По мне, так есть две других причины их не применять - "надо написать быстро, а дальше - трава не расти" и "чо ты умничаешь, пиши чтобы джуны понимали" со стороны руководства, но в этих случаях надо задать себе вопрос, а хочешь ли ты вообще оставаться в таких проектах.
Забыли сказать про минификацию JS/CSS. В WP для этого есть хорошие плагины.
Ну и отключение обновлений / экономия одного запроса к БД — это экономия на спичках. По сравнению с кешированием и opcache и избавлением от 404 эффект мизерный. Также можно не запариваться с чисткой от старых постов если не используются плагины с выборками по кастом-полям постов (при использовании кастом-полей индексы не используются, в остальных случаях — используются и скорость почти не зависит от наличия мусора).
Моя библиотечка предназначена для других нужд. Та, о которой вы говорите — это User API. Она предназначена для Desktop и Mobile приложений, я моя — для IFrame. Разница в том, что userapi-ruby работает в контексте конкретного пользователя после авторизации под его аккаунтом вконтакте. (Кстати, метод авторизации там используется очень спорный и не факт что надёжный, но это виноват вконтакт). Моя же библиотека работает с использованием secret key приложения и к конкретному пользователю не привязана.
Дальше, если придираться — насколько я понимаю userapi-ruby не поддерживает вызовы типа friends.get (через точку) и несколько различных сессий в одном приложении (потому что информация об авторизации хранится в переменных класса).
Сдаётся мне, серьезное преимущество scrum — это чёткая сформулированность user story на момент когда она попадает в цепкие лапки разработчика. Потому что эту story уже на десять раз посмотрели во время покеров и плэннигов и еще раз пересмотрели непосредственно перед запуском итерации — это повышает вероятность вылавливания проблем постановки задач и резко повышает продуктивность за счет того, что программист садится и просто реализует, а не бегает к PO/PM каждые десять минут. А ТЗ неизбежно устаревает, в голове же всё не удержишь.
Хук от этого не спасёт, он просто нужен для реализации. И получается, что в общем случае выносить вызовы хуков в HOC - достаточно безблагодатное занятие. Возможно, есть исключения, но их немного
Я сейчас работаю над проектом, в котором некоторое время фанатично применялся mobx. Настолько фанатично, что у каждого чекбокса есть свой presenter, store, HOC, который связывает store, presenter и компонент. И там, где можно было написать одну строку кода с useState или коротенького хука useToggle, внезапно появляется целых двадцать, плюс тесты на них. А потом глаза лопаются от монструозности происходящего.
Вообще, по мне, так мораль в том, что надо знать где лучше делать максимально просто и тупо, а где стоит применять разничные паттерны, включая все эти M\s+(P|C) и понимание это приходит с опытом.
Я попросил показать пример, потому что вы рассуждаете чисто теоретически, а теория хороша только тогда, когда она подтверждается практикой, иначе она превращается в ненужные абстрактные рассуждения.
Например, в теории может возникнуть необходимость шарить между командами, работающими на разных фреймоворках, бизнес-логику, а на практике если логика изначально написана под React и хуки, то переиспользовать её скажем в Svelte врагу не пожелаешь.
Поэтому я всё же настаиваю чтобы вы задумались и попробовали привести пример из реальной жизни, где один и тот же хук, реализующий сложную бизнес-логику, может быть повторно использован с разными слоями представления. И думаю, что у вас это не получится, потому что в результате окажется, что логика и представление так плотно свяжутся, что их почти невозможно менять независимо друг от друга. А мелкие изменения типа изменения формы кнопочек или иконок продуктивнее делать инжекцией реализаций мелких компонентов через пропсы.
За догму лучше вообще ничего не брать, потому что то, что хорошо работает в одной ситуации - может плохо работать в другой ситуации. Можно рассмотреть ваш эксперимент ещё с точки зрения распределения ответственности и того, какие могут быть причины для изменения:
Исходный вариант: есть компонент, который знает как отрендерить интерфейс и какой хук вызвать чтобы отработала бизнес-логика. Делаем себе пометочку, что вообще-то ему не очень стоило бы знать про эту бизнес-логику. Но с прагматической точки зрения проблемы от этого бывают крайне редко. Если вдруг это ПРОБЛЕМА, то можно передавать ссылку на хук как один из пропсов с дефолтным значением. Это попахивает странностями, но поможет динамически менять поведение в широких пределах. Всё, после этого компонент знает какая там бизнес-логика по умолчанию и позволит поменять её при большой необходимости.
Ваш усовершенствованный подход: есть компонент, который знает как отрендерить пропсы. Неплохо. Есть хук, который умеет в нужную бизнес-логику. Тоже неплохо. Но теперь нам нужен способ, чтобы их связать и а) нам по-хорошему надо делать это в другом файле и б) вся ответственность получившегося HOC в вызове хука и другого компонента, то есть просто сшивание простейших вещей. Если возвести подобный подход в ранг корпоративного правила в крупной компании, кодовая база получит по десятку лишних строк и лишний файл на каждый компонентик, плюс необходимость прыгать глазами между файлами. С точки зрения принципа бритвы Оккама -- это излишнее усложнение, так как существует более простой способ.
Вместо примера вы ответили абстрактными рассуждениями, а я его не просто так попросил
Приведите, пожалуйста, реальный пример использования такой возможности декомпозиции, которую нельзя сделать через только хуки
Вы объявляете развязку представления и логики как преимущество, взяв за догму что это хорошо само по себе. Однако нет никаких доказательств что это всегда так (я лично из опыта сказал бы, что это в большинстве случаев совсем даже не так). В данном случае вы обменяли простоту и производительность (а HOC в реакте раздувают VirtualDOM и снижают производительность кода и отладки) на достаточно субъективную "читаемость". Можно было достигнуть почти того же, просто вынося всю логику в большой хук и замокав его для тестов рендеринга. Это намного проще читается и отлаживается, а заодно не создаёт соблазна вынести HOC в отдельный модуль и получить еще оверхед времени выполнения на резолвинг дополнительных модулей. В общем, ваше намерение понятно, но результат скорее отрицательный.
Я так понимаю, ответ на поставленный в заголовке вопрос - потому что автор так и не научился эти принципы применять на практике. По мне, так есть две других причины их не применять - "надо написать быстро, а дальше - трава не расти" и "чо ты умничаешь, пиши чтобы джуны понимали" со стороны руководства, но в этих случаях надо задать себе вопрос, а хочешь ли ты вообще оставаться в таких проектах.
В данном случае все страницы кешируются на шесть часов (сайт не использует комменты и прочую интерактивность).
Ну и отключение обновлений / экономия одного запроса к БД — это экономия на спичках. По сравнению с кешированием и opcache и избавлением от 404 эффект мизерный. Также можно не запариваться с чисткой от старых постов если не используются плагины с выборками по кастом-полям постов (при использовании кастом-полей индексы не используются, в остальных случаях — используются и скорость почти не зависит от наличия мусора).
Спасибо Яндексу за это
:)
Дальше, если придираться — насколько я понимаю userapi-ruby не поддерживает вызовы типа friends.get (через точку) и несколько различных сессий в одном приложении (потому что информация об авторизации хранится в переменных класса).