Suppose you have two fields in a Phoenix LiveView form where both are user-editable, and each one can be used to calculate the other.
Example:
A → derive B
B → derive A
Both inputs are valid entry points for the user.
The problem is that phx-change submits the entire form on every input change.
Once the form is submitted, the changeset receives both values at the same time and no longer knows which field was the actual user input and which one should be treated as the derived value.
A few obvious approaches seem problematic:
- always prioritizing one field breaks UX
- relying on
changed? can be unreliable because both fields may appear changed after recalculation
- moving logic outside the changeset makes validation and calculation harder to keep consistent
What is considered the idiomatic Phoenix/Ecto approach for this kind of bidirectional dependency?
How do you usually preserve which field was the real user input when the whole form is submitted on every change?
You can use the _target to see which field triggered the event.
From the replies, it seems pretty clear that _target is the obvious answer here, since the real problem is simply preserving which field the user actually edited.
So the actual design question becomes:
once _target tells you which input triggered the change, where should that information live?
Would you usually:
- Map
_target into a virtual field in the changeset (for example :calculation_source with values like :price_entered / :discount_entered) and keep the calculation logic inside the changeset
or
- Handle the recalculation directly inside
handle_event/3 in LiveView before building the changeset
My instinct is that option 1 feels cleaner, because LiveView stays thin and the changeset remains responsible for business rules.
Is that considered the more idiomatic Phoenix/Ecto approach?
https://medium.com/very-big-things/towards-maintainable-elixir-the-core-and-the-interface-c267f0da43
Given the distinction made in that blogpost the logic belongs very much in the interface, not the core. This specific form in question is concerned with that auto calculation, but the next one might not be. I‘d expext the core just needs data to be aligned by whatever means most useful depending on the source for the data.
Both core and interface might still use changesets though.
