elt547
I’m new to elixir, and I’m finding that I often have files have many responsibilities, which I’m not fond of. One frequent occurrence of this I’m seeing is the context files in a phoenix project. If you have many different schemas under that context, you end up having a ton of boilerplate like create_user, create_account, create_admin right next to each other. I really don’t like this and I could see this growing out of control very quickly in a project of consequence. I can’t open up modules for modification in more than one file, as things are overwritten. I’m at a loss at how to deal with this and in my opinion it’s a big downside of using elixir/phoenix and the default code generators in phoenix.
Does anyone have any tips or resources on using files to separate code in elixir?
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Catch errors, track performance, monitor hosts and more.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #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
- #ai
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Bringing learning, work and compliance together since 1987.
Producing high quality Elixir screencasts since 2017.
**Building the future of software with AI, trust, and human connection.**
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)
Hermanverschooten
I like. what Sasa does in his talks, eg https://www.youtube.com/watch?v=6sNmJtoKDCo
beepbeepbopbop
I would also recommend reading a multi part series as well that Sasa wrote: https://medium.com/very-big-things/towards-maintainable-elixir-the-core-and-the-interface-c267f0da43
That’s one part of the 4 I think, of which every single one has incredible value to be pulled from. Like anything, don’t be too dogmatic about it, it’s very likely you won’t nail it the first couple of times, but as long as you have these concepts in the back of your head, certain patterns tend to emerge.
eahanson
One trick is to generate a new Phoenix app in some scratch directory, use Phoenix schema etc. generators there, read the generated code, and then implement something similar by hand in your real app, putting everything where you want it.
tfwright
I’ve observed this as well and I’ve diverged more and more from Phoenix scaffold over time. I think of it kind of like a pattern for a suit. It might work well unaltered for a certain range of people/venues, but as the tailor it’s my job to know who is going to wear it where, and with what shoes, and cut and shape accordingly.
To be a bit more specific, following Saša Jurić I first started managing changesets right in the context, ditching the schema changeset functions. But this does make context bloat even worse so I have started moving create/update functions back to schemas, reserving contexts for true “glue code” (e.g. ‘new registration’ endpoint that creates several rows across tables, and sends an email, etc), something I doubt he would endorse. But on this very forum Saša has given advice contradicting guidance in those articles, so the main thing I follow him on is not being too attached to the purity of abstract rules. More than anything, I hate premature optimization with a passion so I try to always be guided by the domain rather than framework boilerplate, even a framework as well thought out and designed as phoenix.
One caveat: consistency does have a lot of intrinsic value that has to be balanced against this kind of customization/experimentation in a domain, especially when larger teams are coordinating on a project. Sometimes its worth erring on the side of “prematurity” when abstracting domain logic if it keeps everyone on the same page. But personally this is why I avoid larger teams