From the docs (https://hexdocs.pm/phoenix/views.html)
“Phoenix views have two main jobs. First and foremost, they render templates (this includes layouts). The core function involved in rendering, render/3 , is defined in Phoenix itself in the Phoenix.View module. Views also provide functions which take raw data and make it easier for templates to consume. If you are familiar with decorators or the facade pattern, this is similar.”
Picking the right CSS class for given application state, conditionally showing username or “not logged in”, fiddling around with consistent CSS classes for inputs/buttons etc is something that I would put in a view module.
Also one-off stuff, like expanding a list in your assigns into a comma-separated list for display.
I see it as the final step to tidy things up so template code is more readable.
On the Phoenix docs overview page, the list is a little more terse than the description above:
Things like formatting phone numbers, addresses, currency etc are probably more business related. They can end up in email notifications, data exports, reports etc. They would most likely live in the app data modules (as per @lud suggestion) or in other modules depending on their complexity.
Ultimately here’s no hard and fast rules. One of the nice things about functional programming is it makes it relatively easy to move things around as your application grows or you discover module dependencies that no longer make sense. You put something into a function and a formatted thing comes out with no unpredictable side effects, so you can move that function elsewhere with relative ease.
That is really useful. Thanks a lot for the reply.
I’ll have a look at my View modules this week to see if/how I can implement what you are pointing out here.
Thanks again!
@mindok Already gave you an excellent explanation. I’ll just echo it by saying that stuff that people put in their Phoenix Views sometimes don’t serve their main goal of rendering HTML / JSON / other web stuff.
I think it’s quite OK to have modules like MyApp.Data.CSV.Formatter or MyApp.Data.Salesforce.Importer.
So the answer to your question is YES. Everything Phoenix must be thin – controllers, modules, views. Most of your business logic, data movement, validation, import/export, persistence, doesn’t belong in your Phoenix files.
As for stuff that clearly belongs in your web pages, there Views are in their exact territory of usage.