Спасибо за интересный взгляд, но я не совсем согласен с вашим мнением. Вы говорите о проблемах с расширением логики относительно других подходов, но я совершенно не понимаю в чем она заключается. Когда мы хотим преобразовать поведение хука или хока, то взаимодействуем с ним через его аргументы или используем композицию (зависит от реализации конечно же, но мы усредним). Даже в рамках данного упрощенного примера нам ничто не мешает использовать props для Form.Item (те же аргументы функции), чтобы расширить его поведение, а также композицию. При этом мы даже имеем общий контекст, в котором можем распространять общую логику сразу среди всех Form.Item, чтобы избежать необходимости модификации каждого отдельного компонента.
Что касается кейса с checked , то конкретно для компонента формы предусмотреть специфичное поведение для некоторых групп взаимодействующих компонентов - это, на мой взгляд, нормально. Однако если вы захотите применить подход за пределами описанного в статье примера и попробуете организовать таким образом код в рамках какой-то другой задачки, то сможете для себя внезапно открыть, что valueне обязательно может быть примитивом. В зависимости от реализации value может представлять целый объект настроек, который будет сохраняться в общем контексте и обрабатываться соответствующим образом. Вас ведь не смущает общение web-worker'ов с main-tread через postMessage в формате преимущественно строк или банальная работа с localStorage таким же образом, так почему бы не посмотреть на это под немного иным углом? В ваших руках огромное кол-во свободы, остается сделать только славную реализацию
Можно и так конечно. Но это выглядит не очень выразительно, когда обоим компонентом нужно будет передать сразу несколько пропов, да еще рядом 10 таких же компонентов лежат в разметке. Организация через children выглядит более чисто, ближе к привычному синтаксису HTML
Вы правы, спасибо за замечание. В процессе написания статьи вокруг мерджа пропсов были определенные комментарии, но я решил сократить этот момент, а из примера кода не убрал. Надо поправить пример
Отличное замечание! Однако отмечу, что задача изначально стояла не только вокруг управления пропсами, но и вокруг интеграции общей обертки (например как в вашем случае лучше решить кейс с выводом сообщения о текущем статусе валидации для поля формы?). Я показал в статье альтернативу (не замену устойчивым паттернам), которая может быть полезна на стыке возможностей хуков и хоков, чтобы объединить вместе работу с пропсами и одновременное создание обертки элемента для различных нужд
Спасибо за интересный взгляд, но я не совсем согласен с вашим мнением. Вы говорите о проблемах с расширением логики относительно других подходов, но я совершенно не понимаю в чем она заключается. Когда мы хотим преобразовать поведение хука или хока, то взаимодействуем с ним через его аргументы или используем композицию (зависит от реализации конечно же, но мы усредним). Даже в рамках данного упрощенного примера нам ничто не мешает использовать props для
Form.Item(те же аргументы функции), чтобы расширить его поведение, а также композицию. При этом мы даже имеем общий контекст, в котором можем распространять общую логику сразу среди всехForm.Item, чтобы избежать необходимости модификации каждого отдельного компонента.Что касается кейса с
checked, то конкретно для компонента формы предусмотреть специфичное поведение для некоторых групп взаимодействующих компонентов - это, на мой взгляд, нормально. Однако если вы захотите применить подход за пределами описанного в статье примера и попробуете организовать таким образом код в рамках какой-то другой задачки, то сможете для себя внезапно открыть, чтоvalueне обязательно может быть примитивом. В зависимости от реализацииvalueможет представлять целый объект настроек, который будет сохраняться в общем контексте и обрабатываться соответствующим образом. Вас ведь не смущает общение web-worker'ов с main-tread черезpostMessageв формате преимущественно строк или банальная работа сlocalStorageтаким же образом, так почему бы не посмотреть на это под немного иным углом? В ваших руках огромное кол-во свободы, остается сделать только славную реализациюМожно и так конечно. Но это выглядит не очень выразительно, когда обоим компонентом нужно будет передать сразу несколько пропов, да еще рядом 10 таких же компонентов лежат в разметке. Организация через children выглядит более чисто, ближе к привычному синтаксису HTML
Вы правы, спасибо за замечание. В процессе написания статьи вокруг мерджа пропсов были определенные комментарии, но я решил сократить этот момент, а из примера кода не убрал. Надо поправить пример
Отличное замечание! Однако отмечу, что задача изначально стояла не только вокруг управления пропсами, но и вокруг интеграции общей обертки (например как в вашем случае лучше решить кейс с выводом сообщения о текущем статусе валидации для поля формы?). Я показал в статье альтернативу (не замену устойчивым паттернам), которая может быть полезна на стыке возможностей хуков и хоков, чтобы объединить вместе работу с пропсами и одновременное создание обертки элемента для различных нужд