React custom views: items left for later, if ever #1971

These items remain after the React custom views work tracked in #1666. They are deferred for later, if ever; this list does not commit to a future phase or schedule.

Empty descriptors

Some entries in data remain present even when they have no fields. Consider whether such empty descriptors should continue to be present or be omitted. Keeping them lets a component rely on the entry existing; omitting them would require checking for absence. Deferred because changing this affects that existing contract, and should be considered together with the shape of container data.

Data along the container hierarchy

Consider making data and the corresponding controller follow the nesting of form containers, instead of container entries appearing separately at the same level. Deferred because a React component already knows the form structure it draws, so the benefit of changing this shape remains unclear.

Runtime page size for a React view

Let a React view change its list's page size at runtime, for example when its layout changes. A form can already declare a fixed size:

FORM orders
    OBJECTS o = Order PAGESIZE 100
;

PAGESIZE 0 requests all objects, and useSeekOnScroll supports following the visible rows (#1723). Runtime sizing is deferred until a concrete view needs more than these routes provide.

Tree-node loading after an error

After a failed tree expansion, a node's loading can remain true until a later tree update, leaving the view showing a spinner after the request has failed. Consider ending that loading state when the failed expansion finishes. Deferred with the platform tree's existing failure behavior; the delivered tree support in #1672 retains this limitation.

Pin buttons under NAVIGATOR CUSTOM

Under NAVIGATOR CUSTOM, the navigator's and the log's pin buttons change a saved setting but have no effect on the page. Deferred together with deciding how pinning should affect a layout drawn by the application's component.

Platform data loss when changing an object to a subclass

In one session, deleting one saved object of a class, or changing its class so that it leaves that class, and changing another saved object of the same class to a subclass loses the latter object's class-level DATA and saved references to it. Either order triggers the problem; APPLY persists the loss.

For example, given two distinct, already saved A objects with name(promoted) set:

CLASS A;
CLASS B : A;
name = DATA STRING (A);

changeTwoObjects(A removed, A promoted) {
    DELETE removed;
    CHANGECLASS promoted TO B;
    APPLY;
}

The promoted object's name and references to it should survive its move to B. This is a platform data issue, independent of React. It is deferred because CHANGECLASS is rarely used.

COLUMNS — #1676

A React matrix needs to enumerate columns, read each cell's value and presentation, and edit cells addressed by both a row object and a column object. Ordinary row properties, Buckets (#1703) and per-row platform editors (#1722) do not provide that behavior. This requires a separate matrix contract, so it is deferred for later, if ever, with #1676 kept as its own open issue.