Fork me on GitHub
borkdude12:11:28 execute Clojure(Script) directly from browser script tags via SCI! v0.4.11 (2022-11-23) • Add plugin. This gives access to the library. • Fix for Honoring SCITTLE_NREPL_WEBSOCKET_PORT in scittle.nrepl • Add all public vars of cljs-ajax ajax.core • Upgrade several built-in libraries Check for a playground where you can try out the new re-frame plugin. Channel: #C034FQN490E

clojure-spin 9
sci 6
borkdude 6

This is the first release of — similar to select-keys but selects in a nested collection.

👍 9
🎉 3
Noah Bogart15:11:45

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”.

👍 1
Noah Bogart15:11:56

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 ,,,)})
if there is no way to specify a negative-selection, then you're back to using some kind of cond-> to build the selector dynamically (since you need to dissoc keys, instead of just passing in e.g. nil , false or [] as the value)

☝️ 1

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}
so it would select all the fields except :foo


@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

☝️ 1

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.


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")]
^ it seems like a simple thing, but this is really useful vs the alternative of filtering out the nils, etc. and joining the string explicitly


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

(select-tree ring-request
   {:headers ["content-type"]}
   {:params [:pageNumber
If you wanted to select all headers, you would:
(select-tree ring-request
   {:params [:pageNumber