-
Notifications
You must be signed in to change notification settings - Fork 148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove PhoenixView in favor of documenting how to integrate. #164
Comments
Agree to this. I understand how we want to have a plugin that works out of the box. However, explicitly for This would also allow the project to move independent of framework but only by |
I would love to see a PR to the docs/README overhauling and documenting how to use this lib with Phoenix w/o the phoenix view. Once we have that we can deprecate PhoenixView for removal in a (hopefully) soon to come 1.0 release. |
You also need to explicitly handle render :errors. I am quite happy with the PhoenixView. |
From the perspective of an Elixir beginner, I'm really happy with PhoenixView and anything it can provide to reduce the amount of boilerplate. |
I think removing PhoenixView is a good idea. Recently we want to do I18n for JSON API errors, and we have to build our own Maybe moving Phoenix integration to another lib like I'm also glad to PR a config to use custom Ecto error serializer (maybe even a common behaviour), but if |
I think a ja-serializer-phoenix lib is a good idea. 👍 |
This is in the spirit of explicit over implicit.
Suggested by @nurugger07 in #34.
All view really needs is:
Something would also need to be added to the changeset and error views.
The text was updated successfully, but these errors were encountered: