Clojurians Log v2

@p-himik The way we do it with our product, we only have views.cljs and control.cljs, where the control is responsible for all events, data, etc. and turning it into an easier representation that can be called out to by the views. While it does sometimes run into the issues that you describe (i.e. if we have extremely simple events / getters and setters), I think it's a bit less cumbersome than the 4 different namespaces described above, and the structure does help break things up, and keep things a bit modular. Just mentioning this because I'm also a bit curious as to how you organize things personally / how you recommend doing this. Do you simply have one ns for each Component / Page in the application? I've primarily used similar patterns that break things up like this (MVC, etc.), and it usually does help keep code cleaner and a bit more modular, but wondering if it's not as much of an issue in a Clojure based stack.

> Do you simply have one ns for each Component / Page in the application? Yes, with some justified ad-hoc exceptions.

Interesting, I'll keep that structure in mind then!

What I’m aiming for is smart re-use. So a clickable button, for example, can be styled, etc but you pass in the event you want sent with the click handler, plus any relevant args grabbed from immediate component context. A table is more complex, but could be similar with a vector of column headers a vector of row maps. Anything special can be an event passed in and sent off with the dispatch call. Then a container could fire off events, subscribe to results, and pass those atoms down into components. Pretty basic stuff, really.

But I want to make sure the namespaced keywords are an asset rather than an annoyance when it’s time to refactor.

I wouldn't put refactoring costs too high on the priority ladder. Otherwise, abominations AbstractSingletonProxyFactoryBean would appear. :) Both kinds of keywords are just keywords. You refactor them like anything else, especially if your development environment treats them as first-class citizens. The only way namespaced keywords can become cumbersome is if you move a keyword like ::x into a different namespace. Maybe your DE supports that just fine, and then there are no problems whatsoever. Maybe mine IDE supports that as well, but on average I move about one keyword every 2-3 months I'd say, so I never bothered to even check.

So with a separate ns for each component and page, where do you get your reuse, particularly of components?

Not sure if this is exactly what you're going for @jmckitrick, but here's a snippet of what it would look like for us:

(ns example.callback-button
  (:require [reagent.core :as r]))

(defn CallbackButton
  []
  (let [num-times-clicked (r/atom 0)]
    (fn [{::keys [callback text]}]
      [:button {:on-click #(do (swap! num-times-clicked inc)
                               (callback))}
       (str text " " @num-times-clicked)])))

(ns example.main-page
  (:require [example.callback-button :as cb]))

(defn Component
  []
  [cb/CallbackButton #::cb{:text     "A button"
                           :callback #(print "A callback")}])
(defn AnotherComponent
  []
  [cb/CallbackButton #::cb{:text     "Another button"
                           :callback #(print "Another callback")}])

With most of the complexity of the component in the respective ns, and other pages / components simply pass the high level info needed

> So with a separate ns for each component and page, where do you get your reuse, particularly of components? Not sure I understand the question. You have e.g. a my-proj.calendar ns, and you use it just as is, as a whole. If you need to share e.g. a single event handler function out of that ns, then you have to think what kind of dependency that is. Is it something that belongs to the calendar but is just used some place else, or is it something just common for different things? If the former, you don't extract that function and just keep using my-proj.calendar. If the latter, you extract it into my-proj.common or whatnot.

I’ll have to do some experimenting and see if I can come up with concrete cases.

Maybe your approach of keeping all events and subs with their components eliminates the issue entirely.

@p-himik So just to be clear, you’ll have a ns with views/components, and all events and subs are in that namespace, unless factored out for common use elsewhere. So that means namespaced keywords are resolved right there, in those namespaces.

Indeed.

If an event is used somewhere else, I just

(require '[my-proj.calendar :as calendar])

(dispatch [::calendar/set-date "2020-10-21"])

And you generally group the view, event, and subscription all in the same namespace and file?

What about cases where, say, an http fx is used in different places? I guess a ‘common’ namespace or is there a better way? @p-himik

Yep. And yes, just a common ns. Sometimes people extract fxs in a separate special fx ns, I tend to do the same for well-focused tiny effects and I create specialized namespaces for effects that serve the same purpose.

IMO it's comparable to just writing functions in Clojure, which is (again, IMO) not that different from writing code in any modern and actively used language. Well, Clojure does have some polymorphism which may create some differences, but re-frame related stuff is not polymorphic so it's more similar to other languages.

I have quite a lot of legacy code that does split functionality into views/subs/events, and I'm gradually refactoring it into single namespaces. Working with them, in my experience, proves to be much easier. And simpler, I think. :)

Ok, that’s the route I’ll try… for some reason I like the idea of separate folders (views, pages, components, etc) because it seems better organized for navigation and reuse, but things are not always as they seem….

I would just replace the URL with something that guarantees the required HTTP code.