I think this is the thing I’m looking for when it comes to the querying which will be one step closer to maintaining the chaos I’ve sewn. Thanks y’all!
Morzaram
lccezinha
I usually try to organize my code like this
- lib
-- project
---- orders
------ order.ex # schema
---- orders.ex # context
-- project_web
---- components # for shared/general components
------ header.ex
---- live
------ orders_live
-------- orders_live.ex # LV module handle in/out for info where heavy biz logic lives inside the context
-------- orders_live.html.heex
-------- component_related_to_orders_feature.ex
If that helps you.
If my context starts to grow I can extract into a smaller new module to handle queries, but I don’t do this that often.
3
Morzaram
Thanks for responding everyone. The reducer function idea from kokolegorille is exactly what I’m looking for. That will clean up A LOT of my logic.
0
axelson
Scenic Core Team
I’m curious how you name your
lib/project_web/live/orders_live/orders_live.ex module, is it one of:
ProjectWeb.Live.OrdersLiveProjectWeb.OrdersLiveProjectWeb.Live.OrdersLive.OrdersLive(probably not, but this is the “strict” file name to module name version)
I’ve been waffling between them, especially as the module hierarchy gets deeper, e.g for a module like lib/project_web/live/orders_live/order_form_live.ex that “belongs” in the orders_live/ directory.
0
KP123
This blog series by Sasǎ Jurić was really insightful and I’ve adopted some of the practices in my projects
3
cmo
lccezinha
Yes, we usually go with ProjectWeb.OrdersLive, even if that lives in the project_web/live/orders_live directory.
1
eahanson
My preference is Web.Live.Orders and web/live/orders.ex (note: not ProjectWeb, just Web; the prefix always felt superfluous and after a bunch of projects without it, I don’t miss it at all).
2
mindok
Maybe I’m a heretic, but I’ve stopped using “Live” in any module (or folder) naming - most things are live now so it seems superfluous. Any non-live UI modules are controllers and/or views and named explicitly.
In the example above, I’d go:
lib/project_web/orders
index.ex - ProjectWeb.Orders.Index
view.ex - ProjectWeb.Orders.View
edit.ex - ProjectWeb.Orders.Edit
line_item_view_component.ex - ProjectWeb.Orders.LineItemView
line_item_edit_form.ex - ProjectWeb.Orders.LineItemEdit
Any common logic related to the orders front end would get put in a module in that folder too.
Grouping everything around end user functionality makes it easier (IMO) to navigate between use wants, issues and bugs and the codebase.
Shared/generic components (buttons, progress bars, form fields etc) live in a components area at the top of the tree. Generally I put live components in a module to themselves, and function components grouped by general area of functionality.
lib/project_web/components
forms.ex
nav.ex
datagrid.ex
...
As with most things, the biggest project I’m working on has archeology rather than architecture - there’s a few iterations of thinking about where to put things and not everything is in the right spot as yet.
4
fuelen
I wrote a small utility which is based on this approach and helps me to organize my complex queries. You may like it as well 
1