Augmenting a vector context key from a processor

[arichiardi]

Dear fonda folks,

I have a use case where I need to create steps ad-hoc, programmatically, so I am doing:

(-> (map-indexed journey-processor-tap commands)
    (flatten)
    (vec))

where:

(defn journey-processor-tap
  [index command]
  (let [uuid (:uuid command)]
    [{:processor #(post-data! (:endpoint %) command)
      :path [:journeys index]
      :name (str "processor-" uuid)}
     {:processor #(hash-map :response (get-in % [:journeys index])
                            :command command)
      :path [:journeys index]
      :name (str "hack-" uuid)}
     {:tap (fn [{:keys [logger] :as ctx}]
             (logging/info logger (get-in ctx [:journeys index])))
      :name (str "tap-" uuid)}]))

It feels though, I am hacking my way in so that I can save in the context an array or results. I probably should not hijack :path with the index in order to do that.

What would be the best way to handle this?

Should fonda allow more freedom in adding things to the context?

/cc @ElChache

[arichiardi]

I actually get:

"journeys": {
            "0": {

Initializing the context solves:

 (fonda/execute
        {:initial-ctx {:endpoint endpoint
                       :logger logger
                       :journeys []}}
...

[arichiardi]

@ElChache the solution in the other issue is the same I have here...and honestly is not that pretty imho compared to:

(update-in ctx [:request :policies] conj %)

It would be nice to just append to something that is either already a vector (using some magic) or just allow arbitrary operations on top of the context.

I think we talked about this but I will write it here too, it's either you allow operations on the context like in sieppari, where you can just use Clojure functions out of the box, or you write some DSL and implement those operations yourself.

We took the latter I guess with :path, which corresponds to the assoc-in operation.

Clojure provides assoc, update, update-in and merge on maps (I might be missing some).

We should probably decide which ones we want to expose if we want to keep the DSL.

[ElChache]

You are right, we are limited now in the sense that we only map assoc-in to :path
Maybe we could expose the map functions you mentioned in the following way:

{:assoc-in <path> :processor (fn []...)}
{:assoc <keyword> :processor (fn []...)}
{:update-in <path> :processor (fn []...)}
{:update <keyword> :processor (fn []...)}
{:merge <path> :processor (fn []...)}

So we get rid of :path and replace it with one of the above
I am not so sure about merge tho, it could be merged on a path I guess.
But maybe if you are assoc-ing multiple values on the context then it should be split on different steps?

[arichiardi]

Well the problem is that in Clojure-land update would receive the value at <path> in the function. So it does really follow what we are doing here.

We could extend :path to support either [:path :to :key] and :path (only a keyword).

It would this way work as both an assoc and an assoc-in.

Still don't know about merge...for merge makes sense when your processor returns something you want to store as-is.

Say a response returns:

{:body {:this :foo :that :bar}}

You might want to store it in the context as:

{:this :foo
 :that :bar
 :other 1}

So :path would be [:body] maybe?

I have had this use case only once to be honest but putting it out there 😄