Комментарии 14
Задепрекейченный "create-react-app" и "componentDidMount() {}" в статье, затрагивающей React, в 2025 году выглядит интересно))
Просто лежала в черновиках 5-10 лет
я видел в районе 5и крупных проектов на React и гораздо больше мелких и не один из них не был похож на другой по архитектурным решениям, где-то использовались классы, где-то хуки, где-то контекст, где-то одна из реализаций сторов. Что бы вы не написали про эту технологию найдется тот, кто скажет, что сейчас так делать уже не принято
Зачем здесь эта статья? Положите её лучше в курсы гикбренса или скиллбокса
«…стандартными решениями являются React, Next, Angular, Vue, Express…»
Express в списке frontend фреймворков?
по-моему опыту React является одной из наименее гибких из фронтенд технологий и эта его сторона часто преподносится как достоинство хардкод решений, когда можно зарефакторить половину кодовой базы одним махом и быть в относительной уверенности, что она после исправлений за линтером не развалится. В Vaadin вы можете выполнить JavaScript код на любом элементе, кастомизировать его по общим правилам html стандартов и технологий таких как css, shadow dom, слоты, а в React вам будет доступен только локальный внутренний API компонента.
Custom Elements не является подобием компонентов React, а реализует браузерный стандарт, который разрабатывался конечно с некоторой оглядкой на него(отсюда хуки componentDidMount), но несколько позднее и включает многие возможности современного HTML, таких как обзервабилити атрибутов, поддержка нативных браузерных событий, data-атрибутов.
React это библиотека (не фреймворк), единственной задачей которой является предоставление возможности реактивно пересчитывать DOM страницы согласно написанным вами компонентам. Я понимаю, что в сравнении с вашим java-фреймворком у реакта всегда будет "фатальный недостаток" ©, но говорить, что он негибок и не даёт что-то сделать - максимально странно.
React это библиотека (не фреймворк)
это популярное клише, но на деле библиотека это код, который вы можете использовать в своем приложении для решения конкретной задачи, например работы с json/xml файлами. А фреймворк - каркас и инструменты для организации собственного бизнесового кода в приложение накладывающий определенные соглашения на его оформление.
но говорить, что он негибок и не даёт что-то сделать - максимально странно
React не использует ничего из общепринятых инструментов для понижения связности кода: отрицает DI/IoC, Инкапсуляцию через наследование(классов), Шаблоны поэтому любое изменение в нем требует модификации кода(часто массированной), явных решений, дублирования(когда вы перечисляете пропсы там и тут), что не позволяет засчитать ему высокий уровень гибкости. Вместо этого его подсистемы часто тащат свои решения которые градус хардкода только повышают. Например, сторы всегда требовалось биндить явно в компоннетах, а контекст вынуждает компоненты оборачивать в свои конструктции прямо в jsx.
Я повторяю - React это не экосистема и не фреймворк, это просто библиотека слоя отображения, все остальное, включая общую архитектуру приложения определяете вы сами, и если на выходе у вас получается то, что вам не нравится, то пенять нужно не на библиотеку.
А фреймворк - каркас и инструменты для организации собственного бизнесового кода в приложение накладывающий определенные соглашения на его оформление.
И реакт ничего из этого не делает, поэтому он и не является фреймворком. Вы никак не ограничены решениями архитектуры, работы с бизнес-логикой, навигацией и всем остальным. Мне кажется, что вы все ещё не понимаете, что все что можно нагуглить со словом "реакт" не является его частью, а является написанными с его помощью (или для работы с ним) решениями сторонних разработчиков.
ни разу не видел, чтобы реакт использовали именно как библиотеку, да и его особенности, в частности, рендеринга не позволяют его сочетать с другими фреймворками. Все используют реакт чтобы создать SPA или что-то в таком роде. При этом выкидывают jquery и остальные технологии если они использовались, вместо них лепят свои велосипеды или берут реакт-аналоги. Например, свою реализацию слотов или инструмент для стилей. А если хотят у себя сделать "как в реакте" используют какой-нибудь клон его решений, например rx-сторы для ангуляра и вуе.
И реакт ничего из этого не делает, поэтому он и не является фреймворком.
прежде всего, он обязывает код организовывать вокруг его компонентной модели и жизненного цикла, не позволяет удобно использовать нативные эвенты, классы. Вы можете выбирать только между одними реакт-решениеми и другими.
Вы продолжаете обвинять в плохих решениях разработчиков библиотеку, которую они используют. Вы называете библиотеку фреймворком, а потом предъявляете ей - "что-то ты хреновый фреймворк".
jQ в реакт-проекте действительно не нужен, потому что и первый и второй - библиотеки для манипулирования DOM, и при использовании одного второй вам уже просто не нужен. Что касается стилей, то реакт, опять же, вообще никак не определяет/ограничивает вас в том как вы будете с ними работать, можете использовать все что угодно в пределах разумного. Почему вы говорите "как в реакт" про rx-store я решительно не понимаю, это наоборот попытка принести работу с потоком из экосистемы ангуляра в приложения, написанные с использованием реакта. В самом реакте вообще нет понятия стора, только внутреннего стейта компонента, а стор уже привносится сторонними решениями (именно потому что реакт это просто библиотека управления DOM)
Вот при всем моем уважении и без какого-либо негатива в вашу сторону - давайте на этом закончим, я не вижу смысла в этой дискуссии)
Во-вторых, мы находимся в Java. Получается, что сессия — Java-объект. Большой и объемный Java-объект, который имеет много ссылок на другие Java-объекты. Таким образом, размер сессии может спокойно достигать нескольких мегабайтов.
Задачи корпоративного приложения могут потребовать хранения большого количества сессионных параметров. Мне приходилось например видеть такие требования, что надо было обеспечивать полное восстановление состояния экрана(данных формы, фильтров и т.д.) при переходе назад или случайном закрытии окна. В случае если у вас нет такой интеграции вы будете пилить велосипеды реализующие то же самое и возможно даже в конце концов включите липкие сессии в рамках борьбы за консистентность данных и производительность.
В то же время типичное корпоративное приложение в отличии от публичного сервиса как VK имеет обычно вполне определенное количество пользователей, что позволяет оценить системные требования.
React обладает одним из самых больших комьюнити в мире фронтенд-разработки. Огромное количество готовых решений, ответов на вопросы на форумах и найденных обходных решений могут быть найдены по первой ссылке запроса в Google.
решения React часто несовместимы друг с другом(не говоря уже про остальные фронтенд технологии) из-за постоянных изменений в инфраструктуре и отсутствия ее стандартизации. Если сомневаетесь попробуйте использовать компоненты из Antd вместе с Material или модули использующие разные решения для управления состоянием. В тоже время у Vaadin есть приличный репозиторий готовых компонентов, которые вы можете использовать в Jmix https://vaadin.com/directory/ и вообще можете прикручивать сторонние JavaScript библиотеки не боясь, что какой-нибудь перерендеринг как в React будет их ломать. Некоторые аддоны Jmix написаны обертками к JS-библиотекам и существует отработанная методология интеграции с любыми другими. Опять же в личной практике я видел как от использования библиотеки готовых компонентов разработчики на большом React-проекте переходили к переписыванию кода на собственных компонентах, потому что она внезапно комерциализировалась, была тяжелой и бажной. Готовые решения распространялись кусками через личку телеграма между "своими" и кочевали от проекта к проекту позволяя паразитировать на велосипедостроении
Не только React: сравнительный анализ React и Jmix для написания UI бизнес-приложений