Both @dcr8898 and @swilgosz raise important points IMO. Say it boils down to “slices for UI, another layout in lib/ or elsewhare for the rest” versus “slices for whatever part you’d like to wrap”. I may be oversimplifying things, but at least these two ideas could be merged:
On the filesystem, slices/ is just a directory which contains the, well, slices. This name and implementation is generic and a perfect fit for “a slice is any extracted part of the app” which may contain UI, business logic, a mix of both etc. The problem: How to tell the responsability of a slice just from looking at ls slices/?
- You could prefix the individual slices like
slices/ui_admin/orslices/op_invoicing, but that’s pretty ugly. - You could introduce another hierarchy between
slices/and the slice likeslices/ui/admin/orslices/operation/invoicing/. This is a lot of overhead when adding slices to an existing, simple, sliceless app. Also, the middle ground without this additional hierarchy is no longer an option.
But how about making the slices directories configurable?
Currently, there’s either no or exactly one directory slices/, in pseudo code: slices_directories = ["slices"]. Maybe it’s possible to make this more flexible by allowing to customize the slices directories for your app, in pseudo code: slices_directories = ["ui", "operation"] or slices_directories = ["ui_slices", "operation_slices"] – however you like.
(Updated: “operation” instead of “business_logic”)