Если говорить простым языком, то парадигмы ООП и ФП в React, как и в самом JS/TS живут бок о бок и отлично себя показывают. Правильно использовать молотки для гвоздей, а отвертки для саморезов. Тут такая же ситуация. В функциональном стиле гораздо проще работать с иммутабельностью, которой в React достаточно. Например, у вас есть данные (props) на вход. С помощью useMemo на основании определенных пропсов рассчитываются какие-либо следствия. Затем они отображаются. Получается некий pipeline преобразования props -> data -> render.
С точки зрения возможностей, то же можно сделать и в ООП, но само ООП больше заточено на мутабельную парадигму. Так зачем забивать саморезы молотком? Это возможно, но не нужно. ООП прекрасно нашло себе место на сервисном уровне реакт приложений. Там можно и DI себе организовать, и с декораторами поработать, и разделить бизнес логику, обернув ее в нужные шаблоны проектирования. В общем, чем бы дитя не тешилось.
В своей практике обычно использую связку React + React Query для визуализации. tsyringe и Mobx для организации сервисного уровня приложения. Mobx-State-Tree для описания и работы с моделями данных.
А касательно камней в огород Angular: стандартизация и строгость - это хорошо. Плохо, когда этого нет. Для того же существуют линтеры, форматеры, TypeScript, Golang и т. д. Когда проект становится сложным(архитектурно) и объемным в условиях бизнеса, необходимо внедрять много уровней контроля и стандартизации, чтобы кодовая база не превратилась в ад. Каждый разработчик зачастую пишет так, как ему хочется. Если на проекте несколько таких человек, то проект быстро превратится в картину абстракционистов. Один пишет в ООП парадигме, другой в ФП. Одному нравится Redux, другому Mobx, а третий вообще хочет использовать Effector. Тот еще цирк с конями. Angular же в свою очередь из коробки дает инструкцию как и что правильно делать (я не адепт ангуляра, люблю React, но хорошему фреймворку всегда готов отдать дань уважения). Любой новый разработчик на таком строгом проекте быстро вольется в стиль разработки команды. На таком проекте будет легко поддерживать чистоту кода, поскольку никто не изобретает велосипеды и все пользуются одинаковыми молотками. Задачи можно будет частично перекладывать с человека на человека и так далее. Это все уменьшает затраты на развитие и поддержку проекта. А чем меньше затрат - тем лучше для бизнеса) Стоит помнить, что за любым мало мальски серьезным проектом стоит бизнес. Все остальное в свободное время на личном сервере. Если что-то не приносит денег - этим не будут заниматься. Если что-то поглощает больше денег, чем нужно - от этого избавляются)
Поэтому "Чистая архитектура" это классно, но только в книжках) На практике все намного сложнее. Да и брать крупный фреймворк, а затем осуждать его за чистую архитектуру тоже неправильно. Большинство из них активно используют эту парадигму для развязывая связей внутри себя. Это позволяет им быть коммерчески независимыми в случае непредвиденных ситуаций. Это сложный и дорогой процесс, но он необходим, чтобы Вы, как конечный разработчик, могли малыми усилиями творить большие и сложные проекты)
1. Зависит от того, куда Вы планируете идти. Приложения бывают разные и условия в них тоже.
Например, есть приложение, которое представляет из себя дашборд компании для внутреннего учета статистик и отображения сотрудникам. Предоставляет какие-то автоматизированные возможности документооборота и т. д. В общем, сосредоточено на бизнес задачах. Скорее всего на таком проекте дизайнера не будет, каких-то сложный визуалов тоже, а вот сделать быстро и дешево определенно руководство захочет. Поэтому там во главу угла встанут готовые UI библиотеки и на собесе Вас захотят на знание этого дела проверить.
Другой вариант, какой-то стартап направленный на публичность и клиентов с крутым дизайнером, который сделал то, что еще никто и никогда не делал. Модифицировать в таком случае готовые компоненты будет не рентабельно, поэтому для такого проекта Вас будут проверять на умение кастомной верстки.
Так же могут на какой-то проект искать человека, который бы вел библиотеку UI компонентов непосредственно для проектов компании. Там тоже нужно будет уметь верстать, но еще важнее - нужно будет хорошо знать как такие библиотеки строятся.
Так что в итоге - как Вам больше хочется, а тестовое все равно будете делать)
2. Если текст меняется раз в полгода, его проще захардкодить и предкомпилировать (Gatsby). Обычно на лендингах это так. Менять сезонные фразы и так далее проще просто на самом коде лендинга, а не тратить на это ресурсы сервера и базы. Плюс, не будет возникать ситуации, что текст не подгрузился) Как именно реализовывать - вариантов много. Я порекомендовал бы сразу писать бэк на NestJS, если вы с ним знакомы. NestJS имеет много чего готового, так что трудностей возникнуть не должно. Однако пишите сначала либо бэк, либо фронт. Как говорится, большого слона стоит жрать по частям)
3. TypeScript нужен всегда, привыкайте это брать за правило. Есть компании и команды, которые принципиально разрабатывают на JS, но это их дело и, возможно, у них есть на это причина. Для себя часто использую аналогию в плане JS, что он подобен ASM. По сути это низкоуровневый язык браузера. Однако зачем на нем писать? TS помогает программисту писать качественный и самодокументируемый код. Так же вносит определенный элемент строгости, потому что часто в большом проекте можно забыть и заслать что-то туда, куда это засылать не нужно. Плюс не забываем о маловажном, но полезном факте - TS дает возможность IDE предоставлять качественный статический анализ кода. Отсюда и автодополнения, и вспомогательные проверки и так далее. Например, поменяли модель, которая приходит с бэка. Изменили ее тип на фронте. А компилятор Вас сразу уведомит, что такой-то компонент у Вас теперь работает некорректно. Самодокументирование кода позволяет меньше запоминать и больше смотреть. Забыли, что принимает на вход какая-то функция? Не нужно смотреть в ее содержимое, достаточно посмотреть на тип аргумента. В JS для этого приходится документировать каждую функцию и описывать типы в комментариях) В целом, тут сказать можно еще много, но в основном TS обусловлен бизнес требованиями, а не какой-то производительностью и прочее. А работать приходится именно с бизнесом) К тому же, если Вы освоите TS - писать на JS тоже станет проще)
4. Работодатель всегда ищет человека на какую-то задачу. Никто не станет искать сотрудника просто так. А соответственно и тестировать Вас будут именно на эту задачу. Едва ли это будет интернет-магазин) Портфолио позволит лишь сложить первое впечатление о кандидате и понять, чем он увлекается. Поэтому лучше делать небольшие и тематические проекты, к которым лежит душа и про которые Вы можете что-то интересное рассказать. Разрабатывать огромный никому не нужный интернет-магазин это отчасти просто тратить время. Почитайте вакансии, попробуйте найти какие-то тестовые. Обычно они направлены на какую-то конкретную идею. Постарайтесь эту идею реализовать. Главное не попасться на тестовое, которое составил HR. Тогда оно будет просто типовое или скопированное с какого-то типового)
В остальном, удачи Вам в ваших начинаниях. Всегда лучше делать что-то, чем не делать ничего)
P. S. Извиняюсь за очепятки)
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
С точки зрения возможностей, то же можно сделать и в ООП, но само ООП больше заточено на мутабельную парадигму. Так зачем забивать саморезы молотком? Это возможно, но не нужно. ООП прекрасно нашло себе место на сервисном уровне реакт приложений. Там можно и DI себе организовать, и с декораторами поработать, и разделить бизнес логику, обернув ее в нужные шаблоны проектирования. В общем, чем бы дитя не тешилось.
В своей практике обычно использую связку React + React Query для визуализации. tsyringe и Mobx для организации сервисного уровня приложения. Mobx-State-Tree для описания и работы с моделями данных.
А касательно камней в огород Angular: стандартизация и строгость - это хорошо. Плохо, когда этого нет. Для того же существуют линтеры, форматеры, TypeScript, Golang и т. д. Когда проект становится сложным(архитектурно) и объемным в условиях бизнеса, необходимо внедрять много уровней контроля и стандартизации, чтобы кодовая база не превратилась в ад. Каждый разработчик зачастую пишет так, как ему хочется. Если на проекте несколько таких человек, то проект быстро превратится в картину абстракционистов. Один пишет в ООП парадигме, другой в ФП. Одному нравится Redux, другому Mobx, а третий вообще хочет использовать Effector. Тот еще цирк с конями. Angular же в свою очередь из коробки дает инструкцию как и что правильно делать (я не адепт ангуляра, люблю React, но хорошему фреймворку всегда готов отдать дань уважения). Любой новый разработчик на таком строгом проекте быстро вольется в стиль разработки команды. На таком проекте будет легко поддерживать чистоту кода, поскольку никто не изобретает велосипеды и все пользуются одинаковыми молотками. Задачи можно будет частично перекладывать с человека на человека и так далее. Это все уменьшает затраты на развитие и поддержку проекта. А чем меньше затрат - тем лучше для бизнеса) Стоит помнить, что за любым мало мальски серьезным проектом стоит бизнес. Все остальное в свободное время на личном сервере. Если что-то не приносит денег - этим не будут заниматься. Если что-то поглощает больше денег, чем нужно - от этого избавляются)
Поэтому "Чистая архитектура" это классно, но только в книжках) На практике все намного сложнее. Да и брать крупный фреймворк, а затем осуждать его за чистую архитектуру тоже неправильно. Большинство из них активно используют эту парадигму для развязывая связей внутри себя. Это позволяет им быть коммерчески независимыми в случае непредвиденных ситуаций. Это сложный и дорогой процесс, но он необходим, чтобы Вы, как конечный разработчик, могли малыми усилиями творить большие и сложные проекты)