Clojurians Log v2

Static analysis and generative testing interest me greatly.

Good morning.

Morning

morning folks :simple_smile:

Bore da

Anybody has a good technique to dispatch on the current route and select different react components with om next? I’m using multimethods wrapping the factories that wrap the react components and it feels a bit too verbose:

(defui AboutPage
  Object
  (render [this]
    (dom/div "This is the about page")))

(def about-page (om/factory AboutPage))

(defmethod layout/pages :about [_]
  (about-page))

if you don't need open-dispatch, would case/clojure.core.match work?

I was thinking core.match too but to be honest not exactly sure how I would implement it without it being reasonably verbose.

@jarohen: I consider that approach, but that would require having a central place to connect page names to react components instead of it being all together next to the page implementation. Now, routing is central, so, I kind of already have that.

(def routes (silk/routes [[:home [[]]]
                          [:tools [["tools"]]]
                          [:tool [["tool" :slug]]]
                          [:about [["about"]]]
                          [:register [["register"]]]
                          [:log-in [["login"]]]
                          [:reset-password [["reset-password"]]]
                          [:change-password [["change-password"]]]
                          [:fail [["fail"]]]]))

I've just started looking at om next and it does strike me that there's a bit of 'boiler plate'. Mind, I am used to Spring MVC and JSF so I can't complain!

@agile_geek: it feels more verbose than re-frame so far, but then, it does more.

@pupeno: yes, although I usually find that I'm already require-ing all of the defmethods in a central place :simple_smile:

@pupeno: I think that was my take away with Om. I suspect trivial SPA's are easier/quicker in re-frame/Reagent but Om/Om Next is probably more scalable?

Yes, I have a core.cljs that requires everything.

@agile_geek: for me, personally, the jury is out on Om Next, but if it’s a positive outcome, I would say that you are correct that re-frame is easier/quicker than Om Next for small SPAs where small is 1 or less API calls to the server, so, very small.

mm - it's for that reason I usually only use multimethods when someone else (i.e. a downstream library consumer) has to write a defmethod - e.g. same as clojure core's print-method

I wonder if I could have *functions* as the name of the route… muahahaha

morning

Argh… circular dependencies 😞

I think it's interesting that we don't have a fairly clear approach to cljs architecture (the Clojure story is a little more mature). I know Om Next is new but there's still a lot of discussion around Reagent and that's been around a while. It's these decisions and...dare I say it, patterns, that make the learning curve steep for experienced dev's coming from another, more mature, environment.

I think my impression is similar.. Om-next seems very complicated… but then I probably don’t understand the problem it tries to solve really.

@agile_geek: I agree that it’s not there and it should be there but I think many devs believe it shouldn’t.

@thomas: building SPAs.

which is something I have never done.

@pupeno: I want to explore your idea of getting the 'great and the good' in this area together to discuss what we do about this.

:simple_smile:

If we have this much variability and discussion about how to build a SPA what is the story like on cross cutting concerns, like security for example. I love the variation of opinion in the community but I don't think it helps someone who just wants to ship software

@agile_geek: agreed.

One of my vague plans is to find a pattern that I’m happy with, it was re-frame but then I notice some problems that Om Next promises to solve and once I find the pattern, add it to luminus, so doing lein new luminus projectx +spa will get you started.

I like re-frame for its simplicity. But the lack of multiple event handlers (which may be intentional on their behalf, and could probably be solved with a bit of scaffold yourself) is slightly annoying.

Om's cursors are weird.

@pupeno: I'd like to talk about how we get something like that established. Do we stick our heads above the parapet and write a series of blogs on 'patterns'? I'm sure we will get plenty of rotten tomatoes thrown our way!

@xlevus: re-frame’s developer is very approachable and open to improvements. We implemented together a hook function in re-frame to integrate with my own Prerenderer library.

@xlevus: Om Next doesn’t have cursors.

yeah, haven't looked at om-next.

Yeah, I quite like that Om Next has ditched cursors as I struggled with the concept. It seems to be a simpler query/pattern matching approach now?

@agile_geek: I don’t think you can move forward in this direction without writing code. You can explore the ideas with blog posts to invite criticism and improve them, but you can also improve code over time. And I can take the rotten tomatoes 😉

@pupeno: I agree. I would not suggest we talk about it in the abstract. Need, probably several iterations, of code to prove it.

@xlevus: what dyu mean with "the lack of multiple event handlers" in re-frame ?

You can only have one handler bound to one event afaik.

oh, i see - you are thinking pub/sub...

yeah

you would need some way of specifying a priority list for handlers of an event then... i can see why they stuck with a single handler

yeah

You can bind multiple subscribers to a subscription can't you? Would you not have one event from source to app state, and multiple on way back up?

yes

Maybe I'm being naïve, only created a fairly noddy app with it.

That's probably the right way to do it

@agile_geek: just want to ask. are we going to ever something like for ClojureBridge for the male gender? Sometimes its not so easy for some beginners to learn from the dojos..just saying..