Clip

= Clip ifdef::env-github[] :toc:

image:https://img.shields.io/clojars/v/juxt/clip.svg[Clojars Project, link=https://clojars.org/juxt/clip] image:https://cljdoc.org/badge/juxt/clip[cljdoc badge, link=https://cljdoc.org/d/juxt/clip/CURRENT] endif::[]

Clip is an inversion of control API which minimizes impact on your code. It is an alternative to integrant, mount or component.

== Background

=== Project Status

Alpha. The core API is unlikely to change significantly, but there may be some small changes to the system-config format. Design feedback is still welcome, there is still space for the rationale to change/expand. While bugs are avoided, the immaturity of the project makes them more likely. Please provide design feedback and report bugs on the link:https://github.com/juxt/clip/issues/new[issue tracker].

=== Rationale

==== System as data

Systems may fail during startup, which can leave you in a state where a port is in use, but you have no handle to that partially-started system in order to close it.

[source,clojure]

(let [db (get-db)] http (start-http-server db) ;; What happens if make-queue-listener throws an exception? queue-listener (make-queue-listener)] …)

This can lead to re-starting the REPL, which is a major interruption to flow. Clip provides a data model for your system, and will rethrow exceptions with the partially-started components attached in order to allow automatic recovery in the REPL or during tests.

You may choose to make your system very granular. For example, you may choose to provide each web request handler with it's dependencies directly, rather than passing them via the router. In these cases, you will find your system quickly grows large, having your system as data reduces the effort to maintain & understand the relationships between components.

EDN is a natural way to express data in Clojure. A data-driven system should naturally work with EDN without any magic.

==== Boilerplate

Existing dependency injection libraries require boilerplate for defining your components. This either comes in the form of multi-methods which must have their namespaces required for side-effects, or the creation of records in order to implement a protocol. These extension mechanisms are used to extend existing var calls in libraries. Instead of doing that, we can take a reference to a function (e.g. ring.adapter.jetty/run-jetty) and call it directly. This means that effort to wrap an existing library is minimal, you simply have to specify what to call. This also removes the problem of inventing new strategies for tying a keyword back to a namespace as Integrant has to, by directly using the fully qualified symbol which already includes the namespace as required. In addition, normal functions support doc-strings, making for easy documentation. Finally, this use of vars means that your library is not coupled to Clip in any way, yet it's easy to use directly from Clip.

==== Transitions

Side-effects are part of a startup process. The most common example is seeding a database. Before other components can function (such as a health check) the migration must have run. Existing approaches require us to either taint our component's start with additional side-effect code (complecting connection with migration) or to create side-effecting components which others must then depend upon.

Clip by default, provides a :pre and :post phase for start-up, enabling you to run setup before/after starting the component. For example, you may need to call datomic.api/create-database before connecting to it, and you may want to call my.app/seed-db after starting it, but before passing it around.

Clip is also simple, it separates out running many actions on your system. This allows you to define custom phases for components, if you need them.

==== Async

Async is a significant part of systems when doing ClojureScript applications. Something as simple as reading data from disk or fetching the user from a remote endpoint will cause your entire system to be aware of the callback.

Interceptors have shown that async can be a layered-on concern, rather than being intrinsically present in all consumption of the result. Clip provides multiple "executors" for running actions against your system, providing out of the box support for sync (no async), promesa, and manifold. If you need an additional executor, they are fairly simple to write.

==== Obvious

Obvious connections between actions are easier to understand than obscure ones. Use of inheritance for references or relying on implicit dependencies increases the obscurity of your API. Component and Integrant allow you to spread out your references through the use of using and prep-key. Instead Clip encourages you to make references live in the system, making it always obvious how components connect together.

=== Comparison with other libraries

|=== |Name |Need/has wrappers for libs |Extension mechanism |Suspension |System location |Multiple parallel systems? |Transparent async between components?

|Component |Yes |Protocol |Via library |Map |Yes |No |Integrant |Yes |Multi-method |Yes |Map |Yes |No |Clip |No |Code/code as data |Coming |Map |Yes |Yes |Mount |No |Code |No |Namespace |No |No

|===

=== Example Applications

• link:https://github.com/juxt/clip-example[Official clip-example repo]
• link:https://github.com/PrestanceDesign/todo-backend-clojure-reitit/tree/clip[Implementation of the Todo-Backend API spec,using Ring/Reitit, Clip and next-jdbc]
• link:https://github.com/dharrigan/startrek[StarTrek, Clojure REST example project using reitit, next-jdbc and malli]

Want to add one? Open an issue or pull request.

== Usage

=== Defining a system configuration

You define a system configuration with data. A system configuration contains a :components key and an optional :executor key. :components is a map from anything to a map of properties about that component. Note the use of ``` in the example below, this is to prevent execution, you might find it easier to use <<EDN>> to define your system configuration.

[source,clojure]

(def system-config {:components {:db {:pre-start (d/create-database "datomic:mem://newdb") ;; <1> :start (d/connect "datomic:mem://newdb") ;; <2> :post-start seed-conn} ;; <3> :handler {:start (find-seed-resource (clip/ref :db))} ;; <4> :http {:start `(yada/listener (clip/ref :handler)) :stop '((:close this)) ;; <5> :resolve :server} ;; <6> :foo {:start '(clip/ref :http)}}})

<1> :pre-start will be run before :start for your component. Here we use it to run the required create-database in datomic. <2> :start is run and returns the value that other components will refer to. <3> :post-start is run before passing the component to any other components. Here, we use it to seed the connection. Because we provided a symbol, it will be resolved and called like so (seed-conn conn) where conn is the started component. <4> Here we use (clip/ref) to refer to the :db component. This will be provided positionally to the function. <5> :stop has access to the variable this to refer to the started component. <6> You can control how a component is referenced by other components. Here the :server key will be passed to other components referencing it (e.g. :foo).

==== :components reference

Out of the box, there are a handful of keys supported for a component. In the future this may be more extensible (please open an issue if you have a use-case!).

Many of the values of these keys take code as data. This means that if you were to create them programmatically you have to create them using either list or quotes. Supporting code as data means that EDN-based systems can be defined, but also that there's special execution rules.

Code as data means that you don't need to use actual function references, you can use symbols and these will be required & resolved by Clip. Requiring and resolving isn't supported in ClojureScript, see workaround in <<ClojureScript>>.

Code is either executed with an "implicit target" or not. An example of an implicit target is the started instance. If an implicit target is available, you can provide a symbol or function without a list and it will be called with an argument which is the implicit target. If the function to call has multiple arguments, then you can use this to change where the implicit target will be placed.

|=== | Key | Implicit Target | Description

| :pre-start | No | Run before starting the component | :start | No | Run to start the component, this will be what ends up in the system | :post-start | Started instance | Run with the started component, a useful place to perform migrations or seeding | :stop | Started instance (to stop) | Run with the started component, should be used to shut down the component. Optional to add. If not specified and value is AutoCloseable, then .close will be run on it | :resolve | Started instance | Run with the started component used by other components to get the value for this component when using (clip/ref)

|===

Supported values for code as data with implicit target:

|=== | Type | Description

| Symbol | Resolved to function then called with target | Function | Resolved to function then called with target | Keyword | Used to get the key out of the target

|===

Supported values for code as data without implicit target:

|=== | Type | Description | Example(s)

| Symbol | Resolved to function and called with no arguments | 'myapp.core/start-web-server | Function | Called with no arguments | `myapp.core/start-web-serve