That's pretty cool. I'm a little surprised that nil means "select all" instead of "select none". Any particular reason for nil instead of true or something else?

That’s good feedback, thanks. My thinking was something like “nil means make no selection; do nothing; just keep what’s there”.

Ah yeah, that makes sense. I've been dabbling in Lua recently so I've been in the mindset of "a nil value removes the key" lol

I don’t think true really captures that either.

I was also expecting that nil would mean "remove" or so

I've used true as the "everything" value for things like this too

select-tree works like an “allow list”, so you never have to explicitly remove keys. I could add true for this case if it’s less confusing, maybe

yes, I understand: but principle of least surprise you know

I've written a function like this so people could filter out stuff from HTTP responses, kind of like a graphql after the fact ;)

Yeah. one of our use cases is to “redact” http data to make it leak less data when logging and also to make it easy to compare “live” responses to expected / recorded data.

Consider a more dynamic case:

(select-tree data {:foo (when ,,,)})

in my use case people could provide such a structure as one of the optional request body fields, to just get less data over the wire

The notation I had for that, if I remember correctly (the code I wrote I no longer have):

{:library-name/default true
 :foo false}

@U05476190 I’ve thought about something like that a bit, but I haven’t really found an actual use-case yet. Do you have an example in mind?

The use case is to not have to explicitly spell out the things you want to have but just specify what you don't want to have

if you have a large set of fields but one field contains a giant blob you're not interested in, it's handy to be able to say: leave this one out

I’m not sure if I really do want to support that, but I will think about it.

well, it's a 10 line function so it's easy enough to write your own ;)

I just think that if the syntax was true for "select all", and nil/`false` for "select none" -> then it doesn't really hurt the spirit of the library, but supports all the potential cases mentioned in this thread.

exactly

Except that having {:key false} is the same as not providing the key at all. Unless you’re working on sequential collections….

Ah right I see what you mean @U05476190

@U09N5N31T as to the use-cases, I can think of two examples: 1. many times I need to forbid certain keys more often than explicitly allow (in the spirit of Clojure open maps) 2. just tangentially related, but there is a certain nice developer experience I found in frontend libraries when they assume something like:

:classes ["some" "strings" (when visible? "optional")]

Cool! Have you considered EQL syntax? The example on the page would be:

(select-tree ring-request
  [:request-method
   :uri
   {:headers ["content-type"]}
   {:params [:pageNumber
             :pageSize]}])

(select-tree ring-request
  [:request-method
   :uri
   :headers
   {:params [:pageNumber
             :pageSize]}])