Fork me on GitHub
#portland-or
<
2017-02-06
>
hlship17:02:17

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

hlship17:02:44

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

mattly19:02:29

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

mattly19:02:11

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

mattly19:02:37

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

mattly19:02:16

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

mattly19:02:45

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

mattly19:02:04

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

bill20:02:28

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

mattly20:02:16

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

mattly20:02:16

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

bill20:02:55

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?

mattly20:02:49

I'm not comparing it to component necessarily

mattly20:02:59

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

mattly20:02:23

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

bill20:02:38

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/

bill20:02:53

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

mattly20:02:41

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

mattly20:02:54

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

bill20:02:26

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

mattly20:02:49

that link 404s for me

mattly20:02:28

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

mattly20:02:23

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

mattly20:02:40

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