Liking cljdoc? Tell your friends :D

sweet-tooth.endpoint.datomic.connection

No vars found in this namespace.

sweet-tooth.endpoint.datomic.liberator

Helper functions for working with datomic entities.

Transaction results are put in :result in the liberator context.

Helper functions for working with datomic entities.

Transaction results are put in `:result` in the liberator context.
raw docstring

sweet-tooth.endpoint.datomic.tasks

No vars found in this namespace.

sweet-tooth.endpoint.format

Conforms endpoint response bodies to the format that the frontend expects. The Sweet Tooth frontend expects responses in the form of

[[:entity {:ent-type {ent-id {:entity :map}}}]]

The vector [:entity ...] is a segment. A response contains 0 or more segments. This format was chosen to better support composition in responses: If you need to add more information to a response, you can add a new segment without concern for what the response already contains.

However, it would be tedious to have to format the response body of every single endpoint this way, when most the time you just want to return one or more entities. You should be able to just return the entities; this namespace lets you do that.

Basically, returning a map or vector of maps is shorthand for the full entity segment.

Conforms endpoint response bodies to the format that the frontend expects.
The Sweet Tooth frontend expects responses in the form of

`[[:entity {:ent-type {ent-id {:entity :map}}}]]`

The vector `[:entity ...]` is a segment. A response contains 0 or
more segments. This format was chosen to better support composition
in responses: If you need to add more information to a response, you
can add a new segment without concern for what the response already
contains.

However, it would be tedious to have to format the response body of
every single endpoint this way, when most the time you just want to
return one or more entities. You should be able to just return the
entities; this namespace lets you do that.

Basically, returning a map or vector of maps is shorthand for the
full entity segment.
raw docstring

sweet-tooth.endpoint.handler

No vars found in this namespace.

sweet-tooth.endpoint.liberator

Includes:

  • Utility functions for retrieving common values from the context (record, errrors, params)
  • A template of decision defaults appropriate for an SPA
  • Utility functions for auth

Introduces loose convention of putting a record under :record in the context

Extends liberator's representations to handle transit

Includes:

* Utility functions for retrieving common values from the
context (`record`, `errrors`, `params`)
* A template of decision defaults appropriate for an SPA
* Utility functions for auth

Introduces loose convention of putting a record under `:record` in
the context

Extends liberator's representations to handle transit
raw docstring

sweet-tooth.endpoint.module.datomic

No vars found in this namespace.

sweet-tooth.endpoint.module.liberator-reitit-router

Module for creating a ring router (a function that receives a ring requests and dispatches to a handler function based on the request's URL). It ties together the sugar for defining reitit routes and liberator handlers.

The module uses routes produced by sweet-tooth.endpoint.routes.reitit/expand-routes. These routes contain metadata that allow the module to look up vars that define liberator handlers. The module is responsible for associating routes with handlers.

The module is also responsible for adding each handler's configuration to the system's integrant configuration, reducing boilerplate for the developer.

We derive handler keys from ::handler. We then define ig/init-key methods for those keywords, where the method returns a handler function.

This module serves Sweet Tooth's goal of reducing the boilerplate required to get a system running, reducing the potential for errors and allowing the developer to focus on what's unique to their application.

Module for creating a ring router (a function that receives a ring
requests and dispatches to a handler function based on the request's
URL). It ties together the sugar for defining reitit routes and
liberator handlers.

The module uses routes produced by
`sweet-tooth.endpoint.routes.reitit/expand-routes`. These routes
contain metadata that allow the module to look up vars that define
liberator handlers. The module is responsible for associating routes
with handlers.

The module is also responsible for adding each handler's
configuration to the system's integrant configuration, reducing
boilerplate for the developer.

We derive handler keys from `::handler`. We then define
`ig/init-key` methods for those keywords, where the method returns a
handler function.

This module serves Sweet Tooth's goal of reducing the boilerplate
required to get a system running, reducing the potential for errors
and allowing the developer to focus on what's unique to their
application.
raw docstring

sweet-tooth.endpoint.routes.reitit

Sugar for reitit routes. Lets you:

  1. Specify a map of options that apply to a group of routes
  2. Transform names (usually namespace names) into reitit routes that include both: 2a. a collection routes, e.g. /users 2b. a unary route, e.g. /user/{id}

Basic expansion

A sugared route definition might be:

[[:my-app.endpoint.user]]

This would expand to:

[["/user" {:name :users ::ns :my-app.endpoint.user ::type :collection :id-key :id}] ["/user/{id}" {:name :user ::ns :my-app.endpoint.user ::type :member :id-key :id}]]

Common option map

Here's how you'd apply a map of options to many routes:

[{:ctx {:foo :bar}} [:my-app.endpoint.user] [:my-app.endpoint.post]

{} ;; resets "shared" options to an empty ma [:my-app.endpoint.vote]]

This would expand to:

[["/user" {:name :users ::ns :my-app.endpoint.user ::type :collection :ctx {:foo :bar} :id-key :id}] ["/user/{id}" {:name :user ::ns :my-app.endpoint.user ::type :member :ctx {:foo :bar} :id-key :id}] ["/post" {:name :posts ::ns :my-app.endpoint.post ::type :collection :ctx {:foo :bar} :id-key :id}] ["/post/{id}" {:name :post ::ns :my-app.endpoint.post ::type :member :ctx {:foo :bar} :id-key :id}]

;; vote routes do not include the :ctx key ["/vote" {:name :votes ::ns :my-app.endpoint.vote ::type :collection :id-key :id}] ["/vote/{id}" {:name :vote ::ns :my-app.endpoint.vote ::type :member :id-key :id}]]

Sugar for reitit routes. Lets you:

1. Specify a map of options that apply to a group of routes
2. Transform names (usually namespace names) into reitit
routes that include both:
   2a. a collection routes, e.g. `/users`
   2b. a unary route, e.g. `/user/{id}`


## Basic expansion

A sugared route definition might be:

[[:my-app.endpoint.user]]

This would expand to:

[["/user" {:name   :users
             ::ns    :my-app.endpoint.user
             ::type  :collection
             :id-key :id}]
 ["/user/{id}" {:name   :user
                  ::ns    :my-app.endpoint.user
                  ::type  :member
                  :id-key :id}]]

## Common option map

Here's how you'd apply a map of options to many routes:

[{:ctx {:foo :bar}}
 [:my-app.endpoint.user]
 [:my-app.endpoint.post]

 {} ;; resets "shared" options to an empty ma
 [:my-app.endpoint.vote]]

This would expand to:

[["/user" {:name   :users
             ::ns    :my-app.endpoint.user
             ::type  :collection
             :ctx    {:foo :bar}
             :id-key :id}]
 ["/user/{id}" {:name   :user
                  ::ns    :my-app.endpoint.user
                  ::type  :member
                  :ctx    {:foo :bar}
                  :id-key :id}]
 ["/post" {:name   :posts
             ::ns    :my-app.endpoint.post
             ::type  :collection
             :ctx    {:foo :bar}
             :id-key :id}]
 ["/post/{id}" {:name   :post
                  ::ns    :my-app.endpoint.post
                  ::type  :member
                  :ctx    {:foo :bar}
                  :id-key :id}]

 ;; vote routes do not include the :ctx key
 ["/vote" {:name   :votes
             ::ns    :my-app.endpoint.vote
             ::type  :collection
             :id-key :id}]
 ["/vote/{id}" {:name   :vote
                  ::ns    :my-app.endpoint.vote
                  ::type  :member
                  :id-key :id}]]
raw docstring

sweet-tooth.endpoint.system

Introduces some conveniences for dealing with duct systems:

  • A multimethod config for naming integrant configs, like :dev, :test, etc.
  • An ig/init-key alternative that allows a component's configuration to specify an alternative component implementation, possibly bypassing the ig/init-key implementation entirely
  • replacement and shrubbery-mock alternatives
Introduces some conveniences for dealing with duct systems:

* A multimethod `config` for naming integrant configs, like `:dev`,
`:test`, etc.
* An `ig/init-key` alternative that allows a component's *configuration*
  to specify an alternative component implementation, possibly bypassing
  the `ig/init-key` implementation entirely
* `replacement` and `shrubbery-mock` alternatives
raw docstring

sweet-tooth.endpoint.task

A way to run integrant components as a task. Maybe not a great idea? Used for things like creating a db or running migrations.

A way to run integrant components as a task. Maybe not a great idea?
Used for things like creating a db or running migrations.
raw docstring

sweet-tooth.endpoint.test.harness

Includes:

  • Macros and a fixture for dealing with a system for the duration of a test
  • Helpers for composing and dispatching requests
  • read-body multimethod for parsing response bodies of different types (transit, json etc)
  • assertions that work with response segments
Includes:

* Macros and a fixture for dealing with a system for the duration of a test
* Helpers for composing and dispatching requests
* `read-body` multimethod for parsing response bodies of different types (transit, json etc)
* assertions that work with response segments
raw docstring

cljdoc is a website building & hosting documentation for Clojure/Script libraries

× close