Given that View modules contain formatting logic, what do you do if you want to format some data in your main application (ie in lib/myapp/ as opposed to in the lib/myapp_web/) ?
We are doing a load of CSV exports, and I keep finding myself aliasing View modules in my library modules which feels dirty.
How do you handle this? Do you have any self-enforced rules about which modules can call others? I’d love to hear about them!
First I’d ask: why do you use Views for CSV output?
You can just use nimble_csv in your controller and directly return the CSV with render text: csv_output or some such (sorry, forgot the actual Phoenix syntax).
Thanks for the reply @dimitarvp
I am using view logic to format the data in the same way as we do in our templates.
Here is a trivial example:
# in controller
def csv_users(conn, params) do
binary = Accounts.buid_users_csv_export()
send_download(conn, binary: binary)
end
# in Accounts.Users.ExportCSV
def buid_users_csv_export() do
Users.list_users()
|> Enum.map(fn user ->
[
UserView.format_name(user),
UserView.format_address(user),
...
]
|> NimbleCSV.build_csv()
end
This is a really basic example of pseudo code but it is exactly the issue that I am facing in many places in my application. In reality, there is too much formatting to just redefine the functions locally to this module.
Any help really appreciated 
What do you mean by that? CSV doesn’t need formatting. 
There are too many of these “formatting” functions: UserView.format_address(user)
So am I understanding correctly: you don’t want to use nimble_csv and you want to keep using Phoenix Views for CSV formatting because the functions that output the proper CSV fields are too many?
Hi @dimitarvp. No you aren’t understanding me correctly.
I am happily using NimbleCSV. Maybe forget that I ever mentioned CSV 
I think this is the crux of my question:
Given that View modules contain formatting logic, what do you do if you want to format some data in your main application (ie in
lib/myapp/as opposed to in thelib/myapp_web/) ?
I feel like it is not good design/practice to reference my UserView module in my Accounts.Users.ExportCSV module and wanted to understand how people would get around this issue.
They just want access for example the full_name(user) function defined in the view to fill the CSV column full_name in the CSV generating code.
@ jmurphyweb you could move your helpers in the data model and import them from your view and your csv code.
Oops, sorry for the derp. 
In all Phoenix projects where I had any influence, I always moved such functions outside the _web namespace. They absolutely don’t belong there in my eyes. They are also not views per se, they are like data reshapers / transformers / whatever-you-want-to-call them.
So yep, move them to the other namespace and don’t have a care in the world. 
I think this would be better reworded as “Given that View modules contain formatting code specifically for rendering one or more web-pages”. Then there would be no confusion. If it isn’t to do with a web page or API output, it doesn’t belong in the _web part of the project.
It is dirty, that’s why it feels dirty! 
They absolutely don’t belong there in my eyes. They are also not views per se, they are like data reshapers / transformers / whatever-you-want-to-call them.
That’s honestly really eye opening for me. I thought this basic formatting was exactly the purpose of View modules in Phoenix!
It sounds like you are saying the View modules are specifically for putting controller/context provided data into a shape that a template will readily consume. Is that pretty much it?
Can I just double check my comprehension:
Create these data formatters somewhere in/round the User module and then alias that module in my view module for access by the templates?
I can see why that is an improvement, but something still seems a little off the me 
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.
© Copyright Elixir Forum | Terms | Privacy & Cookies
