Fork me on GitHub
dominicm07:03:57 I just realised that they've formatted JSON unlike how most do for CW


do you mean the “lisp-style” positions of the closing parentheses?


Yep. No trailing parens


moin moin morning


I love parinfer, never got the hang of paredit


Mornings. Random core function of the day is require, but the docstring is quite lengthy, so I’ll leave those that want to to (doc require) for themselves.


‘prefix lists’ seem very rarely used


Clj refactor users utilize prefix lists. As that's now namespaces are automatically cleaned.



does seem to make the world feel like a better place 🙂


Mornin' All!


2 coffees in and the needle has barely moved... I need to get better at sleeping when I am in London... 😞


So, I am about to start a new project. This is going to be a Production-Ready app based on the learning from the prototypes I've been building... I am leaning towards ReFrame for the ClojureScript portion, as the app is going to be big to start with and will need to grow, and based on my experiences so far with Reagent and on @mccraigmccraig's recommendation(s) it seems like a good plan... Also, I am now happy / comfortable with Yada, Bidi and Component, but want to start branching out on my own rather than building from Juxt/Edge, and this raises an interesting question; Do I press on with Component or do I side-step to Integrant?


Also, do I adopt the approach, and if so do I do it in conjunction with Boot or Leiningen or do I go "no ropes" and use it alone on its own merit(s)?


These are all questions that I need to make decisions on before lunch, and I have no team to mull it all with, so any thoughts, mullings from "you lot" greatfully received. 🙂


Component is the de-facto standard so i would stick with that. as for tools.deps vs Boot/Lein... Boot has boot-tools-deps from @seancorfield so you can use them both


i don’t like the proliferation of unnecessary protocol impls that component requires, so i would go with integrant or my very own deferst... deferst supports async factory fns (and thus all those js libs which return promises), but you’ll probably get more consistent support from james


edge is moving to integrant


edge is also moving to deps.edn 😛


@sundarj - I didn't know about @seancorfield’s boot-tools-deps, thanks for that... As for Component being the defacto standard, I don't know about that... I am familiar with it and it is powerful, but Mount and Integrant are gaining a lot of ground...


i'm going to defer to you on this. i know very little about these 🙂


mount is an entirely different animal. Integrant is component, but with less protocols.


@dominicm - I was fairly sure you'd said that about Integrant and I am starting to feel as though Integrant is more of what I want with less of the hoop-jumping.


Yep. I think it makes a lot of sense to stop teaching protocols on beginner training courses tbh. Multi-methods are far more idiomatic and they're how you should initially design your programs.


I don't relish re-writing any of my Component code, but I fear that I will have to in the future in order to handle accretion over time and Integrant feels like a better bet over time as well...


I must say duct looks really cool.


Really excited about what James is doing with it.


@dominicm - Do you think Duct "does enough" without even using Integrant..?


I think duct is built on Integrant, not certain though.


It is basically integrant with config as edn files


I played with it a little while ago. The nice thing is you can build quite sophisticated component like systems with very little code/edn


I love me some Bidi and Yada for the web side of things, don't really want to give them up... I got the impression Duct was a Yada competitor rather than an Arachne / Pedestal competitor... Have I misapprehended the lay of the land..?


It's not a competitor to Yada. Rather a competitor to Mount/Component


I'm a big fan of bidi and yada so i ended up writing my own integrant components for them when i was trying to learn duct.


That's very interesting in that case... I am actually using a Duct component in one of my Edge-derived Component apps (at @dominicm’s suggestion) and it was a very pleasant / satisfying experience


Was that quite easy to do @tmulvaney?


I guess you can think of duct as a mixture of Aero and Component. It's got the config is as static data thing and the system config stuff all in one package


I thought duct was a "server-side framework"


does it do the cool multi-environment config stuff that Aero does..?


@maleghast it was quite easy to do and a good dive into Duct.


@dominicm it is server side.


@maleghast it does have its own take on multi-environment config. It is very different though.


The simplicity / elegance of Aero is not something that I would be keen to give up...


Feels odd that it cares about how you store your data, instead of just taking a data structure.


yeah so it has this concept of middleware which are essentially functions which take the config and expand it adding in extra things, usually integrant keys (aka components).


So I guess the config has to be in a shape compatible with the middleware functions.


mmhm, doesn't actually care about edn or anything at all. Seems like aero could give you that initial map.


Yeah you probably could store the duct config it as a key under an aero file