Clojurians Log v2

@progzilla: I run a monthly Clojure workshop at http://hackthetower.co.uk. There is one this Saturday. Its more informal that the ClojureBridge event, anyone is welcome

@agile_geek: I created a home page for the ClojureBridge London event http://clojurebridgelondon.github.io/. It includes a draft schedule, which should be agreed on during the teacher training session Wednesday night. Thanks

Morning.

@jr0cket: cheers John. I'm still chasing sponsors

morning.

morning

my Om Next article is coming out at lunchtime, I have a few opinions - many people are going to find it a frustrating learning curve

(I did)

I love working on client sites when the client is completely an*l about security...not only do I have to jump thru hoops of flame to even get onto the public wifi onsite it drops out so badly I end up using my phone hotspot most of the time!

@malcolmsparks: I've just started on that 'journey' myself so looking forward to seeing what you think/found.

currently my biggest bug-bear is composing query expressions - I get that each component contributes its own piece, just can't see how the whole thing fits together in a hierarchy of components - a pretty basic thing I can't grok - there's not much documentation yet (hence my blog article)

but the big thing Om Next has (in my view, this is a killer feature) is efficient server sync of state. I think that it will make certain types of app a lot easier than re-frame

(once you get up the Om Next slope itself of course)

(my article is on server sync btw.)

actually, here it is: https://blog.juxt.pro/posts/course-notes-2.html?accessid=MagicAccessHack

if anyone has any suggested edits before 12.30 today I'd much appreciated them!

and yes, that MagicAccessHack works across the whole site 😉

@malcolmsparks: /hvae/have/s

Last paragraph of Day 2.

@malcolmsparks: is there any reason such efficient sync couldn't be re-cast as a lib to get along with re-frame ?

I guess not

With re-frame you have more control over the state. Each event that causes a state transition in the app-state could be routed to a remote server to cause the same update to happen there

@malcolmsparks: great post. I like the Jeeves analogy, and the post has removed some of my trepidation in trying Om Next; I’m currently increasing my expose to Re-frame as my initial attempt with Om failed due to learning curve of CLJS + Om + Lein configuration needed etc.

thanks @paulspencerwilliams , typo fixed

we have a project update coming out soon that provides a full cljs+sscomp dev env powered by a single build.boot

getting the tooling fixed is a big win

agreed

ha, so really om/next ditches REST... thinking in terms of my current app, send could as easily be implemented over the websocket my app always has open

yes, but websockets 😞

the point is to reduce all the various parts of your app all calling REST-based services

but I think this calls for additional aggregation services on the back-end, so more REST rather than less 😉

to clarify, these Om Next Remotes (or state aggregation services for re-frame) all next to be quick and responsive, and chances are they'll have to make lots of calls out to other services (micro-services or not) - so HTTP conditional requests and cacheing and things like that are going to become more relevant

and clojure has a sweet-spot for cacheing, because of hash and immutable data structures in general - really good to produce e-tags for (the same argument why Om is faster than React, but at the backend)

ah, maybe i'm misunderstanding - i thought the om/next remotes were far coarser than a typical REST endpoint would be, encompassing whole graphs of objects, and therefore likely less cacheable...

but then i guess if the remote is an aggregation of further REST services, then e-tags etc would be important for those services

my understanding is to decouple your components from your backend via query fragments, so you’re free to fulfil them via REST or whatever

i’ve worked on React apps with a working set small enough to just keep it in the browser and continually sync via websocket

Om next is similar in flow to https://github.com/Day8/re-frame#subscribe - but with that declarative query layer, and an interpreter for it