Зачем знать ООП и шаблоны во фронтенде?

Question

[Volodfarun]

Добрый вечер.
Я все понимаю но за пол года проектов я увидел что задачи трансортить с апи просто данные ну и поведение какием боком ооп то применять?)

Comments

[Сергей]

Создаёте компоненты на основе абстракций? А компоненты на основе других компонентов?

Answer 1

[Рональд Макдональд]

Да незачем, забейте.
Лучший шаблон - copy-paste.

Answer 2

[sim3x]

Верстка !== фронтенд

Когда будете писать фронтенд поймете

Comments

[Volodfarun]

sim3x 100 компонентов не понял вот и спрашиваю приведите пример если есть что сказать а нет так не пустословьте

[sim3x]

Volodfarun, А можете перефразировать, то что вы написали

[Volodfarun]

sim3x, конкретный пример примернения ООП

[sim3x]

Volodfarun,
https://github.com/facebook/react/search?q=class&u...

Answer 3

[Robur]

Затем же зачем и в любых других сферах разработки. Чтобы писать более сложный код с сохранением достаточной простоты его поддержки.

Конкретно вам на тех задачах что вы видели это может быть и не нужно. Зависит от того что вы делаете. Можно и без ооп и паттернов жить, если делать достаточно простые вещи.

Comments

[Volodfarun]

Robur пример посложнее где вам нужно ооп если можно) я просто написал 100 компонентов но увы...не понял

[Robur]

Ну лично я наоборот сейчас на фронте отхожу от ооп в сторону функциональных компонентов. Сходу вам расхожие шаблоны и варианты их использования не назову - я давно не теоретизировал на такие темы, это на мой взгляд актуально в основном для собеседований.
Для начала надо определиться что вы понимаете под ооп и какие шаблоны хотите применять? Если из книги банды четырех - то оттуда мало что подойдет просто потому что другой подход, язык и среда.
В реакте есть свои шаблоны, которые другие но применяются для тех же целей - HOC, render-свойства например. Можно и наследовать компоненты одни от других, но это уже считается антипаттерном.

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

Самое главное - знание хороших подходов и шаблонов, а главное проблем которые они призваны решать, позволяет видеть такие проблемные места и иметь в голове пару-тройку вариантов решения.
Если вы пишете хороший, переиспользуемый код, который легко читать и легко поддерживать - то наверняка уже используете набор разных шаблонов и подходов, возможно своих возможно почерпнутых откуда-то еще.