This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # bangalore-clj (1)
- # beginners (145)
- # boot (8)
- # braid-chat (2)
- # capetown (2)
- # cider (27)
- # cljs-dev (232)
- # cljsrn (30)
- # clojure (223)
- # clojure-boston (1)
- # clojure-dusseldorf (2)
- # clojure-greece (1)
- # clojure-italy (21)
- # clojure-russia (16)
- # clojure-sanfrancisco (13)
- # clojure-spec (33)
- # clojure-uk (56)
- # clojurescript (165)
- # core-async (16)
- # core-logic (5)
- # cursive (14)
- # data-science (2)
- # datavis (2)
- # datomic (49)
- # duct (15)
- # editors (5)
- # emacs (6)
- # fulcro (11)
- # graphql (11)
- # hoplon (8)
- # jobs (4)
- # jobs-discuss (82)
- # jobs-rus (7)
- # leiningen (4)
- # luminus (5)
- # off-topic (90)
- # om (7)
- # om-next (1)
- # parinfer (67)
- # pedestal (34)
- # portkey (46)
- # re-frame (12)
- # reagent (4)
- # reitit (3)
- # remote-jobs (1)
- # ring-swagger (8)
- # shadow-cljs (13)
- # spacemacs (18)
- # specter (6)
- # sql (5)
- # tools-deps (4)
- # unrepl (40)
- # yada (26)
https://docs.datomic.com/on-prem/aws.html#other-storages I just realised that they've formatted JSON unlike how most do for CW
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.
Clj refactor users utilize prefix lists. As that's now namespaces are automatically cleaned.
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 clojure.tools 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
@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...
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 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..?
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
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
@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.