travisf
Piping module attributes
I picked this pattern up from another dev and have made fairly extensive use of it with Multis:
@multi Multi.new()
...
@multi
|> Multi.put(:params, params)
|> Multi.run(:somefunc, &some_func/2
This ensures that pipechains start with a raw value and, I think, it looks a little cleaner. Does anybdy else do this? Are there any articles on this pattern? It’s fairly simple but there is some nuance due to the constraints of module attributes (I’ve only done it with Ecto.Multi.new/2 and raw values), I wonder if you would run into problems during compile time if you tried it with modules in your project. Of course you couldn’t do it with a function in the same module.
Most Liked
andyleclair
How does it ensure the pipe chain starts with a raw value?
IMO I would not do this. We have some legacy tests that use module attrs and they are a bit of a PITA to deal with and refactor.
If you want your pipe chains to start with a raw value, maybe use credo?
andyleclair
I have seen this attitude before in people who are just learning elixir, fussing over micro things that map to things they know from other languages.
My advice is: don’t worry about it! Write the most straightforward, obvious code you can, and go back to make it faster later if you need to. Always heed the words of Saint Joe:
“Make it work, then make it beautiful, then if you really, really have to, make it fast. 90 percent of the time, if you make it beautiful, it will already be fast. So really, just make it beautiful!”
sodapopcan
Not to pile on but I’m really not a fan of things like this. This is really no different than a single-line private function that I have to jump to to be sure of what it is. It’s also creating a compile-time dependency on Ecto.Multi which isn’t a huge deal in this case but not ideal. I agree with @andyleclair that credo is the best tool for the particular outcome you’re looking for.
acangiano
I tend to use module attributes as storage for compile-time constants, which is particularly handy for “caching” expensive operations with no runtime dependencies. I don’t think that what you’re doing is particularly bad but it feels unnecessary.
sodapopcan
I like the suggestions for when I accidentally do stuff like:
|> Enum.flatten()
|> Enum.map(& &1.foo)
And credo is like, “You dummy, just use flat_map!” It’s especially nice when you upgrade Elixir and it shows you all the places you can improve with stuff in the new version.
…though I suppose this “artificial intelligence” everyone keeps talking about can also do that.
I do like the linting a lot, I just disable a bunch of checks.
Popular in Discussions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Producing high quality Elixir screencasts since 2017.
Categories:
Sub Categories:
Forums
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.
Real-time error tracking, performance insights, and observability for devs.
Practical resources that improve the lives of professional developers.
Develop your skills with books, videos, and courses.
Enabling companies to succeed by building software people love.
Courses that'll move you from confusion to "Aha, now I get it!"