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:
- render templates
- act as a presentation layer
- define helper functions, available in templates, to decorate data for presentation
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.