managing state with mount

[Anatoly]

While this google group is not very active, I had a great conversation here about Component and Clojure state management.

I understand that Juxt is very much invested in Component and moreover likes it. I just wanted to share where I arrived since we first talked about it.

I went ahead and started using Component for several of our projects. I immediately liked the seamless integration with "tools.namespace". I liked the prospect of testing the system by merging / massaging a system map with different sub systems. Liked the fact that there is a strong support for Component, which resulted in Component based Juxt projects, the system project and others.

But as I was going further and deeper building my Components, I still had this unenthusiastic feeling of damaging my codebase :)

So I sat down, did some napkin art, and created mount. Then I refactored one of the smaller projects we have, taking Component out and replacing the state management with mount. Ran it through dev, qa all the way to prod, and it worked! So I did the same with the second project, and the third, and the fourth.. still using tools.namespace, still using the same REPL and the same VI, using the same functions, that now are really that: functions that belong to namespaces, etc..

Here are some differences from Component that I observed. 

While I do understand that you are very much Component convinced, I would really like to get your critic, thoughts, feedback about this approach.

Thank you,

/Anatoly

[Martin Trojer]

Thanks for this Anatoly!

Initial glance at mount look very promising. I will take it for a spin soon.

--
You received this message because you are subscribed to the Google Groups "modularity" group.
To unsubscribe from this group and stop receiving emails from it, send an email to modularity+...@googlegroups.com.
To post to this group, send email to modul...@googlegroups.com.
Visit this group at http://groups.google.com/group/modularity.
To view this discussion on the web, visit https://groups.google.com/d/msgid/modularity/d7fd31e5-4337-45ba-a3f9-621ac4d30f46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Malcolm Sparks]

Hi Anatoly, 

Thanks for this very welcome post to the list, which is intended for open discussion of modular project assembly - it is certainly not a 'component-only' list!

Overall I think mount looks very promising, and I really like the name. (I like the analogy of the Unix filesystem for composing applications)

Personally, I'm not 100% sold on component, but I did think it had significant advantages over Jig (my previous effort at tools.namespace integration) so I moved various projects over to it. I've been broadly content with component since then, but there's always scope for continued innovation. It's weird what the simple passage of time does to a library! 

For me, the value of component is all of the following :-

1. tools.namespace integration

2. start/stop (especially useful for network services that don't behave well without orderly shutdown)

3. the whole system available from the repl - you can create convenience functions that encode system structure to provide powerful repl queries on system state

4. configuration - binding implementation-specific parameters to lexical scope - I've seen many 'leaky' abstractions where implementation configuration is passed via additional function arguments to otherwise more abstract functions - I also value having a single unified approach to this, rather than domain-specific hacks - e.g. hijacking Ring request maps for value conveyance.

I see that mount does 1 and 2, and 3 is 'in the hammock', but not sure what mount's answer to 4 is.

The downsides to component, in my view, is the 'whole app buy-in'. But then again, some things have become very useful because they've demanded (and achieved) de-facto ubiquity (e.g. the maven central repository). 

I also don't like that component doesn't support bi-directionality (or graph cycles, co-dependencies...). Things that offer bidirectionality (e.g. bidi route structures), are quite painful to integrate into component-based apps. 

Also, I love the idea of starting/stopping parts of an application that mount supports - this is definitely something I have needed but haven't figured out how to do with component.

I'd be interested in Martin's fuller review (I know he's got a lot of experience with component-based apps and has some stronger reservations that I), but of course everyone else's feedback on mount would be interesting too.

Regards,

Malcolm

Malcolm Sparks
Director

Email: mal...@juxt.pro
Web: https://juxt.pro

JUXT LTD.
Software Consulting, Delivery, Training

To view this discussion on the web, visit https://groups.google.com/d/msgid/modularity/CA%2BfPBFuwZ03XdwvPi6dVFwOvRoxTZYahsNRsU3iLOzQCGO0pew%40mail.gmail.com.

[Anatoly]

Hi Malcolm,

  Thank you for the feedback. It's great you guys are open to try it out!

   I'd like to understand #4 a little better. Can you give an example? My hunch is it is going to be just another top level ":require"ed state that is available to the whole namespace that requires it. But an example of #4 would definitely clear things up I feel.

Thank you,

/Anatoly

[Adrian Mowat]

Hi Antoly,

Thanks for this.  I've been using component for a while now and I think have the same reservations as most people around full app buy in and everything feeling like an object.  I've been playing around with mount ofr a couple of days.

Things I like...

* I can just start coding and add mount if/when I need it

* Making things into "components" becomes a conscious choice where having a lifecycle adds value

Things I'm struggling with...

* The load/execution order is hard to understand (this could be user error though - see issue https://github.com/tolitius/mount/issues/13) 

* Is there a chance we could end up with weird cyclic dependency issues with mount?

On balance, though I think these are reasonable costs to pay for the lightweight feel of this library.

Cheers

Adrian

[Anatoly]

Hi Adrian,

  Thanks for giving it a spin. I did respond to the question on github, let me whether it helps.

[Anatoly]

hit send too early.. :)

As far as "cyclic dependency issues", usually what I see Compiler catches them before mount needs to do anything special. But again it's new, I might be missing some use cases where it can happen. If you can think of one, do let me know.

Thank you,

/Anatoly