Если рассматривать на примере тостера, то есть BaseView, в которую вложено ещё три LeftSideView, CenterView и LeftView. А вот уже они собирают в себе компоненты, которые к mvc вообще никакого отношения не имеют, они просто компоненты.
<toster-sidebar>
<profile></profile>
<navigation></navigation>
<notifications></notifications>
</toster-sidebar>Модель может содержать названия тех операций, которые необходимы провести с картинкой, если это необходимо по логике.
состояние это информационная модель, которая отношения к бизнес модели не имеет.
Это была первая часть. С чем Вы не согласны?
Еще раз, Вы не понимаете что такое модель, так как сказали что модели две. Модель всего одна, второй модели с точки зрения приложения не существует, она всего-лишь представление, которое зависит от модели.
она всего-лишь представление, которое зависит от модели. Но на деле это представление настолько сложное что нуждается в собственной моделе.
Маленький пример - у меня есть тест. Его модель содержит коллекцию, которая содержит узлы с полем index. Сам тест заключается в анализе последовательности индексов.
Это модель из mvc.
Но может быть такая ситуация, когда второстепенной модели может потребоваться обратится к модели приложения. Вот тогда бы я мог сказать что такой подход можно назвать mvvm, но только как подход, когда модель обращается к другой модели
Компонент - это VC, а не MVC, модель живет своей жизнью и ей плевать на UI и презентационную логику.
Ваш пример с поиском взять. Есть "что-то" что выполняет саму работу - поиск, назовем это сервисом (потому что довольно общее название). И есть компонент, который отвечает за UI поиска, что бы пользователь имел возможность вбить айдишку, нажать кнопку и получить результат. И в этом случае наш компонент будет представлять собой вьюшку и контроллер (или вьюшку и вью модель, вьюшку и презентер, тут как угодно - от этого зависит только реализация самого UI компонента). Но по итогу работать этот компонент будет именно с этим сервисом, и именно этот сервис будет для этого компонента моделью.