Fork me on GitHub

@tengstrand congrats on the crux radar mention

🎉 4
polylith 2

Thanks! Yes, that was really cool! 🙂


Yeah, I think that and the Clojurists Together funding announcement have shone quite a light on Polylith lately -- seems like a lot of new folks have joined the channel recently and have been asking about .interface 🙂


might be worth pinning a thread about .interface?


Yes, there are exciting times!


@U0509NKGK Given how quickly the history "goes away" here, I think it might be better to have an FAQ on Polylith's site and refer people to that (pinning just a link to it would survive the loss of history perhaps?).


@U0509NKGK Does anything here answer your concerns? And if not, what Q would you ask, that you'd like to see answered there?


sorry, i used the wrong term. you can bookmark stuff in slack now (see below) your point about contributing to the faq is a good one. i'll seek to provide questions and answers (for review)!


Looks useful!


Added FAQ as a bookmark.


Yep, thats how I came across it and from @seancorfield blog.


Q about common test deps. We have a particular dependency that is used by "most" of our component tests (and base tests). Since it isn't used by "all" brick tests, it feels like it should be in the :test alias of each brick's deps.edn file. But that feels like a lot of duplication just to keep the :test alias honest in each brick -- I'm tempted to just put this test-only dep into the main :test alias in the workspace deps.edn file and into each of the projects's deps.edn files that depend on bricks that would use it in their tests (which is basically all 16 projects currently). Thoughts?


Yes, go for it. It feels like a pragmatic solution and I don’t see any downsides with it.


I also place those test deps (and some very common deps) into project deps.edn files. Although for non-test dependencies, I have an idea of wrapping them in a component and depending on the component itself.


@U2BDZ9JG3 We have a commonly-used test fixture that will probably become such a component at some point.


I think it makes sense. It also gives changeability to a given library; as long as the components interface stays same, it’s safe to replace the library it wraps.


@seancorfield Are you still using stuarts component framework? I have been using it for years and I see you example app in polylith is using it. Just curious what your thoughts on it are ?


Yes, we're still big fans of Component at work, over everything else.


We like that it is simple -- just two lifecycle points start and stop -- and it can work via metadata so you don't need records (we have components that are actually functions once they are started).


Nice, I assume the example app you have is probably the best source on how to use them in the context of polylith


Probably the best public source right now, yes.


I may write a blog post once we have some more Components migrated into components.


An example from work:

(defn system
  "Build a 'system' component that contains the cached hostname
  and this process's full version string."
  (with-meta {}
     #(assoc %
             :hostname (or (:hostname %)
             :version  @process-version)
     #(assoc % :hostname nil :version nil)}))


All of the Component definitions are in implementations with only a helper (constructor) function exposed in the interfaces (we usually call it system).




#(dissoc % :hostname :version) #canthelpmeself


didn’t know about the metadata trick that’s good to know, I’ve found this doc exemple too


@U0509NKGK Hah! That's because this used to be a record and we've gotten into the habit of never dissoc'ing "base" fields because they turn records into hash maps and you "lose" the attached protocol. Obvs that doesn't happen with hash maps and we could just dissoc them here!

👍 2