0x5 Views

Understanding Views

Views in APITable contain two concepts: one is the visual layer interaction, and the other is the data query layer. Together, they form the basic concept of a view.

Visual Interaction

We divided views into 6 different types through viewType. Different views will use the characteristics of different types of fields to perform unique interactive displays. For example, Gantt chart views and calendar views will use Date fields to present bar charts, and Kanban views will use single-select and member fields to group data. In order to support some extensible displays, views will have their own configuration properties.

Special properties

An example of the properties of a Gantt view:

{
  "id": "viwFnYfxr07eg",
  "name": "Gantt view",
  "type": 6,
  "rowHeightLevel": 1,
  "frozenColumnCount": 1,
  "rows": [
    { "recordId": "recVopLz0C6EV" }
  ],
  "columns": [
    { "fieldId": "fldjQo71Wn32G" },
    { "hidden": true, "fieldId": "fldWC3R2Ryo6K", "hiddenInGantt": true },
    { "hidden": true, "fieldId": "fldaVCAm92wBa", "hiddenInGantt": true }
  ],
  "style": {
    "workDays": [1,2,3,4,5],
    "endFieldId": "fldaVCAm92wBa",
    "colorOption": { "type": "Custom", "color": 0, "fieldId": "" },
    "startFieldId": "fldWC3R2Ryo6K",
    "onlyCalcWorkDay": false
  }
}

Developing A New View

In the Snapshots chapter, we introduced the basic properties of views. Here, we take the Gantt view as an example to explain what needs to be noted when developing a new view in terms of data structure.

hiddenInGantt is an additional property added to the column, which determines whether this column is allowed to be displayed in the right area of the Gantt chart.

hidden, as a general property, controls the display of columns in the left table area.

(One column is displayed in the left table area, and two columns (Title and Done) are displayed in the right bar chart area.)

Style is more complex, as it maintains other necessary configuration information required by the Gantt chart view. For example, workDays controls how the Gantt chart displays working days in the UI area. The values of endFieldId and startFieldId respectively store the IDs of the date type fields, which are used to record where the Gantt chart reads the start and end dates.

We have achieved the personalization of views by adding "unique properties" to the view object.

Here's a thought-provoking question: style.startFieldId stores a specified fieldId. What potential risks might this pose?

Error Tolerant

If you think deeper, you will find that storing a specified fieldId in the unique property style is unstable. This is because the schema structure of the table can change at any time. If the user deletes the corresponding field, it will cause the field attribute corresponding to the fieldId to not be obtained. Therefore, we need to do error compatibility processing for any preset judgment of fields in view-specific properties, and provide reasonable prompts in UI interactions.

For example, in this scenario, whether the user has not pre-configured startFieldId or has configured it but cannot read this field, the user should be reminded to make a new selection.

Data Calculation

Rows

Each view independently saves its own set of rows, which are persistently stored in the database. The rows of each view determine the basic order of the records, which can be edited by dragging or affected by data insertion.

The rows stored in the database serve as the basic order and are not affected by filtering, automatic sorting, or grouping functions, as these capabilities are actually "dynamic query conditions" calculated based on conditions and do not affect the basic order of rows.

Columns

Compared to rows, columns are relatively simple. Columns do not support automatic sorting based on conditions, nor do they support grouping or filtering. However, their display can be manually configured using the hidden attribute. Similarly, each view maintains independent column order data.

A database view is a subset of a database and is based on a query that runs on one or more database tables.

Similar to the concept of views in relational databases, the views in APITable also represent an independent set of data query definitions. In APITable, each view has independent and non-interfering filter, group, and sort parameters to determine which records appear in what order on the user interface. In most views, these three options will appear.

View toolbar with highlighted configuration options

Filtering

Screenshots of some examples of filtering

The implementation of the filtering function is closely related to the field type. Different field types can define their acceptable filtering conditions and, like cells, can control the basic type of filtering values.

In other words, fields of different types need to independently implement filtering logic. For example:

• The filtering box for single- or multiple-select only allows selection, and the matching is based on the option ID rather than the text.

• Date fields perform date filtering instead of number filtering.

Table of field types and their corresponding supported filtering conditions:

Sorting

Screenshot of an example of sorting

From the above screenshot, we can see that the sorting function has an "Auto Sort" option. When the Auto Sort switch is turned off, the sorting rule only takes effect once, and the rows can be manually dragged and sorted after sorting.

When the Auto Sort switch is turned on, it means that any data changes will be re-sorted, and the user cannot manually drag the row order or insert a record at a specified position.

In terms of data structure, a single sort will directly modify the order of the rows, while automatic sorting will generate a new sorted rows based on the order of the original rows.

Sorting rules:

• For numeric types, sorting is done by direct numerical comparison.

• For text types, sorting is done based on ASCII code and Chinese Pinyin order.

• For single or multiple selection, sorting is done based on the order of options defined in the field, rather than by string sorting.

• Date sorting is relatively complex and the strategy is dynamically adjusted based on whether the year is displayed.

Grouping

Screenshot of an example of grouping

You can imagine that after sorting the data, the same data will naturally be closely arranged together. When there is a difference in data between two neighboring records, we call it a "breakpoint". We only need to visually separate it on the UI at the breakpoint to achieve grouping layout.

Therefore, the grouping function is actually another sorting function. As with sorting, we also need to select "ascending" or "descending" order for the field.

However, grouping is very different from sorting. In the previous chapter Fields, we mentioned that there is a concept “formatter” of storing and displaying values differently. When sorting, we always use the most accurate stored value for sorting. But for breakpoint selection, we use the value after formatting. This is because people tend to group values that look the same.

Another difference is that when dealing with array-type fields, such as multiple select, even if the order of options is different, they should still be grouped together. For example,

Lazy Sorting

Lazy sorting is not actually a sorting function, but rather a prompt behavior given to the user when the position of a record changes due to a change in its value or when it is about to disappear from the view.

Screenshot of an example of lazy sorting

Taking the above images as an example, the "Order" column has already been set with an automatic sorting condition in ascending order. When the user changes the value of 2 to 5 and the cursor is still on that row, the lazy sorting feature will be activated. This prevents the row from immediately moving to the last row, allowing the user to complete the modification of the entire row without interruption before the record moving to the corresponding position.

Implementing this feature requires temporarily storing the pureVisibleRows before the data changes, but due to space limitations, a detailed description will not be provided here.

Homework

1. In two views that have not set any filters, sorting, or grouping, Is the order of the rows the same?

2. Are the lengths of rows stored in each view the same in a snapshot?

3. Two cells of a multiple-select column respectively contain Salad, Pizza and Pizza, Salad. Will they be grouped together?