Тут видимо у нас путаница с терминологией или я чего-то не понимаю. Мы про какие компоненты говорим? В статье речи отдельно про вью или какие-либо конкретные "архитектурные паттерны" (MV*, многими называемые как паттерны презентационного слоя) не идет. В статье используется MVVM только ради примера. Речь тут идет скорее про более высокий уровень, про структуру проекта.
В данном случае компонентом может являться либо совокупностью всех сущностей любого MV* подхода (то есть вью + совокупность логики + модель = один компонент) и в статье говорится про вариант древовидной архитектуры всего проекта на основе такого компонентного подхода, вместо тотального наслоения, как это часто делают, применяя Clean Architecture. И для таких компонентов говорить про шаблон компоновщика просто бессмысленно, это совсем про разное.
Либо компонентом можно назвать отдельный класс (как это делается в Decompose), содержащий только логику представления, грубо говоря являясь аналогом презентера или вью-модели. Тут уже есть смысл говорить про применение компоновщика, поскольку такие классы-компоненты могут быть зависимы друг от друга. Вы написали, что "компоненты обязаны удовлетворять шаблону проектирования "Composite". Я подумал, что речь именно про эти классы компонентов. И в этом случае я считаю, что не обязаны эти классы соблюдать этот паттерн. Тут может хватить обычного агрегирования, поскольку мне лично сложно найти причину использования тут компоновщика. Можно, но зачем это делать обязательно?
То что в "ортодоксальных" императивных UI-фреймворках иерархия вью обычно строится на основе паттерна компоновщик - с этим никто не спорит и это никакого отношения не имеет с компонентным подходом, про который говорится в статье.
Не соглашусь с формулировкой "обязан удовлетворять шаблону". Нет, не обязан. В Decompose компонентом может являться класс, который вообще никакой интерфейс не реализует и это нормально работает. Поскольку компоненты, про которые идет речь в статье, чаще всего не хранятся в коллекциях, потому что в этом смысла никакого нету. И искать и абстрагировать какую-то функциональность для таких компонентов тяжело и может быть бессмысленно. Поэтому компоновщик не обязан быть, но может помочь в некоторых ситуациях, с учетом того, что у компонентов древовидная связь.
Тут видимо у нас путаница с терминологией или я чего-то не понимаю. Мы про какие компоненты говорим? В статье речи отдельно про вью или какие-либо конкретные "архитектурные паттерны" (MV*, многими называемые как паттерны презентационного слоя) не идет. В статье используется MVVM только ради примера. Речь тут идет скорее про более высокий уровень, про структуру проекта.
В данном случае компонентом может являться либо совокупностью всех сущностей любого MV* подхода (то есть вью + совокупность логики + модель = один компонент) и в статье говорится про вариант древовидной архитектуры всего проекта на основе такого компонентного подхода, вместо тотального наслоения, как это часто делают, применяя Clean Architecture. И для таких компонентов говорить про шаблон компоновщика просто бессмысленно, это совсем про разное.
Либо компонентом можно назвать отдельный класс (как это делается в Decompose), содержащий только логику представления, грубо говоря являясь аналогом презентера или вью-модели. Тут уже есть смысл говорить про применение компоновщика, поскольку такие классы-компоненты могут быть зависимы друг от друга. Вы написали, что "компоненты обязаны удовлетворять шаблону проектирования "Composite". Я подумал, что речь именно про эти классы компонентов. И в этом случае я считаю, что не обязаны эти классы соблюдать этот паттерн. Тут может хватить обычного агрегирования, поскольку мне лично сложно найти причину использования тут компоновщика. Можно, но зачем это делать обязательно?
То что в "ортодоксальных" императивных UI-фреймворках иерархия вью обычно строится на основе паттерна компоновщик - с этим никто не спорит и это никакого отношения не имеет с компонентным подходом, про который говорится в статье.
Не соглашусь с формулировкой "обязан удовлетворять шаблону". Нет, не обязан. В Decompose компонентом может являться класс, который вообще никакой интерфейс не реализует и это нормально работает. Поскольку компоненты, про которые идет речь в статье, чаще всего не хранятся в коллекциях, потому что в этом смысла никакого нету. И искать и абстрагировать какую-то функциональность для таких компонентов тяжело и может быть бессмысленно. Поэтому компоновщик не обязан быть, но может помочь в некоторых ситуациях, с учетом того, что у компонентов древовидная связь.
Мне лично интересно было бы узнать про работу в таких интересных местах как Гонконг, Сингапур.