React, Vue, Angular и Svelte имеют нечто очень важное общее. Все они следуют шаблону стиля MVVM (Model-View-ViewModel). Вы можете подробнее прочитать здесь о том, что это значит, если вы не знаете этот шаблон, но в этом посте мы сосредоточимся в первую очередь на модели представления.
Обратите внимание, что это часть серии, в которой я создаю свой новый бизнес SASS Основное обеспечение. В предыдущем посте мы рассмотрели создание сопоставления ответов API. поэтому, если вам нравится такой контент для кодирования реальных сценариев, дайте мне знать в комментариях и, возможно, рассмотрите возможность подписки :)
Что такое модель просмотра?
Модель представления — это абстракция представления, раскрывающая общедоступные свойства и команды через уровень привязки. Это означает, что когда мы изменяем данные в нашей модели представления, мы можем заставить их отражать наше представление без каких-либо манипуляций с DOM.
Какую проблему мы пытаемся решить?
Я твердо верю, что модель представления должна быть чрезвычайно описательной и изолированной и предоставлять только те данные, которые относятся к представлению. Однако с Next.js и React я заметил сильную тенденцию моделировать представления вокруг того, как работает фреймворк, что очень затрудняет понимание зависимостей и создает длинные окольные пути ведения дел.
Давайте посмотрим на пример ниже.
Как видите, это всего лишь простой список дел. На данный момент у него есть только 3 функции: добавлять, отображать и заполнять задачи. И хотя вы можете довольно быстро сказать, что это делает, все же очень сложно понять зависимости между каждой функцией, не просматривая код, чтобы понять это.
Как мы можем решить эту проблему?
Хуки идеально подходят для наших моделей представления, потому что они могут принимать зависимости и предоставлять только те данные, которые нам нужны для нашего представления. С помощью этого подхода мы также можем создавать более общие модели представления, такие как модель представления формы или списка, чтобы мы могли удалить некоторое дублирование. Если вы хотели бы увидеть этот подход, пожалуйста, дайте мне знать в комментариях :)
Первое, что нужно сделать (без каламбура), — это разделить эти элементы управления на части, представляющие одну функцию. Пожалуйста, имейте в виду, как используется каждая из моделей представления, потому что я целенаправленно использовал их в разных сценариях, чтобы показать разные случаи.
Это новые элементы управления, которые мы создадим:
Список дел
Он будет содержать отображаемые данные и логику проверки.
Чтобы избежать метода обновления всего списка задач, мы создаем новый элемент задачи, который контролирует состояние проверки задач.
Список дел
Он будет содержать элементы списка и метод создания новой задачи.
Список задач теперь использует элемент Todo и ожидает список задач, но не требует дополнительных функций.
Добавить дело
Для этого потребуется функция обратного вызова, которую мы можем использовать для добавления нового TodoItem в TodoList и которая будет передана компоненту AddTodo.
Компонент добавления todo теперь принимает AddTodoViewModel для обновления состояния входного текста, а метод addTodo использует обратный вызов onAdd, который мы передадим из модели представления списка.
Со всем этим мы можем свести наше представление к следующему:
Это огромная разница, и она определенно облегчает чтение. Теперь наши зависимости доступны только тем компонентам и моделям представлений, которые в них нуждаются, что делает это решение гораздо менее связанным.
Полную реализацию можно посмотреть здесь.
Краткое содержание
Для этого метода абстракции есть время и место. Я бы лично рекомендовал его для более крупных проектов, чтобы быстро расширить функциональность компонентов. Попробуйте создать универсальные модели представлений для обработки повторяющегося кода, потому что это значительно сэкономит время.
Если вам нужны еще примеры или объяснения этих концепций, дайте мне знать в комментариях!
До следующего раза… Удачного взлома!
