This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-05-29
Channels
- # architecture (2)
- # bangalore-clj (2)
- # beginners (177)
- # boot (1)
- # cider (36)
- # clara (15)
- # cljs-dev (30)
- # cljs-experience (6)
- # cljsrn (7)
- # clojure (94)
- # clojure-argentina (2)
- # clojure-brasil (1)
- # clojure-dusseldorf (6)
- # clojure-greece (1)
- # clojure-italy (18)
- # clojure-norway (4)
- # clojure-quebec (1)
- # clojure-russia (28)
- # clojure-sg (3)
- # clojure-spec (12)
- # clojure-turkiye (1)
- # clojure-uk (12)
- # clojurescript (169)
- # code-reviews (4)
- # community-development (2)
- # core-async (6)
- # core-matrix (6)
- # cursive (35)
- # datomic (18)
- # devcards (4)
- # euroclojure (1)
- # hoplon (2)
- # keechma (4)
- # klipse (2)
- # leiningen (1)
- # luminus (16)
- # mount (1)
- # off-topic (34)
- # om (31)
- # pedestal (6)
- # re-frame (14)
- # reagent (33)
- # specter (4)
- # uncomplicate (8)
- # unrepl (15)
- # untangled (24)
- # yada (25)
hey. Just getting started with Om/Om.next. Couple quick(?) questions. First, I've read some Clojure guides and I have a (very) basic grasp of Clojure syntax now. Is there anything I should really know before diving into Om/Om,next language syntax/features wise? Second, I looked at some Om(next) docs yesterday and a lot of them had "under heavy development warnings". I guess they're still the docs I should be reading? Third, "Note: this tutorial is for Om, not Om Next" - I assume learning Om carries over to Om next and the "basic tutorial" at https://github.com/omcljs/om/wiki/Basic-Tutorial is still somewhat valid?
pasi: some useful information here too https://www.martinklepsch.org/posts/om-next-reading-list.html
@pasi There isn't much carry over from om to om.next, you should start with the om next quick start.
@pasi If you are new to Clojure, I recommend you to start with some thing like Rum, Reagent and Reframe first if you want to build something. Otherwise, if you are learning, just go with Om.next directly.
I use React, Redux & co based stack at work quite extensively so I'm particularly interested in Om Next. Broadening my horizons etc.
@nxqd Why do you recommend those first?
@danielstockton It's based on my experience, I find it's easier for Clojurescript newbie to try out with those framework first since they are easier to work with, and you can build a prototype easily. It's not the same for Om.next. If they are experienced, then they are free to choose 🙂
@pasi I’m also switching from react, redux. Om-next has quite the learning curve unfortunately. I found rum & reframe a lot easier. There is also untangled (om-next framework).
I found tony kay’s videos really helpful most of the stuff applies to om-next https://www.youtube.com/playlist?list=PLVi9lDx-4C_T_gsmBQ_2gztvk6h_Usw6R
Fair enough, it seems to be a common viewpoint. I've looked at re-frame/reagent very briefly but didn't really grasp it any easier than om.
imho the docs and examples are better. For om next I think that the documentation and examples don’t really explain the overview that well. Spent a lot of time re-reading and trying to get my head around them.
Would have really loved to see something like https://github.com/kriasoft/react-starter-kit for om-next. There is a live version here https://demo.reactstarter.com/
I think I was sold on the philosophy of om.next (dnolen talks etc...) before I actually knew anything about it. It seemed like how we should be building UIs. With reagent/re-frame (and incidentally boot vs lein), I see lots of blog posts, documentation, people telling me to use them, but never really heard a convincing argument other than that (to motivate me to dive deeper).
I was similarly sold on Clojure at the beginning, on abstract ideas rather than 'well everyone else is using X'
I think if I had gone by number of blog posts and documentation, I would still be writing ruby.
It’s just hard to get a working template. 🙂 Personally can’t turn back because the end result is just so much cleaner 🙂
I actually made some mental notes about the sort of things I'd like to see in Om next documentation
it's kinda hard to objectively identify pain points when you're not super comfortable with the syntax itself. I think React docs are a great example of well-written, informative docs but I've never read them not knowing JS quite well.
in the spirit of trying to actually give some useful feedback.. some of the docs are bit heavy on jargon and occasionally I felt like some extra info would be great. I'm talking about https://github.com/omcljs/om/wiki/Quick-Start-(om.next) specifically here: >"The reconciler accepts novelty". Novelty? What? A quick explanation of what novelty means here would help a lot. The routing section is okay content wise but a lot of "web app people" probably associate "routing" with views, rather than client-server side information transfer. Parsing & query expressions chapter could maybe provide a little more context and quickly gets quite technical. I guess explaining what "parsing" means in the context of client-server architecture would help. Also little more time could maybe be spent on explaining query expressions.
@pasi also, for getting started I found the Overview of Om Next
and om tutorial
most helpful. First link from community resources https://github.com/omcljs/om/wiki
@pasi I think routing is used in the usual context in the docs i.e. switching views.
I should add that so far I really like the ideology of Om next and at the very least, I hope I can take some of its thinking back to JS world.
@danielstockton Don't get me wrong, om.next is really good. I have worked with 3 frameworks. Just to make sure if he/she is a newcomer, they can start with those 3 frameworks then go further exploring om.next. It would be more encouraging.
om next itself is powerful and flexible, but also somewhat bare-bones. untangled makes some opinionated choices to make the "getting started" process easier, and, as a bonus, there's a sweet dev guide that you clone that comes with a bunch of live-reloading examples
anyone know if is https://github.com/arohner/om-html the "current way" to use hiccup like sintax with om.next? or is there a better alternative? I had to patch this one to work with latest clojure spec.alpha
Is it safe to directly invoke the :action
of a mutation function from another to "chain" mutations? Is this the best/recommended way to chain mutations?
(defmethod mutate 'bar [_ _ _] {:action (fn [] …)})
(defmethod mutate 'foo [_ _ _] (((mutate 'bar '_ '_ '_) :action)))
@fz can’t you (om/transact! this [(foo) (bar)])
?