Let me get back to you in a day or two.
josevalim
Creator of Elixir
slashdotdash
josevalim
Creator of Elixir
We have removed the warning on the v1.4 branch. On the upcoming v1.4.1, private functions will be once again overridable without warnings.
On master we have cleaned up the implementation and we also allow private macros to be overridable (something that was never supported).
3
smueller
Reviving this one because I’m really excited about @arjan’s decorator lib, and yet @josevalim @OvermindDL1 and @benwilson512 all expressing discontent over this pattern.
We want to use decorators to perform validation on controller actions and channel functions; we are using elixir/phoenix strictly as a realtime data api that has a mixed surface of both REST and websockets (no forms, js, templates, assets, etc). We need to validate passed-in params for data integrity, example: an AuthController has register action that passes in name, username, password. We need to make sure all are non-null strings, username is unique, and password is 8 chars or more.
As recommended in What’s New in Ecto 2.0, a good way to validate incoming data is with Ecto.Schema with embedded_schema. We’re using @vic’s excellent vic/params to reduce boilerplate, but there is still the matter of invoking the changeset, checking if it is valid, then returning error responses that are properly structured per our requirements. Why make this call in every action? Isn’t it cleaner to have a decorator:
defparams register_params %{ name!: :string, username!: :string, password!: :string }
@validate register_params
def register(conn, payload) do
...
Our first inclination was do something like plug :validate which is invoked before every action, but it’s harder (and less explicit) to associate the right schema+changeset with corresponding action.
Like others, the consensus of negativity from the core team tends to preclude others from using this pattern, even though otherwise it seems like a great fit. So I ask, what exactly are you recommending for something like our scenario, if not decorators?
1
NobbZ
arjan
I actually agree with @NobbZ here, in my opinion the use of function decorators should be limited to things that are not critical to the function that is being decorated.
The reason why I wrote the function decorator lib is for the AppSignal Elixir integration, to easily annotate a function that should be measured. So in my opinion decorators should be used mostly for logging, instrumentation and debugging, and not for performing “business-critical” things like branching etc.
2
smueller
@NobbZ @arjan this is really confusing to me, for a couple of reasons. The first is that many other languages & frameworks handle validation with decorators (Scala with PlayFramework, C# with asp.net mvc, and even node with express to name a few). Why would elixir be so different that a technique like this would be advised against so strongly?
Secondly, the essence of Phoenix middleware with Plug architecture is doing nearly the same thing, it’s just a bit more cumbersome. Are you also recommending against the Plug approach too?
I know it’s really easy to just say “Create a function … and use it”, but saying something like that is not really welcoming to new members of the community that are trying to figure out best practices, especially coming from other popular languages.
0
smueller
I just read this article by on medium about elixir validation with ecto and plug: https://medium.com/@feymartynov/validating-controller-params-with-ecto-and-plug-in-phoenix-5fe2cf77a224
The tl;dr of the approach is to use plug to tie an ecto changeset to a single action using the filtering syntax:
plug MyApp.Params.Pagination, :pagination when action in [:index]
Then later on there’s some macro magic to perform the validation logic, detect issues, and set the appropriate api response.
This is very very similar to what we are doing with @decorators, with ours reading a bit more explicitly:
defparams register_params %{ name!: :string, username!: :string, avatar: [field: :string, default: ""]}
@decorate validate(®ister_params/1)
def register(conn, params) do
...
The argument in the article is the same that I have:
Params validation and error response logic is abstracted out from controller actions so they don’t have redundant code and are more readable.
My questions still remain – why is the @decorator pattern not recommended for validation? And does the same go for plug ... when action in [...] to achieve similar functionality?
0
