Built-in Selection Providers

Reference for the built-in selection providers available in SolidX, including `ListOfValuesSelectionProvider` and `PseudoForeignKeySelectionProvider`.

Overview

SolidX ships with two built-in dynamic selection providers so you can wire up common dropdown patterns without writing any code. If you need something more advanced, see Dynamic Selection Providers for creating your own.

Provider	Use case
`ListOfValuesSelectionProvider`	Populate a dropdown from List of Values metadata entries
`PseudoForeignKeySelectionProvider`	Populate a dropdown from records in any existing model, creating a lightweight foreign-key-style relationship without a formal database relation

ListOfValuesSelectionProvider

Use this provider when the options for a field come from your List of Values metadata. It filters LOV entries by type and maps each entry's display to the label and value to the stored value.

Context

The context object passed via selectionDynamicProviderCtxt accepts:

Key	Type	Required	Description
`type`	`string`	Yes	The LOV type to filter by (e.g. `"REGULATED_BY"`, `"INDUSTRY"`)

Field Metadata Example

Example: Dynamic selection field using ListOfValuesSelectionProvider

{
  "name": "regulatedBy",
  "displayName": "Regulated By",
  "description": "Regulated By",
  "type": "selectionDynamic",
  "ormType": "varchar",
  "isSystem": false,
  // highlight-start
  "selectionDynamicProvider": "ListOfValuesSelectionProvider",
  "selectionDynamicProviderCtxt": "{\"type\": \"REGULATED_BY\"}",
  // highlight-end
  "selectionValueType": "string",
  "required": false,
  "unique": false,
  "index": false,
  "private": false,
  "encrypt": false,
  "isUserKey": false,
  "enableAuditTracking": true,
  "isMultiSelect": true
}

How It Works

SolidX reads the selectionDynamicProviderCtxt and extracts the type value.

The provider queries the internal ListOfValuesService with a filter of type = <your type>.

If the user types a search query in the dropdown, the provider additionally filters by display, using case-insensitive contains.

Each matching LOV record is mapped to { label: record.display, value: record.value } and returned to the UI.

Where LOV Data Comes From

The LOV entries themselves are defined in your module's metadata file under the listOfValues key. See the List of Values metadata schema for details on how to define them.

You can also refer to Configuring List of Values for instructions on how to manage LOV entries via the admin UI.

PseudoForeignKeySelectionProvider

Use this provider when you want a dropdown whose options come from records in another model - without creating a formal database foreign key relationship. This is useful for loosely-coupled references where a full relation is overkill or the models live in different modules.

When to Use This Provider

Use PseudoForeignKeySelectionProvider when you need to link data from a co-model, or any other model, to your current model but you cannot or do not want to create an actual database relation between them.

Example scenario: Suppose you have a customer model in one module and a country model in another. You want the user to pick a country when creating a customer, but you do not want a formal foreign key. With this provider, you can populate a dynamic dropdown from the country model's records while keeping the two models completely decoupled at the database level.

Context

The context object passed via selectionDynamicProviderCtxt accepts:

Key	Type	Required	Description
`modelName`	`string`	Yes	The name of the model to query (e.g. `"country"`)
`labelFieldName`	`string`	Yes	The field on the target model to use as the display label
`valueFieldName`	`string`	Yes	The field on the target model to use as the stored value
`whereClauseFields`	`string[]`	Yes	Fields on the target model to search against when the user types a query

Pagination Support

The provider also respects the standard limit and offset context properties for pagination.

Field Metadata Example

Example: Dynamic selection field using PseudoForeignKeySelectionProvider

{
  "name": "countryOfIncorporation",
  "displayName": "Country of Incorporation",
  "description": "Select the country of incorporation",
  "type": "selectionDynamic",
  "ormType": "varchar",
  "isSystem": false,
  // highlight-start
  "selectionDynamicProvider": "PseudoForeignKeySelectionProvider",
  "selectionDynamicProviderCtxt": "{\"modelName\": \"country\", \"labelFieldName\": \"countryName\", \"valueFieldName\": \"countryCode\", \"whereClauseFields\": [\"countryName\", \"countryCode\"]}",
  // highlight-end
  "selectionValueType": "string",
  "required": true,
  "unique": false,
  "index": false,
  "private": false,
  "encrypt": false,
  "isUserKey": false,
  "enableAuditTracking": true,
  "isMultiSelect": false
}

How It Works

SolidX reads the selectionDynamicProviderCtxt and extracts modelName, labelFieldName, valueFieldName, and whereClauseFields.

The provider uses SolidIntrospectService to look up the CRUD service for the specified model at runtime.

If the user types a search query, the provider builds an $or filter across all whereClauseFields using case-insensitive contains, \$containsi.

The matching records are mapped to { label: record[labelFieldName], value: record[valueFieldName] } and returned to the UI.

When to use which?

Use ListOfValuesSelectionProvider when your options are a fixed, admin-managed set defined in metadata (e.g. statuses, categories, industries).
Use PseudoForeignKeySelectionProvider when your options come from live records in another model (e.g. countries, clients, products).
If neither fits, create a custom dynamic selection provider.

Built-in Selection Providers

On this page