Ash has three concepts that map to the concept of a virtual field. Often, virtual fields exist to simulate one of these three things

Arguments

Arguments are action-specific inputs. For example:

create :register do
  accept [:email]
  argument :password, :string, allow_nil?: false
  argument :confirm_password, :string, allow_nil?: false
  validate confirm(:password, :confirm_password)
  change EncryptPassword
end

In the example above there is no “password” attribute, but we have two arguments that we use to ultimately write to that attribute.

Calculations

Another thing virtual fields are used for in ecto is storing computed values. In Ash we use calculations for that. For example:

calculations do
  calculate :full_name, :string, expr(first_name <> " " <> last_name)
end

Action-specific metadata

Finally, we have action-specific metadata. An example might be returning an authentication token from a sign in action (something ash_authentication does)

read :sign_in do
  get? true
  # this just declares that some metadata will be placed on the result called `token`
  metadata :token, :string, allow_nil?: false

  ... logic for signing in.
  prepare CreateAndSetToken # some logic to create and set that token metadata
end

Then the result of that will be in record.__metadata__.token.

Hope that helps!

Where do your custom field values get stored? I assume in a map-typed attribute in the resource? And then to accept them as input you’d need to accept a map of custom field values too? So then you could do things like (just as a potential example)

<.input name={@form[:field].name <> “[field_1]”} id={@form[:field].id} value={@form[:field].value}/>

And you could probably make that into its own custom_field_input component