I prefer the first approach, without separation by subs/events/views. I find it the most organic and the easiest to reason about and navigate.

@U2FRKM4TW so one file with events, subs and comps. I never tried it but it seems to be a very pragmatic approach that is reasonably flat with relatively few file changes. Sort of work on one feature in one file.

Right. And, of course, depends on what you deem a "feature". There are different levels of granularity possible.

Maybe in the spirit of clojure you begin with the big brush strokes, one large file, then refactor incrementaly when the features reveal themselves @U2FRKM4TW

In ours we have most events/subscriptions in the same file as the component/page. Splitting them up into different files was a pain, especially with how limited the ns forms are in Clojure. It also makes navigating around in the codebase by filename a lot slower, at least if you follow the component_name/{events, subs, views}.cljs type pattern.

@U2FRKM4TW’s style is how vue works: a single file per component that holds the vue-flavored html, the relevant javascript, and the relevant css. it's surprisingly effective

@UEENNMX0T SFC (single file component) style I think it's called. The term they use on their website is collocation of inherently coupled concerns.

Since some of our view namespaces can get larger, we've went with the approach to have a model (containing subscriptions) and an events namespace separated. It is helpful for us to separate the view from the state and events, almost like an MVC for the frontend. I'm surprised to hear about navigation here since navigating within a namespace should, theoretically, be the same as navigating to a different namespace

In my current application we have a 2 main folders, 1 for components that we reuse among many features, and another for features themselves. Within the feature folders there are more folders and files broken up by components within the feature. We started by splitting each feature among three namespaces for events/subs/views, but I believe that was a mistake. We ended up with giant view/sub/event namespaces for a single "feature". Having things broken down by sub-features/components within the main feature with all their events/subs/views contained in a single namespace would have been much better. I do that now with new features when possible.

I am surprised and delighted to hear so many folks voting with their feet for what I have heard called "co-location". 👏

In the past I've generally done 1. as a folder with files for subs.cljs / events.cljs / views.cljs etc but after many years I've also found it is not ideal. In future projects I'll probably try co-locating events/subs/views but having not done so on a large project yet I can't say for sure that it will work out like I think it will....