Ideas for CRUD helper functionality

[Legioth]

We have started investigating how Hilla could help when building different types of CRUD functionality. More specifically, we're focusing on the master-detail UI pattern where the user sees a list of items and can select any of them for editing in a separate form.

As a full-stack framework that touches both the UI and the backend, Hilla has some special opportunities that aren't available for a solution that focuses only on the UI or only the backend. Hilla can use metadata from backend types to provide a good starting point for rendering a UI and hooking it up with the backend. At the same time, we need to be very mindful of how to allow customizing any part without having to also re-implement the parts where the defaults are sufficient.

Simplest possible starting point

We assume that the developer wants to get started as quickly as possible by creating an RPC endpoint that reads entities straight from a Spring Data JPA repository into a Vaadin Grid component. The grid is automatically configured with a column for each of the properties in the JPA entity. Thanks to Spring Data, the grid can also be lazy-loaded and sortable without additional application code. There's also some (potentially AI-generated) sample data in that grid right away rather than only showing an empty grid.

Expressed in code, the endpoint could thus look like this:

@Endpoint
@AnonymousAllowed
public class PersonEndpoint {

    private PersonRepository repo;

    public PersonEndpoint(PersonRepository repo) {
        this.repo = repo;
    }

    public Page<Person> list(Pageable pageable) {
        return repo.findAll(pageable);
    }
}

Whereas usage from TypeScript would be like this with the help of a React hook:

const data = useData(PersonEndpoint.list);
return <Grid {...data}></Grid>

When the developer also provides an RPC endpoint for saving a new or existing entity into the repository, then the UI could automatically also have a form with appropriate input fields for editing an existing entity selected in the grid and optionally also submitting a new entity to insert into the database. Just like with regular form binding in Hilla, the form would automatically have client-side validation based on bean validation rules defined in the Java entity class.

Hilla can automate all of this based on metadata from the Java types similarly to how the form binder already discovers rules for client-side validation.

Beyond the starting point

This very simple CRUD might already be enough for an admin view but there are many dimensions where expansion might be needed for CRUDs that are used in other parts of an application. The challenge with all of these options is to make sure each one is individually and incrementally customizable without having to give up the defaults in other areas.

These are the main customization directions that we have identified (in no particular order):

• Exclude specific properties from the grid and/or the form and change in which order they are displayed.
• Delegate backend operations through a service layer to be able to e.g. apply fine-grained access control or trigger additional business processes when an entity is updated.
• Send DTO types instead of the original JPA entities to the client. There might be a different DTO for the grid and for the form since the grid might skip some properties or show a summarized value instead of the full data. The developer might have to explicitly supply metadata that was previously inferred from JPA annotations.
• Customize how raw values for a given property are formatted in the grid and how they are converted to and from the format used by the form field.
• Customize the form field for a specific property to either use an alternative field type or to apply custom configuration options (e.g. helper texts).
  • Specifically for fields that represent a relationship to some other entity, enable reusing existing settings for the CRUD editor for that entity type.
• Adjust the layout of the form to e.g. split it up into a wizard with multiple steps or to add responsive breakpoints to the layout. This should be doable in a way where configuration of individual field components could still be handled by Hilla.
• Skip the automatically generated sample data and instead use data provided by the application developer.
• Add filtering for the grid either based on filter fields inlined into grid column headers or through a separately implemented UI.

Specific questions to the community

• Do you agree that the described simplest possible starting point is indeed a good starting point?
• Is there something fundamental missing from the list of possibilities for further customization?
• Out of the suggested customization options, is there any one that stands out as particularly important?

Aside from these specific questions, we are of course also happy to hear any other thoughts that you have on the topic.

[taefi]

Do you agree that the described simplest possible starting point is indeed a good starting point?

Yes, but ...
I agree that using the Spring Data Repository as the contract for which existing method is doing which CRUD operation possibly reduces some boiler plate codes, but, I'm not sure if it is the statistically dominant use case in real world applications, since I believe in most cases, we need to apply fine-grained access control or trigger additional business processes when an entity is updated. In other words, I think the default should be Delegate backend operations through a service layer.

This could be addressed by introducing a conventional interface e.g. CrudEndpoint to be implemented in user applications, that exposes the needed methods for C-R-U-D operations. They could be freely annotated by the standard access control annotations, and the developer has the possibility of using a business component from the service layer to trigger something along with the actual CRUD operations, or simply calls JPA Repository methods underneath.

[Legioth]

There's no doubt that a fair share of cases will eventually end up with a service layer for functionality such as fine-grained access control.

The key question though is whether most cases will want that during the first day of working on that particular CRUD.

Offering direct mapping to a repository as the first incremental step gives the possibility to start working on e.g. presentation or layout very quickly and then start addressing access control only after a couple of days. There's very little to lose from starting with a repository since you will then only have to remove a couple of lines of code to "undo" that intermediate step once you also have a service in place.

And if you want to go with a service from the very first day of development, then there would be nothing that stops you from doing it that way either.

[taefi]

Out of the suggested customization options, is there any one that stands out as particularly important?

What I really liked about the idea is to have practical defaults in place where possible, and not having to implement the whole thing in case I wanted to customize something trivial.

For instance, I expect to have a <Crud /> component that consists of a <Grid /> and a <Form /> underneath, but if I want to use the defaults (such as listing all the properties both in the form and in the grid), the only thing I need to do for creating a CRUD view for the Person should be returning a <Crud {...PersonEndpoint} /> in my template.

Consequently, let's assume that Person object has three properties: name, family, email. if I want to only exclude a column such as email from the Grid, I don't want to repeat everything, but something like this:

return (
    <Crud {... PersonEndpoint}>
        <Grid columns="name, family" />
    </Crud>
);

In the above snippet, the <Form /> part is not present, so the defaults which is showing editors for all the properties should be still in tact.

[sissbruecker]

I got the impression that a lot of people involved in our discussion imagined this feature to result in a single component that would contain both a grid and the form. I just want to point out that a CRUD feature could span over different routes, for example:

• /customers - Customer list
• /customers/42 - Customer details view
• /customers/42/edit - Customer edit view

This has some advantages over a single component:

• Deep-linking is easy
• Can use native browser navigation making this accessible by default
• Access control could be done with the route (at least partially)
• No need for an uber component doing everything at once, just provide individual components / behaviors for list, details, edit
• No need for a "CRUD layout" that is responsive

Disadvantages are:

• Requires more work for routing setup
• Switching between entries is not as convenient as having both grid and details / form side-by-side
• Possibly having to deal with stale data when moving between routes if caching is involved

[taefi]

Sound interesting!
In this spanned version, could we imagine a pagination indicator for the details (or the edit view)?
For example, to show the following set of controls on for navigating between the records easily:
<< First < Previous 5 of 289 next > Last >>