Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 11
Хотелось бы побольше услышать про backend и вопросы авторизации. Хотя, судя по тому, что вы используете spring-data-rest, backend работает только как хранилище?
Это осталось за кадром, поскольку статья скорее про «React для java программистов», но в планах немного продолжить, и показать более сложный пример React + Spring Security + iFrame + RememberMe + MongoDB.
Было бы очень круто! Потому что между реактом и спрингом еще должен быть какой-то код для обмена данными, и именно его очень хотелось увидеть в этом посте, так хотелось, что аж до конца дочитал, а концовка как в «Борн: Эволюция» оказалась.
да, отчаянно плюсую.
у нас есть такие приложения (java+react), при выборе как делать — путей было множество
интересно увидеть как делают еще люди
особенно рассказы какие проблемы собрали те, кто пускают ноду и жс внутри джавы
у нас есть такие приложения (java+react), при выборе как делать — путей было множество
интересно увидеть как делают еще люди
особенно рассказы какие проблемы собрали те, кто пускают ноду и жс внутри джавы
Поделюсь своим опытом использования Spring + ReactJs.
Своё знакомство начал на проекте с gulp + browserify + reactjs + jee.
Несколько тасков в gulp:
— прод собирает бандл, минифицирует
— вариант сборки в папку application server
— вариант сборки с 'watch', когда мы запускаем процесс, а по ходу изменения в коде js -> сборочка автоматически кладётся в папку application server.
В итоге: работаем через watch, когда автоматом подсасывает изменения на сервер или руками запускаем таск.
Второй проект:
Webpack + ReactJs + Spring
— Один отдельный проект для java-script
— Второй отдельный проект для java
Имеется конфигурация для prod (сборка, минификация). Скриптом запускается процесс сборки, после сборки собранные файлики кладутся по месту дислокации в java.
[Запуск буквально обычным npm run build]
И имеется вариант для debug-разработки. (Включенные source-map). Смысл в том, что при каждом изменении сборка пересобирается, кладётся на сервер, В браузере можно дебажить js-код.
[Запуск с webpack --config ./webpack.dev.js --progress --watch]
Здесь пришлось пожертвовать плагином, который при пересборки рефрешил компоненты.
Есть ещё третий вариант, когда мы запускаем ноду в качестве сервера и с нею мы разрабатываем фронтэнд. Но в итоге отказался от этого, т.к. нужна зацепка за реально работающие rest-сервисы.
Своё знакомство начал на проекте с gulp + browserify + reactjs + jee.
Несколько тасков в gulp:
— прод собирает бандл, минифицирует
— вариант сборки в папку application server
— вариант сборки с 'watch', когда мы запускаем процесс, а по ходу изменения в коде js -> сборочка автоматически кладётся в папку application server.
В итоге: работаем через watch, когда автоматом подсасывает изменения на сервер или руками запускаем таск.
Второй проект:
Webpack + ReactJs + Spring
— Один отдельный проект для java-script
— Второй отдельный проект для java
Имеется конфигурация для prod (сборка, минификация). Скриптом запускается процесс сборки, после сборки собранные файлики кладутся по месту дислокации в java.
[Запуск буквально обычным npm run build]
И имеется вариант для debug-разработки. (Включенные source-map). Смысл в том, что при каждом изменении сборка пересобирается, кладётся на сервер, В браузере можно дебажить js-код.
[Запуск с webpack --config ./webpack.dev.js --progress --watch]
Здесь пришлось пожертвовать плагином, который при пересборки рефрешил компоненты.
Есть ещё третий вариант, когда мы запускаем ноду в качестве сервера и с нею мы разрабатываем фронтэнд. Но в итоге отказался от этого, т.к. нужна зацепка за реально работающие rest-сервисы.
Блин, поздно заметил комментарий и не могу лайкнуть уже.
У меня такое ощущение, что это нужно всё оформлять в виде набора спринговых бинов, и открывать проект типа Spring Cloud Reactive
мы слишком много времени тратим на всю эту девопс-фигню, которая исходя из понимания правильного девопса как раз должна быть заоптимизирована в ноль, сведена к какой-нибудь аннотации и плагину для hotswapagent
У меня такое ощущение, что это нужно всё оформлять в виде набора спринговых бинов, и открывать проект типа Spring Cloud Reactive
мы слишком много времени тратим на всю эту девопс-фигню, которая исходя из понимания правильного девопса как раз должна быть заоптимизирована в ноль, сведена к какой-нибудь аннотации и плагину для hotswapagent
Слишком коротко написано. Имхо.
Спасибо, было познавательно
Я так понимаю – суть статьи в том, как ложить/собирать сорцы фронтенда в java-проекте?
Зачем это? Могу понять кейс только если вы где-то используете MVC+шаблонизатор для вставки каких-то больших динамических кусков, только при чем тут React тогда?:)
Иначе, как мне кажется, правильно организовать все следующим образом:
1. Spring Boot торчит наружу rest-api который используется фронтендом.
2. Фронтенд находится в отдельном проекте, собирается отдельно чем душе угодно, итоговые js/css ассеты ложатся на CDN.
3. Spring Boot отдает наружу index в котором есть ровно две ссылки – на cdn с js и css.
4. Крайне желательно сразу настроить cache bust для всех ассетов чтобы избежать проблем с CDN и кеширующими прокси тут и там. Для бекенда сделать какие-то dynamic properties чтобы при обновлении отдавалось то что нужно.
Зачем это? Могу понять кейс только если вы где-то используете MVC+шаблонизатор для вставки каких-то больших динамических кусков, только при чем тут React тогда?:)
Иначе, как мне кажется, правильно организовать все следующим образом:
1. Spring Boot торчит наружу rest-api который используется фронтендом.
2. Фронтенд находится в отдельном проекте, собирается отдельно чем душе угодно, итоговые js/css ассеты ложатся на CDN.
3. Spring Boot отдает наружу index в котором есть ровно две ссылки – на cdn с js и css.
4. Крайне желательно сразу настроить cache bust для всех ассетов чтобы избежать проблем с CDN и кеширующими прокси тут и там. Для бекенда сделать какие-то dynamic properties чтобы при обновлении отдавалось то что нужно.
Создайте файл static\.babelrc со следующим содержанием (как не трудно догадаться, это конфигурация Babel):
Лайфак:
If you’re writing a Babel beginner tutorial please use package.json instead of .babelrc. Hidden files are so easy to miss.(Dan Abramov)
Для тех, кто впервые сталкивается с React — слишком коротко и поверхностно. Бэк и его взаимодействие с фронтом не затронуты вообще.
Собственно, статья называется «Первое приложение на Spring Boot + ReactJS», но итогового работающего приложения нет.
Собственно, статья называется «Первое приложение на Spring Boot + ReactJS», но итогового работающего приложения нет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Первое приложение на Spring Boot + ReactJS