PaleWatcher
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?
Where Next?
Trending in Questions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Enabling companies to succeed by building software people love.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #ai
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Enabling companies to succeed by building software people love.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 4- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
NobbZ
Can’t you check
_target?LostKobrakai
You can use the _target to see which field triggered the event.
PaleWatcher
From the replies, it seems pretty clear that
_targetis the obvious answer here, since the real problem is simply preserving which field the user actually edited.So the actual design question becomes:
once
_targettells you which input triggered the change, where should that information live?Would you usually:
_targetinto a virtual field in the changeset (for example:calculation_sourcewith values like:price_entered/:discount_entered) and keep the calculation logic inside the changesetor
handle_event/3in LiveView before building the changesetMy 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?
LostKobrakai
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.