Morzaram

Morzaram OP

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!

0
Post #11
lccezinha

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
Post #12
Morzaram

Morzaram OP

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
Post #13
axelson

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.OrdersLive
  • ProjectWeb.OrdersLive
  • ProjectWeb.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
Post #14
KP123

KP123

This blog series by Sasǎ Jurić was really insightful and I’ve adopted some of the practices in my projects

3
Post #15
cmo

cmo

I like it flat, irrespective of being in the live and orders_live folders.

1
Post #16
lccezinha

lccezinha

Yes, we usually go with ProjectWeb.OrdersLive, even if that lives in the project_web/live/orders_live directory.

1
Post #17
eahanson

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
Post #18
mindok

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
Post #19
fuelen

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 :slightly_smiling_face:

1
Post #20