Virtual attributes mirroring Ecto's virtual fields

haubie

Question to the Ash gurus: in the same way Ecto schemas can have virtual fields (e.g. by passing the virtual: true option, so that those fields are part of the schema/struct but not persisted to the database), does Ash have a similar concept for attributes? e.g.

attributes do
  # Core data, persisted
  attribute :title, :string

  # Virtual attribute, not persisted
  attribute :placeholder, :string, virtual: true
end

I’m very much new to Ash and learning by migrating a current project to use it (the Ash livebook tutorial is a fantastic intro, well done whoever created that!). By doing this, the benefits of the framework are becoming more obvious to me.

I’ve only run into one stumbling block which was a situation where I was using Ecto’s virtual fields. I’ve taken a look at the documentation and source code on Ash attributes and Ash.Types, but couldn’t see any obvious equivalent.

Thank you!

7 comments

/ash #virtual-fields

1 1227 7

2024-09-23 04:15:30 UTC

Showing Posts 1 to 7

Show Best Posts
Show All (oldest first)
Show All (newest first)

zachdaniel

Creator of Ash

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!

Post #1

haubie

Great, thanks very much @zachdaniel, appreciate the thorough answer!

I was looking in the wrong place, it hadn’t clicked with me that there were some action-specific approaches rather than defining them as part of the attribute block.

Post #2

kamaroly

Can a metadata attribute be used in AshPhoenix Form?

Post #3

zachdaniel

Creator of Ash

Hmm…not really. You could use the value of a metadata field, with something like value={form.source.data.__metadata__[:metadata_field]}, and then you’d have an argument w/ the same name as that metadata that sets the metadata accordingly. But I’m not sure why you’d want to do that.

Post #4

kamaroly

I have added custom_fields which has an array of multiple fields. I want to dynamically add each field to the form so can use it like <.input field={@form[:custom_field_id]} />

Here’s the structure of the data:


%Resource{
    Id: UUID STRING,
    title: "just a test",
    custom_fields: [
      %{
   
        "id" => Ash.UUID.generate(),
        "type" => "text",
        "value" => "John",
        "name" => "name",
        "options" => [],
        "description" => "Description of the field",
        "is_required" => false,
        "default_value" => "New Name",
        "order" => 1,
        "placeholder" => "Field placeholder",
        "label" => "Field Name"
      }
    ]
  }

Post #5

zachdaniel

Creator of Ash

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

Post #6