Editable table list

The editable table list is a form component designed to support bulk manipulation of data and is optimized to be operated only using the keyboard.

Topics

• Overview
  • Evaluation
• Architecture and Design
  • Row state
  • Row insertion
  • Row deletion
  • Save operation
• Changelog

See also

• Table list

Overview

Regular table lists are static tables that display information in rows and columns. This information is read-only, meaning it cannot be edited directly within the table itself. To edit multiple rows, users need to navigate back and forth between the table list and a dedicated support form. On the other hand, editable table lists allows users to modify the data directly within the table itself, which is particularly useful in scenarios where users need to manipulate multiple rows.

One of the key features of editable table lists is their ability to maintain in-memory changes to multiple rows simultaneously, saving them at once during the save operation of their parent form. This creates the possibility of enforcing rules that affect multiple rows. More on this is discussed on the save operation section.

Evaluation

Advantages

• Efficiency: An editable table list allows users to make changes to the data without needing to navigate to a separate editing screen or form. This can save time and streamline the process of updating information.
• User-Friendly: An editable table list is often more user-friendly as it enables users to edit the data in the context of the table itself. This reduces the need to switch between different screens and can make the user interface more intuitive.
• Reactivity: The editable table list computes in real-time the value of expressions such as arithmetic, block when, and fill when formulas, as well as lookup limits (e.g., district > municipality > parish).
• Bulk validations: Keeping in-memory changes to multiple rows simultaneously allows to enforce rules over groups of rows.

Disadvantages

• Performance: If the editable table list is working with a large amount of data, there can be performance issues when editing or saving rows.
• Reduced feature set: Editable table lists are designed with data manipulation in mind. This means that some features that can be found in regular table lists, such as row sorting, pagination, filtering, or search, are not present in editable table lists to improve their performance.
• Unsupported datatypes: Due to potential usability and user experience concerns, some datatypes such as images or documents are not supported by editable table lists.

Architecture and Design

This section provides a detailed explanation on the editable table list's architecture and design and how its different components work together.

Row state

As the users interact with editable table lists, each row goes through a subset of the following states:

1. Unmodified: This is the initial state of a row when it is first displayed in the table. It indicates that the row has not been modified since it was last saved.
2. Modified: This state indicates that the row has been edited since it was last saved, but the changes have not yet been saved to the underlying data source.
3. New: This state indicates that the row is new and has not yet been saved to the underlying data source.
4. Deleted: This state indicates that the row has been marked for deletion but has not yet been removed from the underlying data source.
5. Error: This state indicates that there was an error when attempting to save the row to the underlying data source.

To make users aware of the state of each row in an editable table list, visual cues are used that clearly indicate the current state of each row. A summary of the visual cues used to display the state of each row is shown in Table 1.

Table 1. Summary of the visual cues used to display the state of each row.

Row insertion

Row insertion in the context of editable table lists is supported by an auxiliary row that is displayed at all times at the bottom of the table, as shown in Figure 1.

Figure 1. Auxiliary row to support insertion of new rows.

It's worth noting that there is no explicit insert button. To ensure the auxiliary row is displayed at all times, a new auxiliary row is automatically inserted at the bottom of the table as soon as users begin to alter it, as shown in Figure 2. Similarly, the editable table list automatically removes any new rows that no longer differ from the auxiliary row. Combined, these two mechanisms ensure that exactly one empty auxiliary row is displayed at the bottom of the table.

Figure 2. Automatic management of empty rows.

Row deletion

In an editable table list, the action that is offered to delete a row depends on its initial state:

• A "Remove" button is displayed for new rows. Clicking this button immediately deletes the corresponding row from the table. This action cannot be undone.
• A "Delete" button is displayed for all the other rows. Clicking this button marks the row for deletion, which does not immediately delete it, but rather indicates that the row will be deleted if the user decides to save the table as a whole. Until then, this action can be undone by clicking the "Undo" button that is displayed for rows that are marked to be deleted, as shown in Figure 3.

Figure 3. Undo button in a row that is marked to be deleted.

Save operation

As discussed, editable table lists keep in-memory changes to multiple rows simultaneously and save them at once during the save operation of their parent form. During this operation, the parent form begins by attempting to save all of its editable table list components, and only then saving the changes of itself, as suggested by Spec. 1.

/**
 *  Form save.
 *  ---------
 *  Saves all child editable table lists and then saves itself.
 */
saveForm() {
  editableTableList1.save()
  editableTableList2.save()

  /** ... */

  self.save()
}

Spec. 1. Pseudocode of the save operation of a form with editable table lists.

Since the size of the data to be saved is uncertain and potentially large, the save operation of editable table lists takes into consideration the following concerns:

1. Minimizing network usage and server load
2. Providing clear feedback to the user on the status of the operation and any errors

Network usage and server load

The save operation of editable table lists takes advantage of the following mechanisms to minimize network usage and server load:

1. Bulk updates: Instead of being updated individually, the rows of the table are grouped into a single request to reduce the number of requests sent to the server.
2. Minimizing the amount of data sent: The amount of data sent is minimized by only sending changes made by the user. Unmodified rows are not sent back to the server.
3. Client-side validation: Client-side validation, such as checking if all required fields are filled out, prevents unnecessary requests to the server and reduces network usage.

Error handling

As discussed, the save operation of editable table lists is a process controlled by the table's parent form. Because of this, the users do not need to click additional buttons to save the table - it happens automatically during the save operation of the table's parent form. If any errors occur during this process, the appropriate rows (and fields, when applicable) are highlighted with error indicators, and popovers are displayed so users can check the error messages, as shown in Figure 4.

Figure 4. Error highlighting with associated error message.

Changelog

The complete changelog of all notable changes made to the Editable Table List component.

Genio 352.15

• (VUE) New: Support for column totalizers in editable table lists. See Table list for an overview of their definition and usage.

Genio 322.28

• (VUE) New: Initial Vue.js implementation of the editable table list (DN) form component.