@dominicm I dont recall seeing an email about ClojureX, was it from SkillsMatter ?

I created another variation on a logo for London Clojurians https://github.com/jr0cket/london-clojurians-logo/blob/master/london-clojurians-text-highlight-lambda-jr0cket.png All the current designs are on the repo and each design is shown in the readme.

@jr0cket yep, it seemed semi-targetted though

"We know you're employed at a company doing Clojure"

Ah, seems like they are doing some email marketing to drive up registrations for the event. We could do with some more attendees for ClojureX

morning

@dominicm was this the email touting for lightning talks? I knew SkillsMatter were sending that out (and as I bought a ticket via my own company before I was sure I would be in London to help organise it I received that email, which was amusing as it started "Hello Chris, I am one of the organisers of Clojure eXchange..." and I got to say "Me too!")

@jr0cket I like that last one best. You should set up a doodle poll and drop links to it here, on meetup and in the google mail group.

morning

I'm getting some interesting insights in to a largish cljs code base at my current client. My throw away comment is that re-frame subscriptions/registrations seem to obfuscate state change in my mind. Misused they seem to proliferate where state is change to various parts of the code making it harder to reason about as the 'type' of the subscription doesn't live anywhere. Before anyone challenges this, I know they are defined wherever the register-handler is called but without judicious use of either spec or schema the dispatch calls setting the value of the subscription can just trample on the existing type. I can see why @krisajenkins started using defrecord to define "message types" in petrol, although I do find that a little clunky (sorry Kris!)

😊

I’ve found I can’t keep on top of a CLJS codebase without using schema/spec basically everywhere.

Yeah. I can see why and I don't experience that feeling in server-side Clojure. I am not a Computer Scientist but I am guessing it's an interesting side effect of: 1. Running on a platform (JS) that doesn't have strict typing (i.e. dynamic-weak as opposed to dynamic-strong on JVM)? 2. State change being prolific in a UI (interaction with DOM?)?

the only effect JS runtime has on types is history

my current JS codebase is full of statically checked types

there’s an approach in Redux, which is quite similar to re-frame, where a relatively small number of components are designated “container components"

only those few do subscriptions, the rest take props

@agile_geek i've got a big re-frame app, and schema-check the whole app-db after every event (while in development, not production) and schema-check everything off of the network (always) - it helps a lot

@glenjamin thanks. Next time we meet in person you may need to explain this to me as I feel it's a big hole in my knowledge

basically don’t just subscribe all over the shop

subscribe in a few places, then pass data down from there

much like you wouldn’t do loads of SQL queries per server-page

Yeah I think subscribing (and dispatching) from all over the shop is the problem I'm seeing. Definitely want to understand a bi tmore about JS 'typing' though.

oh right, I’m using Flow

which is a compile-time-only type checker with a pretty advanced gradual system

@glenjamin doesn't that require the containers to know a lot about the things which are contained ?

i.e. if something 3 levels down from a container needs a new input then the container and everything in between have to be modified to pass it down ?

yeah, that’s true

also, doesn't it mean that the containers will unnecessarily re-render ?

@mccraigmccraig might suggest the gradual introduction of more spec but I think this is something the senior dev's (who are much smarter than me!) have already got on the roadmap. As usual the issue is 'selling' this kind of refactoring to the management. I usually don't bother... just educate the dev's as to the new approach and slightly inflate estimates so that you have time to introduce the new way in every change.

when you hit those scenarios you decide whether to make a new sub or expand a parent

i.e. they subscribe to things which they don't really depend on, just to pass to a child

the most common approach is to have a “page” component which does most of the heavy-lifting subscription-wise

usually you know what sort of thing you want on a page

if you really want granular control something like om-next or relay+graphql might be a closer fit

I prefer that parents know what child components need. Blah, blah, dependency injection, and pure functions.

@agile_geek fortunately it's very easy to introduce schema/spec checking into re-frame gradually and without big refactorings

dependency injection is a good way of looking at it i reckon

subscribing less is simplifying the dependency graph

https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0#.qkgdtyxd6

I will read that link later, but superficially, I agree about subscribing less....my rule of thumb is I dislike anything that 'feels like magic'! (or favour explicit over implicit - one of my major complaints about Scala codebases over using implicits)

morning...

we think we found a house... so now need to sort all that out as well!

It turns out having 9 cider REPLs open in Emacs (and thus 18 JVMs) makes things a bit slow.

@agile_geek can you check the LJC mailing list again to see if my email of promo codes got through?

@jr0cket I have and it did get through

just minutes ago

cool, thanks...

morning

@gjnoonan aye up. Haven't seen you for a while Gavin-John. 👋

Now then Chris, how’s things @agile_geek

How’s thew Clojure Job going

Alright. I'm enjoying new job. Nice to 1 write some code 2 write some clj/cljs code 3 ship code to prod

awesome 🙂