Naming Elixir Phoenix context functions

https://www.stephenlewis.me/blog/naming-phoenix-context-functions

by amalinovic • 4 years ago

74 25 4 years ago

If you treat your storage as a separate subsystem you’ll likely not face the problem with `create_changeset`. I’m saddened to see that almost every Phoenix project is tightly coupled with the database as every context function calls the database and clean business logic is nowhere to be found. Also, why are we using the contexts directly in the controllers and keep the top-level module empty?

rapnie• 4 years ago

Jenny Shih did a conference talk about how Phoenix Contexts fit into Clean Architecture project organization. The slide deck is here (sample code is on Github): https://speakerdeck.com/jennyshih/context-driven-development...

nesarkvechnep5• 4 years ago

The talk is on YT and it’s easy to find by the title.

I forgot to mention, whenever I see Ecto schema structs bubbling up to the views, I want to throw up.

melx• 4 years ago

The relevant Github repo https://github.com/jenny-codes/elixirlab

jnsaff2• 4 years ago

Do you have references to Phoenix projects where they are doing it right in your opinion?

monooso5• 4 years ago

Hello, article author here. Can you expand on what you mean by top-level module?

My understanding of contexts (from the docs) is that they are intended to "...encapsulate data access and data validation." They're intended to be the layer of your application that talks to the database. Do you have a different approach?

beckler• 4 years ago

Not OP, but I think he might be hinting towards something like this:

https://learn-elixir.dev/blogs/creating-reusable-ecto-code

zachallaun2• 4 years ago

I don’t know what the person you’re responding to is getting at, but I found the article very useful! Exposing the changeset through the context is also useful in LiveViews when dealing with forms — once the changeset is valid, calling the relevant function with the same attrs should succeed.

Re: the sibling comment referring to queries, nothing you’re doing in the article prevents that.

Ecto’s changesets are often an unfamiliar concept, so I wonder if that’s where some confusion is coming from.

sodapopcan2• 4 years ago

I _think_ they are talking about treating the top level module as the facade for the whole application, which is something I've thought about doing a bunch. IE, it would be full of delegates to all your contexts and then _every_ public function is available off of it.

I don't think this is a terrible idea but I like to draw boundaries and say "It's ok to reach one level deep from any point in the context tree".

ie App.Chat.send_message/2 is cool, but MyApp.Chat.Messages.send_message/2.

Existenceblinks• 4 years ago

Yeah. Trying to teach specific practices confuses people. Naming and "context" should not matter (in a sense of consistency) much .. if at all. My take is "context" is just "module" and schema is just "type". I'd like to think in ML languages style.

zachallaun2• 4 years ago

Also, why are we using the contexts directly in the controllers and keep the top-level module empty?

Because the context is the “public API” for the rest of your application to use. You can have as many layers below the context as you want, often purely functional, composable, and testable.

nesarkvechnep5• 4 years ago

The contexts are boundaries, places where you use process machinery and might call other subsystems, or services, but they’re not the application’s public API. You might want to check Bruce Tate’s book “ Designing Elixir Systems with OTP”.

sodapopcan2• 4 years ago

I get it--or maybe I don't deeply get it-- but I don't really find this a huge concern for most web apps. If I know that my app is never not going to have a db, then what is that extra step of that decoupling buying me? I still have fast tests due to transactional rollbacks, and I can even perform certain business logic in the db nicely with Ecto when it's a better fit than the BEAM.

Ankhers2• 4 years ago

I'm not really following this. The only problem the author has is with the name `create_changeset`. It may not be obvious to someone just starting with Elixir and Ecto what that means, but it is a naming convention that most (all?) projects use. You should be able to get the hang of it fairly quickly.

This may just be the simplicity of the example they have, but they also have an `update_changeset`, which I think is an anti-pattern. You should be creating a different changeset for each operation that can be applied to a given schema. In the case of a user, you may be able to change a password, or an email address separately from being able to change a screen name or something. You should be creating separate changeset functions for each of those operations.

The author also puts a foot note at the end stating that they would usually create a `base_changeset` function that can be reused for common parts of a changeset. Please don't do this. Just create multiple reusable functions for each check. For example, you may create private functions in the schema for `validate_email`, `validate_password`, etc. These are the reusable pieces that you most likely want to have and can be used from within any changeset. Then you will be able to mix and match them as needed instead of trying to come up with a truly base changeset that applies to everything and still have a lot of validation rules duplicated between various changesets.

monooso5• 4 years ago

...they also have an `update_changeset`, which I think is an anti-pattern.

I disagree that it's an anti-pattern. I'm already making a distinction between a "create" and an "update" changeset, as these may have different validation rules.

Of course, some situations may warrant separate changesets for operations on individual fields (updating an email address, updating a password, etc.), but in practise I rarely find this to be useful.

Please don't do this. Just create multiple reusable functions for each check.

It's worth noting that these aren't mutually exclusive approaches; we regularly use both on my current project.

Ankhers2• 4 years ago

I will agree that not every situation will require multiple kinds of updates. For those situations an `update_changeset` may be considered okay. I now realize how definite my wording sounds. But I just meant that if you have multiple update operations, that should be exposed as multiple changeset functions. If you have multiple update operations but a single update_changeset function, it is possible to send the server data you did not intend to be sent together and now you are changing things that were not originally meant to be changed together. This has happened in previous projects I have worked on and now prefer the be explicit with multiple changeset functions.

Naming Elixir Phoenix context functions

Related Stories