Using a calculate in a form field

Ash Forum Ash Questions / Help
,
1

Hello,

first time playing around with Ash and hitting a wall. I’m trying to use a calucate in a form field. Lets say I have an attribute :duration, :integer and an attribute :duration_unit, :duration_name in a resource, and a calculate :duration_option, expr(duration <> " " <> duration_unit).

If I try to use the duration_option in a form field, I’m only getting a generic error from AshPhoenix.Form.submit.

I’ve looked at the custom composable types, but I’m using AshSqlite and it does not support this.

I guess “I’m using it wrong”, could someone point me at the “Ash” direction, please? :slight_smile:

Thanks alfred

1 Like
2

Without knowing what your form looks like or what error you’re seeing, its hard to know what your issue might be! Can you share those, as well as what you’re trying to do?

3

Okay, so the expression might be the issue:

iex(1)> Ash.Expr.eval "a" <> "b"
{:ok, "ab"}
iex(2)> Ash.Expr.eval "a" <> 1
** (ArgumentError) expected binary argument in <> operator but got: 1
    (elixir 1.18.2) lib/kernel.ex:2074: Kernel.wrap_concatenation/3
    (elixir 1.18.2) lib/kernel.ex:2065: Kernel.extract_concatenations/2
    (elixir 1.18.2) lib/kernel.ex:2061: Kernel.extract_concatenations/2
    (elixir 1.18.2) expanding macro: Kernel.<>/2
    iex:2: (file)
iex(2)>

Also, I’m confused about using duration_option in a form field; don’t you mean the form should support entry of attributes that are used in calculation, not the calculation it self.?

4

Thank you for your reply, excuse my brevity, my resource looks like this:

attributes do
  uuid_primary_key :id

  attribute :email_address, :string do
    allow_nil? false
  end
  attribute :duration, :integer do
    allow_nil? false
  end
  attribute :duration_unit, :duration_name do
    allow_nil? false
  end

  calculations do
    calculate :duration_option, :string, expr(duration <> " " <> duration_unit)
  end
end

and in my LiveView I create the form:

def mount(_, _, socket) do
  form = MyApp.MyDomain.form_to_create_my_resource()
  socket = assign(socket, :fom, to_form(form)
  {:ok, socket}
end

def render(assigns) do
~H"""
<.simple_form
  :let={form}
  for={@form}
  as={:form}
  id="my_resource_form"
  phx-submit="save"
>
  <.input field={form[:email_address]} placeholder="email" />
  <.input field={form[:duration_option]} type="select" prompt="Please select" options={duration_options()} />
  <:actions>
    <.button type="primary">Save</.button>
  </:actions>
</.simple_form>
"""
end

defp duration_options() do
  [
    "30 seconds": "30 seconds", 
    " 1 minute": "1 minute", 
    "5 minutes": "5 minutes"
  ]

def handle_event("save", %{"form" => data}, socket) do
  case AshPhoenix.Form.submit(socket.assigns.form, params: data) do
    {:ok, resource} ->
      # handle ok case, flash and nagivate, ...
    {:error, form} ->
      # display form again
  {:noreply, socket}
end

The error is, that duration and duration_unit are required fields.
I’m trying to use a select field with two database/resource attributes and want to populate the attributes from one virtual field.
In the pre-Ash era, I would’ve parsed the returned form value and written the result to the changeset (direction to db) or joined it for the form field value (direction from db).

The Composite Type in Ash looks exactly like that, but unfortunately AshSqlite does not seem to support those.

I guess calculations are only for the direction from db case?

5

I want to create a virtual form field (select) which populates, and is populated from two resource attributes, I hope my other answer to sevenseacat make my use case clearer to understand.

6

I understand now.

iex(1)> Ash.Expr.eval "#{1}" <> " " <> "minutes"
{:ok, "1 minutes"}

:point_up: this works for an expression btw.
So if you put in the form the required fields and send them to submit the error would be resolved. Then you could get that submitted entry and load the calculation.

But from what I gather you want the other way. You could parse data into params that have required field.

7

Calculations are likely not the fit here. You are likely looking for arguments. In your create action:

create :create do
  accept [:email_address]
  argument :duration_option, :string, allow_nil?: false
  change SetDurationAttributes
end

defmodule SetDurationAttributes do
  use Ash.Resource.Change

  def change(changeset, _opts, _context) do
    case parse_duration(changeset.arguments.duration_option) do
       {:ok, duration, duration_unit} ->
          Ash.Changeset.force_change_attributes(
            changeset, 
            %{duration: duration, duration_unit: duration_unit}
          )
      {:error, error} ->
        Ash.Changeset.add_error(changeset, error)
    end
  end
end
8

Thank you, if I understand this correct, I’d have to call the :create action with the value of duraction_option from the form as an argument?
Regarding :reading from the database, would that also work with arguments?

Feel free to let this problem rest for a while, I understand I need to read more (and more…, and the book too) :slight_smile: Thanks for all the responses.

9

You can use arguments on reading yes. it is also possible that you want the calculation for display still. The main thing is that nothing will “reverse engineer” the underlying attributes by virtue of trying to change the calculation. You’ll need arguments for that.

10

I’ll ponder over that.

11

I read a little more in the Ash Framework book and in chapter 2 they use the transform_params option to the form_to_create_resource call, so I tried it like this:

def mount(_, _, socket) do
  form = MyApp.MyDomain.form_to_create_my_resource(
    transform_params; fn _form, params, _context ->
      parse_duration(params)
    end
  )
  socket = assign(socket, :fom, to_form(form)
  {:ok, socket}
end

This works for me as expected, as I understand it, if I’d use argument and change it would work on the Ash.Changeset, but as far as my example goes, working on the params directly is good for me.
I used the calculation too for the <select> form field value by the way.

Thanks again, this was fun playing around with :smiley: I will definitely use this on my next project.

1 Like
12

Okay, I can see the benefits of using arguments and changes now. It encapsulates the parsing and converting logic into the resource (or into a Ash.Resource.Change module) and not into the Form. This is much clearer for me, and the prefered solution.

3 Likes