Morning folks

Morning everyone...

Good morning.

Morning

afternoonz y'all

@malcolmsparks: i live in the hope that too much programming doesn't cause detached retinae

@mccraigmccraig: don't think there's a causal relationship?!

@mccraigmccraig: I don't think it does!

(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.

I struggled with Om, I haven't had the courage to tackle Om Next yet!

ReFrame. ezpz :P

Yeah, I've turned to looking at reagent and re-frame instead..

On next is exceedingly clever, far too clever for the likes of me

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

makes sense from what I've read from others

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.

Also on the schema check, are you using something Schema for that?

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

neat

(yada also does the reverse on the server-side - the api spec is used to coerce the JSON)

Ah, very handy

How have you found yada? I haven't had time to try that yet

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

Om Next feels very clever indeed...

but it feels like it addresses problems I don't even know they exist.