This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (15)
- # aws (1)
- # beginners (5)
- # boot (328)
- # cider (5)
- # cljsjs (7)
- # cljsrn (12)
- # clojure (100)
- # clojure-art (3)
- # clojure-austin (1)
- # clojure-chicago (1)
- # clojure-russia (19)
- # clojurecup (2)
- # clojured (2)
- # clojurescript (34)
- # cursive (10)
- # datavis (33)
- # datomic (9)
- # devcards (21)
- # editors-rus (1)
- # events (1)
- # hoplon (42)
- # jobs (5)
- # ldnclj (38)
- # mount (39)
- # om (140)
- # re-frame (26)
- # reagent (25)
- # spacemacs (1)
- # specter (3)
- # vim (1)
@malcolmsparks: i live in the hope that too much programming doesn't cause detached retinae
(no, there is no causal relationship - there is a causal relationship from being short-sighted though)
Hmmm, I started writing code at age 13 and became short-sighted at age 15. However first year of coding was on a teletype outputing on paper so maybe it only took a year of staring at a screen!
Slightly off topic, but is anyone else struggling to get to grips with om next? I can't really seem to join the dots.
However, I strongly suspect this is a 'simple, not easy' thing. I.e. in the long run Om (Next) is simpler (less accidental complexity) but not easy? I have no empirical evidence for this however.
So (maybe?) anything beyond a trivial app would be worth the investment in Om (Next)?
Someone with real world experience of Om (Next) and Reagent/Reframe want to chip in?
@agile_geek: i've got lots of re-frame experience now - re-frame is pretty darn simple - it's very easy to grok and to reason about it's behaviour and to inspect what's going on
it doesn't help you out with higher-level 'component' like abstractions and code organisation, which can make growing an app from small to medium a bit awkward as you have to figure out your own conventions
there's no great magic required though, and it's by far the nicest ui dev experience i've ever had
Thanks @mccraigmccraig , will start off with something pretty trivial and see how I get on from there
@jamiei: that's the way to go - the examples around are fine to get started... after a while you will find you want to split your subs and handlers and views into separate namespaces, but you kinda need a feel for your app before you figure out how to do that, so no point worrying about it at the start
@jamiei: do schema-check your app-db on every update (with a middleware) while developing though - it catches loads of slippery bugs
@mccraigmccraig: Good advice on the splitting. Sometimes you need to make mistakes before you understand how to split the app properly anyway.
yeah, i'm using prismatic schema... i've got all my schemas in .cljc files so they get shared between front and back-end
and i'm also using schema-coercion with a JSON API, to check and coerce everything coming off the wire, so i get richer datatypes (i.e. #inst, #uuid etc) for almost zero effort
(yada also does the reverse on the server-side - the api spec is used to coerce the JSON)
generally excellent - a few bugs, but @malcolmsparks is quick to assist, and the concept is well thought-out and overall it's been a much easier ride than i expected (to create a fully async server-side)
i haven't tried the latest release yet, but i imagine that the ride is only going to get smoother from here on in
AIUI Om next is a good solution for the problem of a large app where components have broadly varied data sources