Hi all! I'm trying to get better at Specter. I'm doing a lot of parsing HAR files for metadata. I'm able to do what I want, but it feels...inefficient. like this:

(select [ALL #(or 
                   (re-find #"css" (get-in % [:response :content :mimeType]))
                   (and (re-find #"html" (get-in % [:response :content :mimeType]))
                        (re-find #"tff|woff" (get-in % [:request :url]))
                        )
                   (re-find #"font" (get-in % [:response :content :mimeType]))
                   (and (re-find #"javascript" (get-in % [:response :content :mimeType]))
                        (re-find #"js" (get-in % [:request :url]))
                        )
                   (and (re-find #"image" (get-in % [:response :content :mimeType]))
                        (re-find #"jpg|png|gif|bmp|ico" (get-in % [:request :url]))
                        )

                   )
         [:request :url]] f)

Is there a cleaner way to do this?

(I'm trying to extract URLs that match certain mimeTypes)

@bradford I think this is cleaner and it should be much more efficient as well:

(defn ^:direct-nav my-matcher [exp1 exp2]
  (collected? [part1 part2]
    (and (or (not exp1)
             (re-find exp1 part1))
         (or (not exp2)
             (re-find exp2 part2)))
    ))

(select [ALL 
         (selected?
          (collect-one :response :content :mimeType)
          (collect-one :request :url)
          (multi-path
            (my-matcher #"css" nil)
            (my-matcher #"font" nil)
            (my-matcher #"html" #"tff|woff")
            (my-matcher #"javascript" #"js")
            (my-matcher #"image" #"jpg|png|gif|bmp|ico")
            ))
         :request
         :url]
        f)

^:direct-nav?

minor optimization, not necessary

Hmm.

explained in https://github.com/nathanmarz/specter/wiki/Specter's-inline-caching-implementation

Is it idiomatic to use collect-one in that way if you're trying to, uh, introduce a variable that will be used by a downstream navigator?

Let me see if I can rephrase that question to make it clearer… :thinking_face:

I wand to use cond-path, but each of the cond-path tests begins with the same (view …).

What is the right way to reuse the (view …) results?

yea collect-one + collected? should do what you need

you can use DISPENSE to drop collected values later in path (so they don't reach your transform-fn, for instance)

Interesting. Let me give this a shot.

you can also use defrichnav to do more custom manipulation of collected values

look at definition of DISPENSE for an example

ok

@nathanmarz oh... very cool. very.

Hmm.

Should I be thinking of the collected values as … a stack?

Like, what happens if some upstream navigator before me also collected a few things?

@zane they're a vector

new collected values are conj'd to the end

I'm sure there's room for all sorts of new navigators to help with those sorts of issues

I see, okay.

something like (with-fresh-collected (cond-path ...))

Yeah.

That's what I'm itching for.

But this'll work.

should be easy to do using richnav and defdynamicnav

I haven't yet wrapped my mind around those, I think.

Baby steps.

I opened an issue for it since it's actually a pretty good idea https://github.com/nathanmarz/specter/issues/175

There's no DISPENSE-ONE?

no

I have a feeling the use cases for that would be better served by with-fresh-collected

not sure, this part of the design space is fairly unexplored

would need to see more use cases

defrichnav isn't documented yet?

The only way it differs is that it takes vals, which is the collected vals?

yea, that and next-fn expects to be passed in the new vals + the next value to navigate to

Got it.

Cool!

defnav is a thin wrapper around defrichnav

Is defnav mainly there for backwards compat at this point?

I'm not going to need late-bound-nav here?

Rather than richnav?

@zane oh yea, you'll need late-bound-richnav

Maybe I should re-read the caching implementation doc.