Fetching data and render the form in one step
The challenges and solutions
There are several challenges when using HTML forms.
1. Safety challenge
Go is far safer than Javascript as it is compiled. By letting Go send the API request to an API server with no inbound traffic, the API is not exposed to the internet directly.
2. Speed challenge
One important part of the UX is speed. And also important for both reducing costs and reducing impact on the environment. Reducing traffic back and forth by SSR is one thing to consider.
3. Master Detail challenge
If you have a table of data (master) and want to display or update a form (detail) without reloading the entire page, you preferably render the entire form and send it to a body buffer. Then use Javascript to paste the form into innerHTML.
4. Endpoint challenge
The url sent to the server endpoint should both display the form AND fetch the data from the API. My solution is that the url consists of three parts: module, mode and value. Like tsk/view/1. The name of the component is "tsk_view" which is joined from the url parts (module+"_"+mode).
5. Maintenance challenge
Theoretically - 100 SQL tables will result in 100 forms for each view, edit and new. Meaning about 300 html templates only for the html forms. By gathering related forms into ONE single html template by using embedded sub templates, the html form pages will be reduced to appr 100 templates. Creating the forms dynamically can be one option, but I find it harder to maintain as the creation will be very complex.
6. Translation challenge
Using the Go HTML template it is quite simple to manage several languages. All translations are done on-the-fly when rendered by Go (SSR).