Enable the application of field selection algorithms

[kiahna-tucker]

Last Updated: Jul. 28, 2025

---

Include a brief description of the request here, especially if explicit requirements have yet to be defined.

Below are the base requirements for this feature: (TBD)

• Integrate the WASM function, evaluate_field_selection, which evaluates which fields should be materialized based on collection projections, user configuration, connector constraints, and existing materializations. All changes to field selection in the client must be processed by this function.

• Align the styling of the field selection table with that of the collection schema table.

  • Use an outlined chip to display the field name in the Field column. The standard, outlined chip styling should be used for a field that will be materialized (a.k.a., selected); the diminished, outlined chip styling should be used for a field will not be materialized (a.k.a., rejected); and an outlined chip in the error color should be used for a field that has a conflict.

  • Use the monospace font to display the pointer in the Location column.

• Add an Outcome column to the field selection table that uses an icon to indicate one of the following states: a field will be materialized (a.k.a., selected), a field will not be materialized (a.k.a., rejected), or a field has a conflict.

  • The single outcome reason and detail should be displayed in a popper for a non-conflicting field upon hovering or clicking the icon; whereas the reason and detail of both the select and reject outcomes should be displayed for a conflicting field.

  • The following icons should be used to indicate outcome states: BookmarkSolid for a field that will be materialized (a.k.a., selected), Bookmark for a field will not be materialized (a.k.a., rejected), and WarningTriangle for a field has a conflict.

  • Use the primary color of the application theme for icons indicating non-conflicting outcome states; use the semantic error color for the icon indicating a conflicting outcome state.

• Order the field selection table columns as follows: Field (fixed/sticky on horizontal scroll), Location (optional), Type, Actions, Outcome.

• Prevent the user from initializing a publication when at least one binding contains field conflicts.

• Use the primary color of the application theme to indicate a field selection table row action is in a selected state.

• Remove the Select button from the set of field selection table row actions. Field outcomes provide a better indication and contextualization of the impact of a binding's field selection; the Outcome column should be referenced to determine whether a field will be materialized.

• Limit the field selection mode options to the following: Depth Zero (i.e., recommended: 0), Depth One (i.e., recommended: 1), Depth Two (i.e., recommended: 2), and Depth Unlimited (i.e., recommended: true).

• Add an Exclude All mass action to the field selection table. This button will appear to the right of the Mode CTA. Clicking the CTA will result in the fields currently shown in the table to be explicitly excluded (i.e., added to the exclude array of the binding's fields stanza).

• Add a footer to the field selection table that displays a count of selected, rejected, and conflicting fields. This would be similar to the count of enabled, disabled, and backfilled bindings at the bottom of the binding's list.

Dependencies

Last Updated: Mar. 11, 2025

• WASM support. A WASM function that informs the client of the outcome of the chosen field selection algorithm (i.e., which fields are required, selected, and excluded).

Additional Comments

• The markdown file used to document the WASM function, evaluate_field_selection, can erroneously express relevant interfaces (e.g., FieldSelection) or have vague descriptions of properties (e.g., FieldSelectionInput). The field selection crate should be cross referenced to validate type annotations.

References

Code

• Field selection crate. The definition of the WASM function, evaluate_field_selection.