Как разделить компонент по зонам ответственности без наследования?
Добрый день, есть 1 сложный компонент - работа с canvas.
Сейчас компонент это огромный комбайн, который отвечает за:
1. Отрисовка на canvas
2. Масштабирование и перерасчет canvas
3. Реализует интерфейс event emitter (подписка и диспатчинг событий)
Очевидно поддерживать этот жирный класс-компонент сложно.
Нужно разбить его на меньшие по зонам ответственности, как минимум на 3.
Обычно я бы разбил это классы и использовал наследование, но в реакт наследование не принято.
Ложку дегтя добавляет тот факт, что это ContextProvider (обертка над MyContext.Provider для управления содержимым контекста), это нужно для того, чтобы из любого дочернего компонента можно было управлять canvas, отрисовать, масштабировать, подписаться или задиспатчить событие
Подскажите пожалуйста, как грамотно все разделить, что с этим делать?
А как конкретно вы бы здесь использовали наследование? Описание очень краткое, но я не вижу тут особо чего-то, что можно было бы вынести в базовый класс.
А как конкретно вы бы здесь использовали наследование?
Так бы и разделил:
1. класс реализующий интерфейс подписок и диспатч событий
2. Базовый класс Canvas который расширяет п.1
3. Класс расширяющий Canvas работающий с масштабированием
По сути это разделит класс на зоны ответственности ну и + я смогу переиспользовать каждый класс в других компонентах
Алексей Уколов, можете, пожалуйста привести пример, как это в общих чертах должно выглядеть ?
с 2 и 3 пунктом +- все понятно, в контексте можно хранить размеры или коеф масштабирования, из одного компонента управлять этими значениями (п3, отвечает за масштабирование), другим использовать (п2, базовый canvas)
А вот как с помощью композиции сделать observer, ума не приложу.
Буду очень благодарен за маломальские пример, а то совсем не представляю
В Реакт мне лично хватает:
- Hight Order Components (HOC) для специфической логики;
- Кастомные хуки для работы с данными и состоянием;
- Папка с утилитами (чистыми функциями);
- Ну и всё это можно комбинировать с провайдерами, если нужно.
Создавать иерархию классов в Реакт как минимум неудобно, потому что теряется возможность гибко использовать реактивность и состояние.
А функциональный стиль позволит максимально разделить всю логику и сделать её предсказуемой
