Organizing changesets: universal vs. per-operation vs. per-role

You can also do like @sasajuric https://medium.com/very-big-things/towards-maintainable-elixir-the-core-and-the-interface-c267f0da43 and move changesets to your context.

Me personally, I like to stick with a single schema changeset function and have special changeset functions rarely, when needed. For special fields like :is_admin or something.

I keep separate changesets for different functionality. You can also compose changesets, which I don’t see mentioned often.

E.g. I have a Bookmark schema which holds both user fields (the name and url) and data fetched from the web (title, page content, an image url, etc). Both need to be validated, but sometimes I only need to validate the latter (when fetching later).

So on creation I can do this:

%Bookmark{}
|> Bookmark.user_changeset(%{name: "foo"})
|> Bookmark.metadata_changeset(%{title: "Hello world"})

But if I was just updating the fetched metadata I could do this:

Bookmark.metadata_changeset(bookmark, new_metadata)

The distinction in this case is that the user fields are validated for the user while the metadata fields are validated with very large constraints mostly as a sanity check (e.g. 4096 char limit for a URL, which should never be hit by normal use).

IMO functions are basically free, make as many of them as you need to keep things clear.

The worst possible messes I’ve seen in code have been when everything was jammed through a “universal” function and then the needs of different callsites diverged. Suddenly every place that Foo.change_all_the_things is called needs to be reviewed (it’s covered by tests, right?)

Regarding the last case you mention (test setup / factories) - there’s no rule that says those can’t have their own test-specific modules. I’d keep the “change every column” stuff there in preference to having it sitting around in the main app waiting for misuse.

Same. Good prefixes do the job, provided you don’t need 20+ changesets.

Absolutely one of my favorite things I’ve picked up from him. That tip alone convinced me to read Elixir In Action. It can be combined with “changeset functions” by abstracting common pieces into the schema when that becomes a good refactoring opportunity.

Hmm yeah that resonates with the part of me that wants a stronger separation between my web layer and the rest of my app.

Yeah I think I’m coming back around to that approach.

I think there’s a balance there, balancing “as many of them as you need” with DRY principles. I’ve written functions before that did essentially the same thing as each other with minor differences, then as “essentially the same thing” became increasingly complex how each function handled the edge cases started unintentionally to diverge a bit. But that’s probably more a sign I needed to refactor at that point. And they weren’t just changeset functions.

I like that idea. Do you find that the common pieces are usually more like entire changeset functions for a subset of fields or more like custom validations and such?

Usually there is a set of base required fields and other validations that I put there. Logic that would be shared between all context functions manipulating changesets, less to DRY anything up and more to make things explicit and as self-documenting as possible. I tend to be really particular about API surface so I generally only cast fields, for example, that are needed by some client for a specific operation, so I don’t find putting cast logic there to be as helpful as it would be if you just include all fields by default.

I’m probably going to get drug through the mud for this, but…

I just put changeset functions directly in my LiveView, not in my models. So far, I’ve never had to reuse them, so I just make them specific to the page they are being used on.

Further, more often than not, the form being rendered does not map 100% cleanly to any model. So there is an an Ecto embedded_schema directly in the LiveView also…

If there is a need for sharing, I’ll refactor into a model or context.