I work at a company called Zaptic and our internal modules are namespaced in a few different ways. We have some core domain types & decodes (eg. Users, Campaigns, Teams, Reports) under a Data.
namespace so:
Data.User
Data.Campaign
...
We also have two main Elm apps called Business
and Users
so we have:
Business.UnitType.Model
Business.UnitType.View
Business.LocationList.Update
Business.Model
Users.Team.Model
Users.View
...
We also have a series of utility modules under a Zap
namespace. So:
Zap.Upload
Zap.File
Zap.Icons
...
This is a mixture of legacy (I think Data
was perhaps inspired by Haskell’s Data.
namespace though I feel that is probably more for reusable generic data structures) and copying NoRedInk (I think they have a Nri
namespace for some stuff?) and then just have actual apps that feel like they should be top level.
My question is, how do you all approach this? Similar strategy or notably different? I also have a colleague who feels that we should try to remove the top level namespaces but I’m concerned about conflicting with 3rd party packages and honestly I like the visual separation of 1st & 3rd party packages in the import
block. That said, we do a lot of import Data.User as User
and both feel it would be nice to have import Business.UnitType.Model as UnitType.Model
but you can’t have dots in aliases (probably sensible!)
Anyway, this all comes up in conversation a bit between my colleague and I and it would be great to have some other voices and input around different strategies to help us move the conversation forwards