This could be simplified to:

export type FieldElementsSource =
	| Option[]
	| Promise< Option[] >
	| ( () => Promise< Option[] > );

I was thinking that elements could be either Option[] or an async function, as the async function enables the framework to trigger retrieval when necessary. However, having the Promise<Option[]> as well enables consumers to trigger retrieval instead. Nothing against it, I am just curious if you have any more thoughts about this.

Promise<Option[]> gives consumers an easy path to get started; it makes the code less verbose than an async function. That's the only benefit of accepting a Promise. In my opinion, it doesn't pollute the type, so I think we should accept that.

Regarding the async function, I think we should still support returning a synchronous array. By doing so, we can better accommodate use cases when the data is already available or computed synchronously, for example, derived lists built from other props or localStorage (not a fan, though :D). We're giving consumers flexibility without trading much complexity, so I think we should do it.

After consideration, I decided to support only array or async, as you suggested. We should start by focusing on what matters most.

This approach triggers retrieval at the leaf: elements are fetched when the components that need them are mounted (dataform controls, filters). This is good for minimizing memory/computing. However, I am concerned about how this impacts user perceived performance. There are some other places where we should also trigger "leaf" retrieval: the render methods of the field types.

What would you think of triggering the retrieval (call useFieldElements) in normalizeFields instead? That way, the elements may already be loaded when the user opens a filter, and we centralize this process for all components that work with elements (render, filters, etc.).

What would you think of triggering the retrieval (call useFieldElements) in normalizeFields instead? That way, the elements may already be loaded when the user opens a filter, and we centralize this process for all components that work with elements (render, filters, etc.).

We should consider the trade-offs involved. While this can make the UI feel snappier and faster, I have some concerns with this approach.

• Firstly, scalability is an issue. A list can have many filters, and fetching all data at once can lead to performance issues.
• Secondly, we know that we need search and pagination. So we still need to retrieve the data at the leaf. We are creating two mechanisms for fetching the data, and I'm afraid it makes our codebase more complex.
• Lastly, if we want to retrieve everything in a normalized format, we may need to introduce another cache layer to store data. We have one for entities already. I don't think we need another one.

Given these pros and cons, I believe it's best to keep retrieval at the leaf for now. wdyt?

Let's try this way and re-evaluate when we have everything working (searching, etc.). This means we need fetching them every time they are potentially used, because it may be the first time. For example, we need to fetch them in render as well.

I corrected some words in my comment. I used dictation but missed fixing them.

Let's try this way and re-evaluate when we have everything working (searching, etc.).

@oandregal So you mean moving the fetch to normalizeFields, right?

No, leave it as you proposed in this PR (fetching at the leaves). But we need to cover all use cases (every place that uses elements, including render).

Do we need these? I don't think we should retrigger element retrieval. Though perhaps error could be displayed in controls and render as in Elements could not be loaded.

Do we need these?

We don't have it now. But I believe we need retriggering for search and pagination. I can remove it for now and reconsider the API when adding search and pagination support.