HTML was made into a common part with Thymeleaf to unify the design and improve development efficiency.

In a Spring Boot + Thymeleaf environment, multiple people may develop the front end, It is a memo that when the same structure and design often appear, there was such a problem and it was solved. (Even if someone takes over, it may be an ant to make it a common part)

environment

Spring Boot: 1.3.2 RELEASE Thymeleaf: 2.14 RELEASE

What is Thymeleaf

It is one of the template engines and is recommended for use in the Java environment. What I like is that you can embed Thymeleaf's own syntax in HTML. First write native HTML, roughly determine the structure and design, and without breaking the code too much You can complete it. (I've never used any other template engine ... maybe that's what the world is all about) It is said that you can do various things (although it is rough) by combining with Spring Boot. Official site: http://www.thymeleaf.org/

Challenges at the site where I was

Actually, it was a little less than two years ago, and I recently returned to the front end and remembered it, so I wrote it. At that time, in the midst of development, we had the following issues.

• Multiple people implemented screen templates, and there were variations in the structure and design implemented by each. (There was a coding standard, but unfortunately not everyone adhered to it, so it was not realistic to enhance the standard (I still wonder if this judgment was correct. I improved it later. But it should have been the first ...))
• As the number of server-side development tasks increased, a small number of people (efficiency) were required to implement screen templates. (Ultimately, I had to make dozens of screen templates weekly by myself)

Common parts made with Thymeleaf

From the conclusion, it looks like this (I will omit the Thymeleaf grammar).

Caller

<!-- form.text in html-Call a part called form.
As an argument, templateId, label,Pass required.
templateId"accountName"Pass the string.
label is msg in the message resource.account.Pass the string defined in name.
Pass false for required-->
<div th:replace="form :: text-form(
    templateId = 'accountName',
    label      = #{msg.account.name},
    required   = false)">
</div>

Common parts

<!-- text-It is a part named form.
As an argument, templateId, label,Receive required.-->
<div th:fragment="text-form(templateId, label, required)">
    <label th:for="${templateId}" th:text="${label}"></label>
    <div>
        <input type="text" th:id="${templateId}" th:name="${templateId}" th:field="*{__${templateId}__}"
               th:required="${required}? required"/>
    </div>
</div>

Actually, there are CSS class application and Javascript call, which makes it complicated, but if you define common parts, You can efficiently create a structure with a unified design simply by passing the necessary parameters to the necessary parts and calling them.

Issues after making common parts

We were able to unify the design, develop screen templates efficiently, and release them as planned. However, as the development progressed, the following issues came up.

• Since common parts were made in units of design differences, a large number of common parts were created, and the cost of searching for suitable common parts increased. → For example, if you write the switch syntax in the common parts within the range where the arguments do not change, you can reduce the number of parts and improve it. → It may be a design issue in essence.
• We have not taken enough time to design the units to be used as common parts, and there are many common parts made in units that are not optimal. → In the above code example, it is a form unit, but is this the best? There should be verification for each product. → It's a good idea to make full use of the layout-dialect function (http://www.ultraq.net.nz/thymeleaf/layout).

What I personally think

• There may have been a way for automatic generation in the first place → I had no idea at that time, but ... Right now the main thing is to fix it, but it should have been very valuable at that time.
• There may be a more efficient way to make common parts by updating to Thymeleaf 3.x. → There were some new functions that could be used for making common parts. It's backwards compatible, so you shouldn't be too scared