Объектно ориентированное и функциональное программирование в React?

Question

[Андрей Охотников]

Хорошая ли практика смешивать ООП и ФП в проекте. Планирую реализовать проект следующим образом - все элементы UI , т.е. компоненты выполнить в функциональном стиле с использованием хуков, а всю бизнес логику вынести отдельно и реализовать через ООП.
Это норма? Есть ли примеры подобных проектов?

Comments

[Виталий]

отличный пример как делать на реакт есть у палантир называется blueprint
ребята пошли простым путем...

Answer 1

[Robur]

Можно. Любой подход который приводит к чистому и хорошо поддерживаемому коду - хорош. Вариантов как это сделать много, само по себе смешивание ооп и функциональщины к плохому коде не приводит.

Другой вопрос - зачем вам нужно делать именно так как вы написали. Если у вас есть ответ на него - без проблем.

Comments

[Владимир Проскурин]

А что остается в React от ООП? Там нет наследования (есть, но предпочитается композиция), инкапсуляция почти не нужна (разве что, для различных либ). Обычные классы писать можно даже не зная ООП.

[Robur]

Владимир Проскурин, Ну это уже философский спор, так то есть люди которые утверждают что JS без классов это самый правильный ООП. Есть и те кто утверждает что даже Java не достаточно ООП.
К тому же автор говорит "бизнес логику вынести и использовать ООП" - ни слова что это будут классовые реакт-компоненты, я понял это так что него там будет как раз "правильное" ооп в бизнес-слое, с классами, наследованием и дальше по списку, а функциональщина - в компонентах.

[Владимир Проскурин]

Robur, ну, в основном, данные все в редаксе обрабатываются, не так много места остается на классы, только для всяких либ. Я лично мало вижу, чтобы ООП применялось, хотя я сторонник ООП, выращенный на книгах Роберта Лафоре, но писать на ООП приходится все меньше. Еще сейчас многие начали переходить на хуки, до конца убивая все следы классов.

[Robur]

Владимир Проскурин, То что все меньше классического ооп - это правда. Его и так то было не густо.

Answer 2

[Mikhail Osher]

Считаю это вполне так нормой, и что-то похожее сам практикую. Что-то похожее на https://github.com/kentcdodds/bookshelf/ (подход YourServiceNameProvider + useYourServiceName, чтобы инкапсулировать логику), но чуток иначе.
Организовать доменный/сервисный слой на ооп, что потом весьма проще мокать и тестить, по сравнению с замыканиями.
А на хуках + контексте уже "инфраструктурный" слой, ака контейнеры.