Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/dsyer/spring-boot-js-demo
These samples explore the different options that Spring Boot developers have for using Javascript and CSS on the client (browser) side of their application.
https://github.com/dsyer/spring-boot-js-demo
javascript spring spring-boot
Last synced: about 2 months ago
JSON representation
These samples explore the different options that Spring Boot developers have for using Javascript and CSS on the client (browser) side of their application.
- Host: GitHub
- URL: https://github.com/dsyer/spring-boot-js-demo
- Owner: dsyer
- Created: 2021-12-13T14:36:03.000Z (about 3 years ago)
- Default Branch: main
- Last Pushed: 2024-01-16T14:12:58.000Z (11 months ago)
- Last Synced: 2024-10-12T06:16:13.660Z (2 months ago)
- Topics: javascript, spring, spring-boot
- Language: Java
- Homepage:
- Size: 293 KB
- Stars: 32
- Watchers: 2
- Forks: 7
- Open Issues: 0
-
Metadata Files:
- Readme: README.adoc
Awesome Lists containing this project
README
:toc: auto
These samples explore the different options that Spring Boot developers have for using Javascript and CSS on the client (browser) side of their application. Part of the plan is to explore some Javascript libraries that play well in the traditional server-side-rendered world of Spring web applications. Those libraries tend to have a light touch for the application developer, in the sense that they allow you to completely avoid Javascript, but still have nice a progressive "modern" UI. We also look at some more "pure" Javascript tools and frameworks. It's kind of a spectrum, so as a TL;DR here is a list of the sample apps, in rough order of low to high Javascript content:
* `htmx`: https://htmx.org[HTMX] is a library that allows you to access modern browser features directly from HTML, rather than using javascript. It is very easy to use and well suited to server-side rendering because it works by replacing sections of the DOM directly from remote responses. It seems to be well used and appreciated by the https://www.python.org/[Python] community.
* `turbo`: https://turbo.hotwired.dev/[Hotwired] (Turbo and Stimulus). Turbo is a bit like HTMX. It is widely used and supported well in https://rubyonrails.org/[Ruby on Rails]. Stimulus is a lightweight library that can be used to implement tiny bits of logic that prefer to live on the client.
* `vue`: https://vuejs.org[Vue] is also very lightweight and describes itself as "progressive" and "incrementally adoptable". It is versatile in the sense that you can use a very small amount of Javascript to do something nice, or you can push on through and use it as a full-blown framework.
* `react-webjars`: uses the https://reactjs.org[React] framework, but without a Javascript build or bundler. React is nice in that way because, like Vue, it allows you to just use it in a few small areas, without it taking over the whole source tree.
* `nodejs`: like the `turbo` sample but using https://nodejs.org[Node.js] to build and bundle the scripts, instead of https://webjars.org[Webjars]. If you get serious about React, you will probably end up doing this, or something like it. The aim here is to use Maven to drive the build, at least optionally, so that the normal Spring Boot application development process works. Gradle would work the same.
* `react`: is the `react-webjars` sample, but with the Javascript build steps from the `nodejs` sample.
There is another sample using Spring Boot and HTMX https://github.com/dsyer/todowebflux[here]. HTMX is a very powerful tool for building a UI composed of a number of backend services accessed through a gateway, and there is a sample of that pattern https://github.com/dsyer/frontend-microservices[here], implemented with Mustache and Thymeleaf. If you want to know more about React and Spring there is a https://spring.io/guides/tutorials/react-and-spring-data-rest/[tutorial on the Spring website]. There is also content on https://angular.io[Angular] via another https://spring.io/guides/tutorials/spring-security-and-angular-js/[tutorial on the Spring website] and the related getting started content https://github.com/dsyer/spring-boot-angular[here]. If you are interested in Angular and Spring Boot https://github.com/mraible[Matt Raible] has a https://www.infoq.com/minibooks/angular-mini-book/[Minibook]. The https://spring.io[spring.io] website (https://github.com/spring-io/sagan[source code]) is also a Node.js build and uses a completely different toolchain and set of libraries. Another source of alternative approaches is https://www.jhipster.tech/[JHipster] which also has support for a few of the libraries used here. Finally the https://github.com/spring-projects/spring-petclinic[Petclinic], while it has no Javascript, does have some client side code in the stylesheets and a build process driven from Maven.
## Getting Started
All the samples can be built and run with standard Spring Boot processes (e.g. see https://spring.io/guides/gs/spring-boot/[this getting started guide]). The Maven wrapper is in the parent directory so from each sample on the command line you can `../mvnw spring-boot:run` to run the apps or `../mvnw package` to get an executable JAR. E.g.
```
$ cd htmx
$ ../mvnw package
$ java -jar target/js-demo-htmx-0.0.1.jar
. ____ _ __ _ _
/\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
\\/ ___)| |_)| | | | | || (_| | ) ) ) )
' |____| .__|_| |_|_| |_\__, | / / / /
=========|_|==============|___/=/_/_/_/
:: Spring Boot :: (v3.1.1)
2021-12-08 08:50:30.517 INFO 2385363 --- [ main] com.example.jsdemo.JsDemoApplication : Starting JsDemoApplication using Java 11.0.7 on tower with PID 2385363 (/home/dsyer/dev/demo/workspace-daily/js-demo/target/classes started by dsyer in /home/dsyer/dev/demo/workspace-daily/js-demo)
2021-12-08 08:50:30.519 INFO 2385363 --- [ main] com.example.jsdemo.JsDemoApplication : No active profile set, falling back to default profiles: default
2021-12-08 08:50:31.501 DEBUG 2385363 --- [ main] s.w.r.r.m.a.RequestMappingHandlerMapping : 6 mappings in 'requestMappingHandlerMapping'
2021-12-08 08:50:31.519 DEBUG 2385363 --- [ main] o.s.w.r.handler.SimpleUrlHandlerMapping : Patterns [/webjars/**, /**, /node_modules/**] in 'resourceHandlerMapping'
2021-12-08 08:50:31.641 DEBUG 2385363 --- [ main] o.s.w.r.r.m.a.ControllerMethodResolver : ControllerAdvice beans: none
2021-12-08 08:50:31.666 DEBUG 2385363 --- [ main] o.s.w.s.adapter.HttpWebHandlerAdapter : enableLoggingRequestDetails='false': form data and headers will be masked to prevent unsafe logging of potentially sensitive data
2021-12-08 08:50:31.829 INFO 2385363 --- [ main] o.s.b.web.embedded.netty.NettyWebServer : Netty started on port 8080
2021-12-08 08:50:31.841 INFO 2385363 --- [ main] com.example.jsdemo.JsDemoApplication : Started JsDemoApplication in 0.97 seconds (JVM running for 1.209)
```
The project works well in https://docs.github.com/en/codespaces[Codespaces] and was developed mostly locally with https://code.visualstudio.com/docs/languages/java[VSCode]. Feel free to use whatever IDE you prefer though, they should all work fine.
## Narrowing the Choices
Browser application development is a huge landscape of ever-changing options and choices. It would be impossible to present all those options in one coherent picture, so we have intentionally limited the scope of tools and frameworks we look at. We start with a bias of wanting to find something that works with a light touch, or is at least incrementally adoptable. There is also the previously mentioned bias towards libraries that work well with server-side renderers - those that deal with fragments and subtrees of HTML. Also, we have used Javascript https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules[ESM] wherever possible, since most browsers now support that. However, most libraries that publish a module to `import` also have an equivalent bundle you can `require`, so you can always stick to that if you prefer.
Many of the samples use https://webjars.org[Webjars] to deliver the Javascript (and CSS) assets to the client. This is very easy and sensible for an application with a Java backend. Not all the samples use Webjars though, and it wouldn't be hard to convert the ones that do to either use a CDN (like https://unpkg.com[unpkg.com] or https://jsdeliver.com[jsdelivr.com]) or a build time Node.js bundler. The samples here that do have a bundler use https://rollupjs.org/guide/en/[Rollup], but you could just as well use https://webpack.js.org/[Webpack], for instance. They also use straight https://www.npmjs.com/[NPM] and not https://classic.yarnpkg.com/[Yarn] or https://gulpjs.com/[Gulp], which are both popular choices. All the samples use https://getbootstrap.com/[Bootstrap] for CSS, but other choices are available.
There are also choices that can be made on the server side. We have used https://docs.spring.io/spring-framework/docs/current/reference/html/web-reactive.html#spring-webflux[Spring Webflux] but https://docs.spring.io/spring-framework/docs/current/reference/html/web.html#spring-web[Spring MVC] would work identically. We have used Maven as a build tool, but using Gradle it would be easy to achieve the same goals. All the samples actually have a static home page (not even rendered as a template), but they all have some dynamic content, and we have chosen https://github.com/samskivert/jmustache[JMustache] for that. https://www.thymeleaf.org/[Thymeleaf] (and other templating engines) would work just as well. In fact Thymeleaf has built-in support for fragments and that can be quite useful when you are updating parts of a page dynamically, which is one of our goals. You could do that same with Mustache (probably) with a bit of work, but we didn't need it in these samples.
## Create a New Application
To get started with Spring Boot and client-side development, let's start at the beginning, with an empty app from https://start.spring.io[Spring Initializr]. You can go to the website and download a project with web dependencies (select Webflux or WebMVC) and open it up in your IDE. Or to generate a project from the command line you can use `curl`, starting form an empty directory:
```
$ curl https://start.spring.io/starter.tgz -d dependencies=webflux -d name=js-demo | tar -xzvf -
```
We can add a really basic static home page at `src/main/resources/static/index.html`:
```html
Demo
Demo
Hello World
```
and then run the app:
```
$ ./mvnw package
$ java target/js-demo-0.0.1-SNAPSHOT.jar
```
and you can see the result on http://localhost:8080[localhost:8080].
### Webjars
To start building client-side features, let's add some CSS out of the box from Bootstrap. We could use a CDN, like this for example in `index.html`:
```html
...
...
...
```
That's really convenient, if you want to get started quickly. For some apps it might be all you need. Here we take a different approach that makes our app more self-contained, and aligns well with the Java tooling we are used to - that is to use a Webjar and package the Bootstrap libraries in our JAR file. To do that we need to add a couple of dependencies to the `pom.xml`:
```xml
org.webjars
webjars-locator-core
org.webjars.npm
bootstrap
5.1.3
```
and then in `index.html` instead of the CDN we use a resource path inside the application:
```html
...
...
...
```
If you rebuild and/or re-run the application you will see nice vanilla Bootstrap styles instead of the boring default browser versions. Spring Boot uses the `webjars-locator-core` to locate the version and exact location of the resource in the classpath, and the browser sucks that stylesheet into the page.
### Show Me Some Javascript
Bootstrap is also a Javascript library, so we can start to use it more fully by taking advantage of that. We can add the Bootstrap library in `index.html` like this:
```html
...
...
...
```
It doesn't do anything visible yet, but you can verify that it is loaded by the browser using the devtools view (F12 in Chrome or Firefox).
We said in the introduction that we would use ESM modules where available, and Bootstrap has one, so let's get that working. Replace the `` tag in `index.html` with this:
```html
<script type="importmap">
{
"imports": {
"bootstrap": "/webjars/bootstrap/dist/js/bootstrap.esm.min.js"
}
}
import 'bootstrap';
```
There are two parts to this: an "importmap" and a "module". The import map is a feature of the browser allowing you to refer to ESM modules by name, mapping the name to a resource. If you run the app now and load it in the browser there should be an error in the console because the ESM bundle of Bootstrap has a dependency on https://popper.js.org/[PopperJS]:
```
Uncaught TypeError: Failed to resolve module specifier "@popperjs/core". Relative references must start with either "/", "./", or "../".
```
PopperJS is not a mandatory transitive dependency of the Bootstrap Webjar, so we have to include it in our `pom.xml`:
```xml
org.webjars.npm
popperjs__core
2.10.1
```
(Webjars use the "__" infix instead of a "@" prefix for namespaced NPM module names.) Then it can be added to the import map:
```html
{
"imports": {
"bootstrap": "/webjars/bootstrap/dist/js/bootstrap.esm.min.js",
"@popperjs/core": "/webjars/popperjs__core/lib/index.js"
}
}
```
and this will fix the console error.
### Normalizing Resource Paths
The resource paths inside a Webjar (e.g. `/bootstrap/dist/js/bootstrap.esm.min.js`) are not standardized - there is no naming convention that allows you to guess the location of the ESM module inside a Webjar, or an NPM module which amounts to the same thing. But there are some conventions in NPM modules that make it possible to automate: most modules have a `package.json` with a "module" field. E.g. from Bootstrap you can find the version and the module resource path:
```json
{
"name": "bootstrap",
"description": "The most popular front-end framework for developing responsive, mobile first projects on the web.",
"version": "5.1.3",
...
"module": "dist/js/bootstrap.esm.js",
...
}
```
CDNs like unpkg.com make use of this information, so you can use them when you know only the ESM module name. E.g. this should work:
```html
{
"imports": {
"bootstrap": "https://unpkg.com/bootstrap",
"@popperjs/core": "https://unpkg.com/@popperjs/core"
}
}
```
It would be nice to be able to do the same with `/webjars` resource paths. That's what the `NpmVersionResolver` in all the samples does. You don't need it if you don't use Webjars and you can use a CDN, and you don't need it if you don't mind manually opening up all the `package.json` files and looking for the module path. But it's nice to not have to think about that. There's a https://github.com/spring-projects/spring-boot/issues/28715[feature request] asking for this to be included in Spring Boot. Another feature of the `NpmVersionResolver` is that it knows about the Webjars metadata, so it can resolve the version of each Webjar from the classpath, and we don't need that `webjars-locator-core` dependency (there's an https://github.com/spring-projects/spring-framework/issues/27619[open issue in Spring Framework] to add this feature).
So in the sample the import map is like this:
```html
{
"imports": {
"bootstrap": "/npm/bootstrap",
"@popperjs/core": "/npm/@popperjs/core"
}
}
```
All you need to know is the NPM module name, and the resolver figures out how to find a resource that resolves to the ESM bundle. It uses a Webjar if there is one, and otherwise redirects to a CDN.
NOTE: Most modern browsers support modules and module maps. Those that don't can be used in our app at the cost of adding a https://www.npmjs.com/package/es-module-shims[shim library]. It is already included in the samples.
### Adding Tabs
We might as well use the Bootstrap styles now we have it all working. So how about some tabs with content and a button or two to press? Sounds good. First the `` with the tab links in `index.html`:
```html
Demo
Message
Stream
```
The second (default inactive) tab is called "stream" because part of the samples will be exploring the use of Server Sent Event streams. The tab contents look like this in the `` section:
```html
Hello World!
Nothing here yet...
```
Note how one of the tabs is "active" and both have ids that match up with the `data-bs-target` attributes in the header. That's why we need some Javascript - to handle the click events on the tabs so that the correct content is revealed or hidden. The https://getbootstrap.com/docs/5.1/getting-started/introduction/[Bootstrap docs] have loads of examples of different tab styles and layouts. One nice thing about the basic features here is that they can automatically render as drop downs on a narrow device like a mobile phone (with some small changes to the class attributes in the `` - you can look at the https://github.com/spring-projects/spring-petclinic[Petclinic] to see how). In a browser it looks like this:
image::images/tabs.png[]
and of course if you click on the "Stream" tab it reveals some different content.
## Dynamic Content with HTMX
We can add some dynamic content really quickly with HTMX. First we need the Javascript library, so we add it as a Webjar:
```xml
org.webjars.npm
htmx.org
1.6.0
```
and then import it in `index.html`:
```html
{
"imports": {
"bootstrap": "/npm/bootstrap",
"@popperjs/core": "/npm/@popperjs/core",
"htmx": "/npm/htmx.org"
}
}
import 'bootstrap';
import 'htmx';
```
Then we can change the greeting from "Hello World" to something that comes from user input. Let's add an input field and a button to the main tab:
```html
Hello World
Greet
```
The input field is unadorned, and the button has some `hx-*` attributes that are grabbed by the HTMX library and used to enhance the page. These ones say "when user clicks on this button, send a POST to `/greet`, including the 'name' in the request, and render the result by replacing the content of the 'greeting'". If the user enters "Foo" in the input field, the POST has a form-encoded body of `value=Foo` because "value" is the name of the field identified by `#name`.
Then all we need is a `/greet` resource in the backend:
```java
@SpringBootApplication
@RestController
public class JsDemoApplication {
@PostMapping("/greet")
public String greet(@ModelAttribute Greeting values) {
return "Hello " + values.getValue() + "!";
}
...
static class Greeting {
private String value;
public String getValue() {
return value;
}
public void setValue(String value) {
this.value = value;
}
}
}
```
Spring will bind the "value" parameter in the incoming request to the `Greeting` and we convert it to text which is then injected in the `
` on the page. You can use HTMX to inject plain text like this, or whole fragments of HTML. Or you can append (or prepend) to a list of existing elements, like rows in a table, or items in a list. You can also use a `` in place of the container `` above, and then you don't need `hx-include` (HTMX just sends all the form data).
Here's another thing you can do:
```html
Unauthenticated
...
```
This does a GET to `/user` when the page loads and swaps the content of the element. The sample app has this endpoint and it returns "Fred" so you see it rendered like this:
image::images/user.png[]
### HTMX Triggers
In addition to page event (like "load" in the example above), the backend can send a response header `Hx-Trigger` to fire additional events in the client. In this way you can add nice pop-up notifications, or update other parts of the page. For example, you might add this to the backend:
```java
@GetMapping("/notify")
public ResponseEntity notification() throws Exception {
return ResponseEntity.status(HttpStatus.CREATED)
.header("HX-Trigger", mapper.writeValueAsString(Map.of("notice", "Notification"))).build();
}
```
The `mapper` is a Jackson `ObjectMapper` because the `HX-Trigger` header is encoded in JSON (or just a plain string which is the name of the event to fire). When you `hx-get="/notify"` the client will fire an event which you can listen for and handle in Javascript. For example:
```javascript
import { Toast } from 'bootstrap';
import 'htmx';
htmx.on("notice", (e) => {
document.getElementById("toast-body").innerText = e.detail.value;
new Toast(document.getElementById("toast"), { delay: 2000 }).show();
});
```
The example above used a `Void` response body, but more commonly you'll want to return some data, like a view to render and HTML template and replace some content in the page.
### SSE Streams
There are many other neat things you can do with HTMX, and one of those is to render a https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events#event_stream_format[Server Sent Event (SSE)] stream. First we'll add an endpoint to the backend app:
```java
@SpringBootApplication
@RestController
public class JsDemoApplication {
@GetMapping(path = "/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public Flux stream() {
return Flux.interval(Duration.ofSeconds(5)).map(
value -> value + ":" + System.currentTimeMillis()
);
}
...
}
```
So we have a stream of messages rendered by Spring by virtue of the `produces` attribute on the endpoint mapping:
```
$ curl localhost:8080/stream
data:0:1639472861461
data:1:1639472866461
data:2:1639472871461
...
```
HTMX can inject those messages into our page. Here's how in `index.html` added to the "stream" tab:
```html
```
We connect to the `/stream` using the `connect:/stream` attribute and then pull event data out using `swap:message`. Actually "message" is the default event type, but SSE payloads can also specify other types by including a line starting with `event:`, and so you could have a stream that multiplexes many different event types and have them each affect the HTML in different ways.
The endpoint in our backend above is very simple: it just sends back plain strings, but it could do more. E.g. it could send back fragments of HTML and they would be injected into the page. The sample applications do it with a custom Spring Webflux component named `CompositeViewRenderer` (requested as a feature https://github.com/spring-projects/spring-framework/issues/27652[here] for the Framework), where `@Contoller` method can return a `Flux` (in MVC it would be `Flux`). It enables an endpoint to stream dynamic views:
```java
@GetMapping(path = "/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public Flux stream() {
return Flux.interval(Duration.ofSeconds(5)).map(value -> Rendering.view("time")
.modelAttribute("value", value)
.modelAttribute("time", System.currentTimeMillis()).build());
}
```
This is paired with a view named "time" and the normal Spring machinery renders the model:
```
$ curl localhost:8080/stream
data:
Index: 0, Time: 1639474490435
data:
Index: 1, Time: 1639474495435
data:
Index: 2, Time: 1639474500435
...
```
The HTML comes from a template `time.mustache` in `src/main/resources/templates`:
```html
Index: {{value}}, Time: {{time}}
```
which in turn works automatically because we included JMustache on the classpath in `pom.xml`:
```xml
org.springframework.boot
spring-boot-starter-mustache
```
### Replacing and Enhancing HTML Dynamically
HTMX can still do more. Instead of an SSE stream, an endpoint can return a regular HTTP response, but compose it as a set of elements to swap on the page. HTMX calls this an "out of band" swap because it involves enhancing content of elements on the page that are not the same as the one that triggered the download.
To see this work we can add another tab with some HTMX-enabled content:
```html
Fetch
```
Don't forget to add a nav link so the user can see this tab:
```html
...
Test
...
```
The new tab has a button that fetches dynamic content from `/test` and it also sets up 2 empty divs "hello" and "world" to receive the content. The `hx-swap="none"` is important - it tells HTMX not to replace the content of the element that triggered the GET.
If we have an endpoint that returns this:
```
$ curl localhost:8080/test
Hello
World
```
then the page renders like this (after the "Fetch" button is pressed):
image::images/test.png[]
A simple implementation of this endpoint would be
```java
@GetMapping(path = "/test")
public String test() {
return "
Hello\n"
+ "World";
}
```
or (using the custom view renderer):
```java
@GetMapping(path = "/test")
public Flux test() {
return Flux.just(
Rendering.view("test").modelAttribute("id", "hello")
.modelAttribute("value", "Hello").build(),
Rendering.view("test").modelAttribute("id", "world")
.modelAttribute("value", "World").build());
}
```
with a template "test.mustache":
```html
{{value}}
```
### Boosting Links and Forms
Another thing that HTMX does is "boost" all the links and form actions in your page, so that they automatically work using an XHR request instead of a full page refresh. That's a really simple way to segment your page by feature and update only the bits that you need. You can also easily do that in a "progressive" way - i.e. the application works with full page refreshes if Javascript is disabled, but is zippier and feels more "modern" if Javascript is enabled.
## Dynamic Content with Hotwired
Hotwired is a little bit similar to HTMX, so let's replace the libraries an get the app working. Take out HTMX and add Hotwired (Turbo) to the application. In `pom.xml`:
```xml
org.webjars.npm
hotwired__turbo
7.1.0
```
Then we can import it into our page by adding an import map:
```html
{
"imports": {
...
"@hotwired/turbo": "/npm/@hotwired/turbo"
}
}
```
and a script to import the library:
```html
import * as Turbo from '@hotwired/turbo';
```
### Replacing and Enhancing HTML Dynamically
This lets us do the dynamic content stuff that we already did with HTMX with a few changes to the HTML. Here's the "test" tab in `index.html`:
```html
Fetch
```
Turbo works a little differently than HTMX. The `` tells Turbo that everything inside is enhanced (a bit like an HTMX boost). And to replace the "hello" and "world" elements on a button click, we need the button to send a POST through a form, not just a plain GET (Turbo is more opinionated about this than HTMX). The `/test` endpoint then sends back some `` fragments containing templates with the content we want to replace:
```html
Hi Hello!
Hi World!
```
To make Turbo take notice of the incoming `` we need the `/test` endpoint to return a custom `Content-Type: text/vnd.turbo-stream.html` so the implementation looks like this:
```java
@PostMapping(path = "/test", produces = "text/vnd.turbo-stream.html")
public Flux test() {
return ...;
}
```
To serve the custom content type we need a custom view resolver:
```java
@Bean
@ConditionalOnMissingBean
MustacheViewResolver mustacheViewResolver(Compiler mustacheCompiler, MustacheProperties mustache) {
MustacheViewResolver resolver = new MustacheViewResolver(mustacheCompiler);
resolver.setPrefix(mustache.getPrefix());
resolver.setSuffix(mustache.getSuffix());
resolver.setViewNames(mustache.getViewNames());
resolver.setRequestContextAttribute(mustache.getRequestContextAttribute());
resolver.setCharset(mustache.getCharsetName());
resolver.setOrder(Ordered.LOWEST_PRECEDENCE - 10);
resolver.setSupportedMediaTypes(
Arrays.asList(MediaType.TEXT_HTML, MediaType.valueOf("text/vnd.turbo-stream.html")));
return resolver;
}
```
The above is a copy of the `@Bean` defined automatically by Spring Boot but with an additional supported media type. There is an open https://github.com/spring-projects/spring-boot/issues/28858[feature request] to allow this to be done via `application.properties`.
The result of clicking the "Fetch" button should be to render "Hello" and "World" as before.
### Server Sent Events
Turbo also has built in support for SSE rendering, but this time the event data has to have `` elements in it. For example:
```
$ curl localhost:8080/stream
data:
data:
data:
Index: 0, Time: 1639482422822
data:
data:
data:
data:
data:
Index: 1, Time: 1639482427821
data:
data:
```
Then the "stream" tab just needs an empty `
` and Turbo will do what it was asked (replace the element identified by "load"):
```html
```
Both Turbo and HTMX allow you to target elements for dynamic content by id or by CSS style matcher, both for regular HTTP responses and SSE streams.
### Stimulus
There is another library in Hotwired called https://stimulus.hotwired.dev[Stimulus] that lets you add more customized behaviour using small amounts of Javascript. It comes in handy if you have an endpoint in your backend service that returns JSON not HTML, for instance. We can get started with Stimulus by adding it as a dependency in `pom.xml`:
```xml
org.webjars.npm
hotwired__stimulus
3.0.1
```
and with an import map in `index.html`:
```html
{
"imports": {
...
"@hotwired/stimulus": "/npm/@hotwired/stimulus"
}
}
```
Then we are in good shape to replace the piece of the main "message" tab that we did with HTMX before. Here's the tab content covering just the button and custom message:
```html
Hello World
Greet
```
Notice the `data-*` attributes. There is a `controller` ("hello") declared on the container `
` that we need to implement. Its action in the button element says "when this button is clicked, call the function 'greet' on the 'hello' controller". And there are some decorations that identify which elements have input and output for the controller (the `data-hello-target` attributes). The Javascript to implement the custom message renderer looks like this:
```html
import { Application, Controller } from '@hotwired/stimulus';
window.Stimulus = Application.start();
Stimulus.register("hello", class extends Controller {
static targets = ["name", "output"]
greet() {
this.outputTarget.textContent = `Hello, ${this.nameTarget.value}!`;
};
});
```
The `Controller` is registered with the `data-controller` name from the HTML, and it has a `targets` field that enumerates all the ids of elements that it wants to target. It can then refer to them by a naming convention, e.g. "output" shows up in the controller as a reference to a DOM element called `outputTarget`.
You can do more or less anything you like in the `Controller`, so for example you could pull some content from the backend. The `turbo` sample does that by pulling a string from the `/user` endpoint and inserting it in an "auth" target element:
```html
...
```
with the complementary Javascript:
```javascript
Stimulus.register("hello", class extends Controller {
static targets = ["name", "output", "auth"]
initialize() {
let hello = this;
fetch("/user").then(response => {
response.json().then(data => {
hello.authTarget.textContent = `Logged in as: ${data.name}`;
});
});
}
...
});
```
## Add Some Charts
We can have some fun adding other Javascript libraries, for instance some nice graphics. Here's a new tab in `index.html` (remember to add the `` link as well):
```html
Clear
Bar
```
It has an empty `` that we can fill in with a bar chart using https://www.chartjs.org/[Chart.js]. In preparation for that we declared a controller called "chart" in the HTML above and labelled the target element for it with `data-*-target`. So let's start by adding Chart.js to the application. In `pom.xml`:
```xml
org.webjars.npm
chart.js
3.6.0
```
and in `index.html` we add an import map and some Javascript to render the chart:
```html
{
"imports": {
...
"chart.js": "/npm/chart.js"
}
}
```
and the new controller implementing the "bar" and "clear" actions from the buttons in the HTML:
```javascript
import { Chart, BarController, BarElement, LinearScale, CategoryScale, Title, Legend } from 'chart.js';
Chart.register(BarController, BarElement, LinearScale, CategoryScale, Title, Legend);
Stimulus.register("chart", class extends Controller {
static targets = ["canvas"]
bar(type) {
let chart = this;
this.clear();
fetch("/pops").then(response => {
response.json().then(data => {
data.type = "bar";
chart.active = new Chart(chart.canvasTarget, data);
});
});;
clear() {
if (this.active) {
this.active.destroy();
}
};
};
});
```
To service this we need a `/pops` endpoint with some chart data (estimated world population by continent according to Wikipedia):
```
$ curl localhost:8080/pops | jq .
{
"data": {
"labels": [
"Africa",
"Asia",
"Europe",
"Latin America",
"North America"
],
"datasets": [
{
"backgroundColor": [
"#3e95cd",
"#8e5ea2",
"#3cba9f",
"#e8c3b9",
"#c45850"
],
"label": "Population (millions)",
"data": [
2478,
5267,
734,
784,
433
]
}
]
},
"options": {
"plugins": {
"legend": {
"display": false
},
"title": {
"text": "Predicted world population (millions) in 2050",
"display": true
}
}
}
}
```
The sample app has a few more charts, all showing the same data in different formats. They are all serviced by the same endpoint illustrated above:
```java
@GetMapping("/pops")
@ResponseBody
public Chart bar() {
return new Chart();
}
```
## Code Block Hiding
In Spring guides and reference documentation we often see blocks of code segmented by "type" (e.g. Maven vs. Gradle, or XML vs. Java). They are shown with one option active and the rest hidden, and if the user clicks on another option, not just the closest code snippets, but all the snippets in the whole document that match the click are revealed. For example if the user clicks on "Gradle" all the code snippets that refer to "Gradle" are simultaneously activated. The Javascript that drives that feature exists in several forms, depending on which guide or project is using it, and one of those forms is as an NPM bundle https://www.npmjs.com/package/@springio/utils[@springio/utils]. It's not strictly an ESM module but we can still import it and see the feature working. Here's what it looks like in `index.html`:
```html
{
"imports": {
...
"@springio/utils": "/npm/@springio/utils"
}
}
...
import '@springio/utils';
```
and then we can add a new tab with some "code snippets" (just junk content in this case):
```html
One
Some content
Two
Secondary
Three
Third option
One
Some more content
Two
Secondary stuff
Three
Third option again
```
It looks like this if the user selects the "One" block type:
image::images/one.png[]
The thing that drives the behaviour is the structure of the HTML, with one element labelled "primary" and alternatives as "secondary", then a nested `class="title"` before the actual content. The title is pulled out into the buttons by the Javascript.
## Dynamic Content With Vue
Vue is a lightweight Javascript library that you can use a little of or a lot. To get started with Webjars we would need the dependency in `pom.xml`:
```xml
org.webjars.npm
vue
2.6.14
```
and add it to the import map in `index.html` (using a manual resource path because the "module" in the NPM bundle points to something that doesn't work in a browser):
```html
{
"imports": {
...
"vue": "/npm/vue/dist/vue.esm.browser.js"
}
}
```
Then we can write a component and "mount" it in a named element (it's an example from the Vue user guide):
```html
import Vue from 'vue';
const EventHandling = {
data() {
return {
message: 'Hello Vue.js!'
}
},
methods: {
reverseMessage() {
this.message = this.message
.split('')
.reverse()
.join('')
}
}
}
new Vue(EventHandling).$mount("#event-handling");
```
To receive the dynamic content we need an element that matches `#event-handling`, e.g.
```html
{{ message }}
Reverse Message
```
So the templating happens on the client, and it is triggered by a click using `v-on` from Vue.
If we want to replace Hotwired with Vue we could start with the content on the main "message" tab. So we can replace the Stimulus controller bindings with this, for example:
```html
{{user}}
{{greeting}}
Greet
```
and then hook the `user` and `greeting` properties in through Vue:
```javascript
import Vue from 'vue';
const EventHandling = {
data() {
return {
greeting: '',
name: '',
user: 'Unauthenticated'
}
},
created: function () {
let hello = this;
fetch("/user").then(response => {
response.json().then(data => {
hello.user = `Logged in as: ${data.name}`;
});
});
},
methods: {
greet() {
this.greeting = `Hello, ${this.name}!`;
},
}
}
new Vue(EventHandling).$mount("#message");
```
The `created` hook is run as part of the Vue component lifecycle, so it's not necessarily going to be run precisely the same time as Stimulus did it, but it's close enough.
We can also replace the chart picker with a Vue, and then we can get rid of Stimulus, just to see what it looks like. Here's the chart tab (basically the same as before but without the controller decorations):
```html
Clear
Bar
```
and here's the Javascript code to render the chart:
```html
import Vue from 'vue';
import { Chart, BarController, BarElement, LinearScale, CategoryScale, Title, Legend } from 'chart.js';
Chart.register(BarController, BarElement, LinearScale, CategoryScale, Title, Legend);
const ChartHandling = {
methods: {
clear() {
if (this.active) {
this.active.destroy();
}
},
bar() {
let chart = this;
this.clear();
fetch("/pops").then(response => {
response.json().then(data => {
data.type = "bar";
chart.active = new Chart(document.getElementById("canvas"), data);
});
});
}
}
}
new Vue(ChartHandling).$mount("#chart");
```
The sample code also has "pie" and "doughnut" in addition to the "bar" chart type, and they work the same way.
### Server Side Fragments
Vue can replace the entire inner HTML of an element using the `v-html` attribute, so we can start to re-implement the Turbo content with that. Here's the new "test" tab:
```html
Fetch
```
It has a click handler referring to a "hello" method, and a div that is waiting to receive content. We can attach the button to the "hi" container like this:
```html
import Vue from 'vue';
const HelloHandling = {
data: {
html: ''
},
methods: {
hello() {
const handler = this;
fetch("/test").then(response => {
response.text().then(data => {
handler.html = data;
});
});
},
}
}
new Vue(HelloHandling).$mount("#test");
```
To make it work we just need to remove the `` elements from the server side template (reverting to what we had in the HTMX sample).
It is definitely possible to replace our Turbo (and HTMX) code with Vue (or another library or even plain Javscript), but we can see from the sample that it inevitably involves some boilerplate Javascript.
## Plain Javascript with SSE Stream
Vue isn't really adding a lot of value in this simple HTML replacement use case, and it would add no value at all to the SSE example, so we will go ahead and implement that in vanilla Javascript. Here's a stream tab:
```html
```
and some Javascript to populate it:
```html
var events = new EventSource("/stream");
events.onmessage = e => {
document.getElementById("load").innerHTML = e.data;
}
```
## Dynamic Content with React
Most people who use React probably do more than just a bit of logic and end up with all of the layout and rendering in Javascript. You don't have to do that, and it's quite easy to use just a bit of React to get a feel for it. You could leave it at that and use it as a utility library, or you could evolve to a full Javascript client-side component approach.
We can get started and try it out without changing too much. The sample code will end up looking like the `react-webjars` sample if you want to peek. First the dependencies in `pom.xml`:
```xml
org.webjars.npm
react
17.0.2
org.webjars.npm
react-dom
17.0.2
```
and the module map in `index.html`:
```html
{
"imports": {
...
"react": "/npm/react/umd/react.development.js",
"react-dom": "/npm/react-dom/umd/react-dom.development.js"
}
}
```
React is not packaged as an ESM bundle (yet, anyway), so there is no "module" metadata and we have to hard code the resource paths like this. The "umd" in the resource path refers to "Universal Module Definition" which is an older attempt at modular Javascript. It's close enough that if you squint you can use it in a similar way.
With those in place you can import the functions and objects they define:
```html
import * as React from 'react';
import * as ReactDOM from 'react-dom';
```
Because they are not really ESM modules you can do this at the "global" level in a `` in the HTML `
`, e.g. where we import `bootstrap`. Then you can define some content by creating a `React.Component`. Here's a really basic static example:
```html
const e = React.createElement;
class RootComponent extends React.Component {
constructor(props) {
super(props);
}
render() {
return e(
'h1',
{},
'Hello, world!'
);
}
}
ReactDOM.render(e(RootComponent), document.querySelector('#root'));
```
The `render()` method returns a function that creates a new DOM element (an `
` with content "Hello, world!"). It is attached by `ReactDOM` to an element with `id="root"`, so we'd better add one of those as well, for example in the "test" tab:
```html
```
If you run that it should work and it should say "Hello World" in that tab.
### HTML in Javascript: XJS
Most React apps use HTML embedded in the Javascript via a templating language called "XJS" (which can be used in other ways but is actually part of React now). The hello world sample above looks like this:
```html
class Hello extends React.Component {
render() {
return <h1>Hello, {this.props.name}!</h1>;
}
}
ReactDOM.render(
<Hello name="World"/>,
document.getElementById('root')
);
```
The component defines a custom element `` that match the class name of the component, and conventionally starts with a capital letter. The `` fragment is an XJS template, and the component also has a `render()` function that returns an XJS template. Braces are used for interpolation, and `props` is a map including all the attributes of the custom element (so "name" in this case). Finally there is that `` which is needed to transpile the XJS into actual Javascript that the browser will understand. The script above will do nothing until the browser is taught to recognize this script. We do that by importing another module:
```html
<script type="importmap">
{
"imports": {
...
"react": "/npm/react/umd/react.development.js",
"react-dom": "/npm/react-dom/umd/react-dom.development.js",
"@babel/standalone": "/npm/@babel/standalone"
}
}
...
import * as React from 'react';
import * as ReactDOM from 'react-dom';
import '@babel/standalone';
```
The React user guide advises against using `@babel/standalone` in a large application because it has to do a lot of work in the browser, and the same work can be done once at build time which is more efficient. But it's good for trying stuff out, and for apps with small amounts of React code, like this one.
### Basic Event and User Input Handling
We are now in a position where we can migrate the main "message" tab to React. So let's modify the `Hello` component and attach it to a different element. The message tab can be stripped down to an empty element ready to accept the React content:
```html
```
We can anticipate that we will need a second component to render the authenticated user name, so let's start with this to attach some code to the element in the tab above:
```javascript
ReactDOM.render(
,
document.getElementById('hello')
);
```
Then we can define the `Auth` component like this:
```javascript
class Auth extends React.Component {
constructor(props) {
super(props);
this.state = { user: 'Unauthenticated' };
};
componentDidMount() {
let hello = this;
fetch("/user").then(response => {
response.json().then(data => {
hello.setState({user: `Logged in as: ${data.name}`});
});
});
};
render() {
return
{this.state.user};
}
};
```
The lifecycle callback in this case is `componentDidMount` which is called by React when the component is activated, so that's where we put our initialization code.
The other component is the one that transfers the "name" input to a greeting:
```javascript
class Hello extends React.Component {
constructor(props) {
super(props);
this.state = { name: '', message: '' };
this.greet = this.greet.bind(this);
this.change = this.change.bind(this);
};
greet() {
this.setState({message: `Hello ${this.state.name}!`})
}
change(event) {
console.log(event)
this.setState({name: event.target.value})
}
render() {
return
{this.state.message}
Greet
;
}
}
```
A `render()` method has to return a single element, so we have to wrap the content in a `
`. The other thing that is worth pointing out is that the transfer of state from the HTML to the Javascript is not automtatic - there's no "two-way model" in React, and you have to add change listeners to inputs to explicitly update the state. Also we have to call `bind()` on all the component methods that we want to use as listeners (`greet` and `change` in this case).
### Chart Chooser
To migrate the rest of the Stimulus content to React we need to write a new chart chooser. So we can start with an empty "chart" tab:
```html
```
and attach a `ReactDOM` element to the "chooser":
```javascript
ReactDOM.render(
,
document.getElementById('chooser')
);
```
`ChartChooser` is a list of buttons encapsulated in a component:
```javascript
class ChartChooser extends React.Component {
constructor(props) {
super(props);
this.state = {};
this.clear = this.clear.bind(this);
this.bar = this.bar.bind(this);
};
bar() {
let chart = this;
this.clear();
fetch("/pops").then(response => {
response.json().then(data => {
data.type = "bar";
chart.setState({ active: new Chart(document.getElementById("canvas"), data) });
});
});
};
clear() {
if (this.state.active) {
this.state.active.destroy();
}
};
render() {
return
Clear
Bar
;
}
}
```
We also need the chart module setup from the Vue sample (it won't work in a ``):
```html
<script type="module">
import { Chart, BarController, BarElement, LinearScale, CategoryScale, Title, Legend } from 'chart.js';
Chart.register(BarController, BarElement, LinearScale, CategoryScale, Title, Legend);
window.Chart = Chart;
```
Chart.js isn't shipped in a form you can import into a Babel script. We import it in a separate module, and `Chart` has to be defined as a global so we can still use it in our React component.
### Server Side Fragments
To render the "test" tab with React we can start with the tab itself, empty again to accept content from React:
```html
```
with a binding to the "root" element in React:
```javascript
ReactDOM.render(
,
document.getElementById('root')
);
```
Then we can implement the `` as a component that fetches HTML from the `/test` endpoint:
```javascript
class Content extends React.Component {
constructor(props) {
super(props);
this.state = { html: '' };
this.fetch = this.fetch.bind(this);
};
fetch() {
let hello = this;
fetch("/test").then(response => {
response.text().then(data => {
hello.setState({ html: data });
});
});
}
render() {
return
Fetch
;
}
}
```
The `dangerouslySetInnerHTML` attribute is delibrately named by React to discourage people from using it with content that is collected directly from users (XSS issues). But we get that content from the server so we can put our trust in the XSS protection there and ignore the warning.
If we use that `` component and the SSE loader from the sample above then we can get rid of Hotwired altogether from this sample.
## Building and Bundling with Node.js
Webjars are great, but sometimes you need something closer to the Javascript. One problem with Webjars for some people is the size of the jars - the Bootstrap jar is nearly 2MB, most of which will never be used at runtime - and Javascript tooling has a strong focus on reducing that overhead, by not packaging the whole NPM module in your app, and also by bundling assets together so they can be downloaded efficiently. There are also some issues with Java tooling - regarding https://github.com/sass/dart-sass[Sass] in particular there is a lack of good tooling, as we found with the https://github.com/spring-projects/spring-petclinic/pull/868[Petclinic recently]. So maybe we should take a look at options for building with a Node.js toolchain.
The first thing you will need is Node.js. There are many ways of obtaining it, and you can use whatever tools you want. We will show how to do it with the https://github.com/eirslett/frontend-maven-plugin[Frontend Plugin].
### Install Node.js
Let's add the plugin to the `turbo` sample. (The final result is the `nodejs` sample if you want to peek) in `pom.xml`:
```xml
com.github.eirslett
frontend-maven-plugin
1.12.0
install-node-and-npm
install-node-and-npm
v16.13.1
npm-install
npm
install
npm-build
npm
run-script build
generate-resources
...
```
Here we have 3 executions: `install-node-and-npm` installs Node.js and NPM locally, `npm-install` runs `npm install` and `npm-build` runs a script to build the Javascript and possibly CSS. We will need a minimal `package.json` to run them all. If you have `npm` installed you could `npm init` to generate a new one, or just create it manually:
```
$ cat > package.json
{
"scripts": { "build": "echo Building"}
}
```
Then we can build
```
$ ./mvnw generate-resources
...
[INFO] Building
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.133 s
[INFO] Finished at: 2021-12-16T07:46:42Z
[INFO] ------------------------------------------------------------------------
```
You will see the result is a new directory:
```
$ ls -d node*
node
```
It is useful to have an quick way to run `npm` from the command line, when it is installed locally like this. So once you have Node.js you can make it easy by creating a script locally:
```
$ cat > npm
#!/bin/sh
cd $(dirname $0)
PATH="$PWD/node/":$PATH
node "node/node_modules/npm/bin/npm-cli.js" "$@"
```
Make it executable and try it out:
```
$ chmod +x npm
$ ./npm install
up to date, audited 1 package in 211ms
found 0 vulnerabilities
```
### Adding NPM Packages
Now we are ready to build something, let's set up `package.json` with all the dependencies that we had in Webjars until now:
```json
{
"name": "js-demo",
"version": "0.0.1",
"dependencies": {
"@hotwired/stimulus": "^3.0.1",
"@hotwired/turbo": "^7.1.0",
"@popperjs/core": "^2.10.1",
"bootstrap": "^5.1.3",
"chart.js": "^3.6.0",
"@springio/utils": "^1.0.5",
"es-module-shims": "^1.3.0"
},
"scripts": {
"build": "echo Building"
}
}
```
Running `./npm install` (or `./mvnw generate-resources`) will download those dependencies into `node_modules`:
```
$ ./npm install
added 7 packages, and audited 8 packages in 8s
2 packages are looking for funding
run `npm fund` for details
found 0 vulnerabilities
$ ls node_modules/
@hotwired @popperjs @springio bootstrap chart.js es-module-shims
```
It's OK to add all the downloaded and generated code to your `.gitignore` (i.e. `node/`, `node_modules/`, and `package-lock.json`).
### Building with Rollup
The Bootstrap maintainers use https://rollupjs.org/guide/en/[Rollup] to bundle their code, so that seems like a decent choice. One thing it does really well is "tree shaking" to reduce the amount of Javscript you need to ship with your application. Feel free to experiment with other tools. To get started with Rollup we will need some development dependencies in `package.json` and a new build script:
```json
{
...
"devDependencies": {
"rollup": "^2.60.2",
"rollup-plugin-node-resolve": "^2.0.0"
},
"scripts": {
"build": "rollup -c"
}
}
```
Rollup has its own config file, so here's one that will bundle a local Javascript source into the app and serve the Javsacript up from `/index.js` at runtime. This is `rollup.config.js`:
```json
import resolve from 'rollup-plugin-node-resolve';
export default {
input: 'src/main/js/index.js',
output: {
file: 'target/classes/static/index.js',
format: 'esm'
},
plugins: [
resolve({
esm: true,
main: true,
browser: true
})
]
};
```
So if we move all the Javascript into `src/main/js/index.js` we would have just one `` in `index.html`, for instance at the end of the `<body>`:
```html
<script type="module">
import '/index.js';
```
We will keep the CSS for now, and we can deal with a local build for that later. So in `index.js` we have all the `` tag contents mushed together (or we could have split it up into modules and imported them):
```javascript
import 'bootstrap';
import '@hotwired/turbo';
import '@springio/utils';
import { Application, Controller } from '@hotwired/stimulus';
import { Chart, BarController, BarElement, PieController, ArcElement, LinearScale, ategoryScale, Title, Legend } from 'chart.js';
Turbo.connectStreamSource(new EventSource("/stream"))
window.Stimulus = Application.start();
Chart.register(BarController, BarElement, PieController, ArcElement, LinearScale, CategoryScale, itle, Legend);
Stimulus.register("hello", class extends Controller {
...
});
Stimulus.register("chart", class extends Controller {
...
});
```
If we build and run the app it should all work, and Rollup creates a new `index.js` in `target/classes/static` where it will be picked up by the executable JAR. Because of the action of the "resolve" plugin in Rollup, the new `index.js` has all of the code that is needed to run our application. If any dependencies are packaged as a proper ESM bundle, Rollup will be able to shake the unused parts of them out. This works for Hotwired Stimulus at least, and most of the others get included wholesale, but the result is still only 750K (most of it Bootstrap):
```
$ ls -l target/classes/static/index.js
-rw-r--r-- 1 dsyer dsyer 768778 Dec 14 09:34 target/classes/static/index.js
```
The browser has to download this once, which is an advantage when the server is HTTP 1.1 (HTTP 2 changes things a bit), and it means the executable JAR isn't bloated with stuff that never gets used. There are other plugin options with Rollup to compress the Javascript, and we'll see some of those in the next section.
### Building CSS with Sass
So far we have used plain CSS bundled in some NPM libraries. Most applications need their own stylesheets and developers prefer to work with some form of templating library and build time tooling to compile to CSS. The most prevalent such tool (but not the only one) is https://www.npmjs.com/package/sass[Sass]. Bootstrap uses it, and indeed packages its source files in the NPM bundle, so you can extend and adapt the Bootstrap styles to your own requirements.
We can see how that works by building the CSS for our application, even if we don't do much customization. Start with some tooling dependencies in NPM:
```
$ ./npm install --save-dev rollup-plugin-scss rollup-plugin-postcss sass
```
which leads to some new entries in `package.json`:
```json
{
...
"devDependencies": {
"rollup": "^2.60.2",
"rollup-plugin-node-resolve": "^2.0.0",
"rollup-plugin-postcss": "^0.2.0",
"rollup-plugin-scss": "^3.0.0",
"sass": "^1.44.0"
},
...
}
```
This means we can update our `rollup.config.js` to use the new tools:
```javascript
import resolve from "rollup-plugin-node-resolve";
import scss from "rollup-plugin-scss";
import postcss from "rollup-plugin-postcss";
export default {
input: "src/main/js/index.js",
output: {
file: "target/classes/static/index.js",
format: "esm",
},
plugins: [
resolve({
esm: true,
main: true,
browser: true,
}),
scss(),
postcss(),
],
};
```
The CSS processors look in the same place as the main input file, so we can just create a `style.scss` in `src/main/js` and import the Bootstrap code:
```css
@import 'bootstrap/scss/bootstrap';
```
Customizations in SCSS would follow that if we were doing it for real. Then in `index.js` we add imports for this and the Spring utils library:
```javascript
import './style.scss';
import '@springio/utils/style.css';
...
```
and re-build. This will lead to a new `index.css` being created (the same file name as the main input Javascript) which we can then link to in the `<head>` of `index.html`:
```html
<head>
...
<link rel="stylesheet" type="text/css" href="index.css" />
</head>
```
That's it. We have one `index.js` script driving all the Javascript and CSS for our Turbo sample, and we can now remove all remaining Webjars dependencies in the `pom.xml`.
## Bundling a React App with Node.js
To finish up we can apply the same ideas to the `react-webjars` sample, removing Webjars and extracting Javascript and CSS into separate source files. This way, we can also finally get rid of the slightly problematic `@babel/standalone`. We can start from the `react-webjars` sample and add the Frontend Plugin as above (or otherwise acquire Node.js), and create a `package.json` either manually or via the `npm` CLI. We will need the React dependencies, and also the build time tooling for Babel. Here's what we end up with:
```json
{
"name": "js-demo",
"version": "0.0.1",
"dependencies": {
"@popperjs/core": "^2.10.1",
"@springio/utils": "^1.0.4",
"bootstrap": "^5.1.3",
"chart.js": "^3.6.0",
"react": "^17.0.2",
"react-dom": "^17.0.2"
},
"devDependencies": {
"@babel/core": "^7.16.0",
"@babel/preset-env": "^7.16.0",
"@babel/preset-react": "^7.16.0",
"@rollup/plugin-babel": "^5.3.0",
"@rollup/plugin-commonjs": "^21.0.1",
"@rollup/plugin-node-resolve": "^13.0.6",
"@rollup/plugin-replace": "^3.0.0",
"postcss": "^8.4.5",
"rollup": "^2.60.2",
"rollup-plugin-postcss": "^4.0.2",
"rollup-plugin-scss": "^3.0.0",
"sass": "^1.44.0",
"styled-jsx": "^4.0.1"
},
"scripts": {
"build": "rollup -c"
}
}
```
We need the `commonjs` plugin because React is not packaged as an ESM and the imports will not work without doing some conversion. The Babel tooling comes with a config file `.babelrc` which we use to tell it to build the JSX and React components:
```json
{
"presets": ["@babel/preset-env", "@babel/preset-react"],
"plugins": ["styled-jsx/babel"]
}
```
With those build tools in place we can extract all the Javascript from `index.html` and put it in `src/main/resources/static/index.js`. It's almost a copy paste, but we will want to add the CSS imports:
```javascript
import './style.scss';
import '@springio/utils/style.css';
```
and the imports from React look like this:
```javascript
import React from 'react';
import ReactDOM from 'react-dom';
```
You can build that with `npm run build` (or `./mvnw generate-resources`) and it should work - all the tabs have some content and all the buttons generate some content.
Finally we just need to tidy up the `index.html` so that it only imports the `index.js` and `index.css`, and then all the features from the Webjars project should be working as expected.