I wish I could share the reasons for the delays; it would be amusing if it wasn’t happening to us!

There’s another GraphQL implementation out there, it’s just not nearly as sophisticated as ours. You could start prototyping.

@bill I use mount

it's easier to use in development but my complaints are similar to josh's above

it's basically a way of creating singletons with state, and managing the dependencies between them

Once I hit about ten defstate singletons in my app it started getting way too hard juggling those for testing

overall I still like mount more than component, so I'm not planning to switch anytime soon, but I've been moving towards a pattern like

this has made testing about 100x easier, and things still work as expected in dev/prod

it's nicer in dev, as I can spin up a second server on another port or with a different config as needed

@mattly how is Component not "basically a way of creating singletons with state, and managing the dependencies between them”? In this respect I feel like Component and Mount are equivalent. One key difference I see is syntactic. w/ Component, every single fn that wants to access the ugly state has to take it as a parameter whereas with Mount the reference to the ugly state is made by require so functions may close over those references. I realize how ugly that sounds. The resulting namespaces look a lot more like ugly namespaces written using dynamic vars to set default state which gets redefined in test and prod using with-redefs. OTOH with Mount, (unlike with-redefs) the state is not thread-local.

@bill, no I mean mount is basically a way of creating singletons with state

not singleton/state in a thread sense but in a "there is a fixed reference point to it in the global namespace" sense

sure

and wouldn’t I try to use Component the same way, i.e., try to have the minimum number of Components I could possibly have?

sure

I'm not comparing it to component necessarily

mostly offering some perspective on using mount in a fairly involved project

...don't get me wrong, I think either mount or component is vastly superior overall to using neither

So I was all excited about Component as the 500 LoC Clojure answer to my colleagues’ 80K LoC Guice (for Java). Then I got excited about Mount because Component seemed like it’d lead to essentially lots of Components and OO-ish badness in actual practice, and I thought Mount was better. Now I am more and more inclined toward dependency rejection a la: http://blog.ploeh.dk/2017/01/27/from-dependency-injection-to-dependency-rejection/

^ that article takes you in about 30-minutes to indirect output and indirect input via monads without using That Word. sigh

heh

I'd be curious to see what that would look like in clojure

my haskell isn't as good as I'd like it to be

I too, am curious @mattly! I’m starting with Who In Their Right Mind Would Use Monads in Clojure?: http://blog.muhuk.com/2015/10/01/who_in_their_right_mind_would_use_monads_in_clojure.html

hah

that link 404s for me

One thing I'm trying to do, per the example above, is move towards having each thing handle it's own configuration & validation based on what's passed in, and then having only the mount pieces explicitly use the other mount pieces

so defstate server's :start pulls from both environment variables and another mount state, but the start-server function knows nothing about those and handles the validation

whereas before I was doing all of that in the config namespace