This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (4)
- # beginners (71)
- # boot (258)
- # braid-chat (7)
- # business (3)
- # cider (5)
- # cljs-dev (5)
- # cljsrn (64)
- # clojure (154)
- # clojure-canada (1)
- # clojure-poland (112)
- # clojure-russia (290)
- # clojurebridge (1)
- # clojurescript (60)
- # community-development (1)
- # core-async (25)
- # cursive (9)
- # data-science (1)
- # datomic (40)
- # editors (14)
- # events (2)
- # hoplon (2)
- # jobs (3)
- # ldnclj (51)
- # lein-figwheel (2)
- # luminus (1)
- # off-topic (5)
- # om (57)
- # onyx (29)
- # overtone (1)
- # parinfer (52)
- # portland-or (1)
- # proton (17)
- # quil (2)
- # re-frame (77)
- # reagent (1)
- # ring-swagger (20)
- # spacemacs (1)
- # test-check (4)
- # testing (13)
- # yada (1)
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))
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!
@pupeno: yes, although I usually find that I'm already
require-ing all of the
defmethods in a central place
@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?
@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
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.
@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.
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
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.
@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.
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 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
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?