Fork me on GitHub
#ldnclj
<
2016-02-10
>
practicalli-johnny00:02:11

@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

practicalli-johnny00:02:47

@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

agile_geek08:02:24

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

malcolmsparks10:02:58

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

agile_geek10:02:59

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!

agile_geek10:02:07

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

malcolmsparks10:02:24

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)

malcolmsparks10:02:07

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

malcolmsparks10:02:16

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

malcolmsparks10:02:29

(my article is on server sync btw.)

malcolmsparks11:02:07

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

malcolmsparks11:02:30

and yes, that MagicAccessHack works across the whole site 😉

paulspencerwilliams11:02:53

Last paragraph of Day 2.

mccraigmccraig11:02:53

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

malcolmsparks11:02:00

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

paulspencerwilliams11:02:45

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

malcolmsparks11:02:08

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

malcolmsparks11:02:19

getting the tooling fixed is a big win

mccraigmccraig11:02:10

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

malcolmsparks12:02:48

yes, but websockets 😞

malcolmsparks12:02:31

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

malcolmsparks12:02:53

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

malcolmsparks12:02:26

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

malcolmsparks12:02:10

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)

mccraigmccraig12:02:18

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

mccraigmccraig12:02:15

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

glenjamin13:02:44

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

glenjamin13:02:21

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

glenjamin13:02:21

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