Kinda There's some code on Chlorine that does that

But it converts a Java Throwable into a reagent "react component": https://gitlab.com/clj-editors/repl-tooling/-/blob/master/src/repl_tooling/editor_integration/renderer.cljs#L426-462

Only one I’ve seen is this: https://github.com/ptaoussanis/encore/blob/07a6ef576eb23912d4d02f4ac5641a2b351e6dc5/src/taoensso/encore.cljc#L381-L391

IMO stdlib should include some version of this. It really is annoying.

I would wrap it in a let, and put some when inside since it mutates the object anyway

it would be slightly more verbose I admit

@U07S8JGF7 i saw that one with apropos but was hoping there was a clever combination of things from core. @U0CL38MU1 yeah i ended up doing the obvious let when, when, return object just wondering if there was a better idiom. Apparently there isn't and i agree this would be nice to have

Fogus had some clever << macro at one point, and I’m wondering if it would cover this case.

I think it was Fogus. For the life of me I cannot find it.

It was like a cond threader that you could add let into

(cond-> x
  (foo?) (doto inc)
  (bar?) (doto dec))

doesn’t work for setters that return void

damn :) I'm dense lately

No I’ve just done that 1000 times and realized why it doesn’t work.

would double doto work?

(cond-> x
  y (doto (doto z))
  ...)

cond-> does work

(let [a "1"
        b "2"
        c nil]
    (str
     (doto (StringBuffer.)
       (cond-> a (.append ^String a))
       (cond-> b (.append ^String b))
       (cond-> c (.append ^String c)))))

StringBuffer#append returns the StringBuffer

that doesn't matter

but that doesn't matter here

(let [a "1"
        b "2"
        c nil]
    (str
     (doto (StringBuffer.)
       (cond-> a (.append ^String a))
       (cond-> true prn)
       (cond-> b (.append ^String b))
       (cond-> c (.append ^String c)))))

that's a good idiom what i was looked for. thanks lost3d

doto always passes the same thing through to the next expression, regardless of what each expression returns

ah gotcha, yeah I’ve seen the some-> used for nil checking there

missed the top-level doto

yeah no, that’s good. Thanks man!

that'll just check that the object you're using with doto is not null

I don't knw if this is is relevant, but there is let? and also the lib swiss arrows https://github.com/egamble/let-else https://github.com/rplevy/swiss-arrows

seems like interesting stuff in there but i don't think i'd want to take a dependency on that

This one? https://twitter.com/cgrand/status/1281527501387440128

YES. Thank you!

😲 do you have an example of how you would use it? Don’t really understand the one in the tweet

There’s an example in the twitter thread

Yes I got it now

There’s also the classic https://github.com/randomcorp/thread-first-thread-last-backwards-question-mark-as-arrow-cond-arrow-bang :)

Oh wow.

Oh wow! It has <<- ten years before I first saw it!

I’m curious where you think that’d be valueable.

I’ve literally never had a need for such an animal 😄

Well, I find the threading macros frustrating, because collection functions need to use ->> but hashmap functions use ->. The wand thingie is basically as-> but better. And nil shortcutting is pretty cool in an api environment, where inputs can be bad.

Also the side effect arrows are nice. Being able to add (-!> println) and go about your debugging is nice.

(-> something
  (doto (println)))

-!> sounds a lot like doto

I didn't know doto , tbh. I'll look it up.

@U02DEQJ409F the rationale for the two types of arrows is that there are "sequence operations" (what you called collection functions) which take the sequence as the last argument. They are for stream processing basically. And there are collection operations (which the map functions are, along with nth, and a bunch of other similar things), and those take the collection first. Basically if you're trying to transform a stream, you need ->>, but if you're trying to work with an individual piece of data, then you need ->. Also you can combine -> with as-> to make some nice chains even when the first argument isn't what's needed.

the threading macros also work together

(-> {:things (range 10)}
      :things
      (->> (map inc) (reduce +))
      (as-> x (* 2 (/ x 11))))

Wow. Coming here was my best decision today. Thanks for that information. This is literally gonna change my life x)

https://stuartsierra.com/2018/07/06/threading-with-style was a nice read about the subject as well

https://github.com/Reactive-Extensions was one of the delightful things I found in other languages. Threads have the same spirit, and I find them cleaner/more elegant

I've started to use transducers a lot more where I had previously used ->> which seem to overlap with the reactive extensions ideas from other langs

I'd use transducers more if they were more ergonomic.

(sequence (comp (map inc)
                (filter even?))
          (range 10))

(->> (range 10)
     (map inc)
     (filter even?))

(of course you can use into instead of sequence, but that doesn't change much)

well ... sequence is lazy and into isn't ... I think that making lazyness optional at the point of application is a great feature of transducers.

I think that familiarity will only come with more usage.

I was going to ask : I have to map over a sequence and also sort it. Would a transducer to that in one pass ?

well a lazy-seq won't run through the whole dataset in one go, and you need to realise all the data in order to sort it (cos the last element might be the first one 😉 ) ... but

(transduce (map dec) (completing conj sort) [] (range 10 0 -1))

(require '[net.cgrand.xforms :as x])
  (into [] (comp (map dec) (x/sort)) (range 10 0 -1))

Creating a sorted collection will not be particularly efficient whether you use transducers or not. Probably the best way to do it would be to use into with a sorted-set-by as the target and then call seq on the result.

Although cgrand.xforms may be more efficient since it uses java's arraylist sort without sorting the intermediate steps

into a sorted set will remove duplicates which probably isn't what you want. I would have thought that the xforms sort would be most efficient, but test it with your dataset ...

Thanks for the recommendations.

#reitit has a channel, might be best to ask there

To my knowledge the situation for reitit hasn’t changed. I’m asking whether there are other options now? (Rephrased question to be clearer).

@U06HHF230 Maybe https://github.com/juxt/apex

ahh thanks — I was trying to recall the name of that one — sadly doesn’t look finished nor updated recently 😕

just discussed last week about adding OpenAPI3 finally to reitit. There have been many people contributing to that, but not completely done. Just work.

Malli and spec both have -> JSON Schema translation already.

IIRC Rich has expressed a preference for omitting keys, and I think that's reflected in the design of at least clojure.spec

I mean, I dunno what you want me to say.

It is. Doesn’t mean you have to like it 😄

There are lots of idioms I don’t like.

using :or only makes sense when there's a sensible default value which the user always wants when calling that code, and where it's invalid to not have that data. It should not be used to provide default data for when there is missing information.

then it should be better to have empty strings? not nil?

Why? So that you can have two values for nil you have to check?

,, in a CSV means either: I don’t have this data or I have this data and the value is nil. Given the semantics of CSV it’s better to assume the latter and move on.

(I know from experience that using "" leads to problems. For CSVs, I usually trim all whitespace and then translate "" to nil.)

why then you would have keywords with nil values?

To say that you know what value is for that keyword, and the correct value is nil

Which is distinct from not knowing what the value for that keyword is.

this is exactly the purpose of :or in destructuring

(let [{:keys [a b c] :or {c 42}} {:a 1 :b 2 :c nil}]
 c)

oh, I see what you mean, nvm

Definitely… If I’m getting rid of the value under a key, I use (dissoc …) There can be edge cases like in the case of defrecord like pointed out by @noisesmith, but that’s not the typical case.

I would have thought that wouldn't work, because the #omit-nil bit is a reader tag and the function will need to be run at runtime, after it's been read and compiled ... Right?

You are probably right, I have a gap in my knowledge, never looked into reader literals at all

Ah, got it. Perhaps instead of that weird #if-some syntax, do a macro like: (without-nils {:a "A" :b (function-that-will-return-nil))})

You can use Clojure’s metadata feature to identify values/fns to be checked for nil

(without-nils 
 {:a "A" :b ^:no-nil (fn [x] nil)})

Hmm yea, though it would require IMetas

The without-nils macro would transform the code:

{:a "A" :b ^:no-nil (fn [x] nil)}

(let [m (volatile! (transient {:a "A"}))]
  (when-some [b (function-that-will-return-nil)]
    (vswap! assoc! :b b))
  (-> m deref persistent!))

Right

IMO, this feels like too much magic, but I believe it’s possible 🙂

The easier way:

(defn clear-nils
 "Remove the keys from m for which the value is nil"
 [m]
 (apply
  dissoc m
  (for [[k v] m :when (nil? v)] k)))

Have used that function, once in a blue moon… But again, I try to avoid having the nils there in the first place.

One thing that may be annoying is getting it to work recursively

A bit, yes.

But possible.

Perhaps clojure.walk is your friend then.

You can walk randomly shaped/deep maps and data-structures and get rid of whatever you want as you walk them.

Yea I have done that approach too, works pretty well, because then you can take it a bit further and remove e.g., vectors that become empty after the steps above

Again, I prefer not having that problem in the first place, if possible. If I control the data/input, I would very much prefer that option 🙂

Yea, I was just proposing this as a more concise way to control it, because every alternative we've discussed is still more verbose

Right… Same rule applies, imo. Clean up the vector in the first place, if you can, or make the code work without caring whether the vector is empty or nil, etc.

I think where it comes up is if you are building something like a query AST, where some of the parts are dynamic. For example in some test code, I have this:

:venia/queries
               [[:employees
                 (if first-n
                   {:first :$n :after :$cursor :orderBy :$order}
                   {:last :$n :before :$cursor :orderBy :$order})
                 (filterv
                   some?
                   [page-info
                    [:edges
                     [[:node [:dbId :description]]]]])]]

Where is page-info declared/coming from?

It is just getting destructured from a map argument to the function

Got it, and it causes a problem if it’s nil?

Yea, it is not a valid selection node in the syntax

Doesn’t the (filterv some? …) clear it up?

Yea it does, it is just pretty verbose compared to this:

:venia/queries
               [[:employees
                 (if first-n
                   {:first :$n :after :$cursor :orderBy :$order}
                   {:last :$n :before :$cursor :orderBy :$order})
                 [#if-some page-info
                    [:edges
                     [[:node [:dbId :description]]]]]]]

Is it really that verbose though?

But I understand multiple places.

It is an extra level of indentation usually for a very trivial thing

Right… I actually might have it like:

[[:employees
  (if first-n
   {:first :$n :after :$cursor :orderBy :$order}
   {:last :$n :before :$cursor :orderBy :$order})
  (filterv some?
   [page-info
    [:edges
     [[:node [:dbId :description]]]]])]]

In Cursive, it gets indented like this:

[[:employees
  (if first-n
    {:first :$n :after :$cursor :orderBy :$order}
    {:last :$n :before :$cursor :orderBy :$order})
  (filterv some?
           [page-info
            [:edges
             [[:node [:dbId :description]]]]])]]

Since the function arguments 'should' have the same level of indentation

Yes… I use cursive as well… I have modified the indentation configs

Another option is to avoid the execution from the top:

(when (and page-info etc-info)
 ;query
 )

Right ok, I probably should look into doing the same because it is annoying

Yea, I write a lot of React(Native) view code. That’s why I reduced the indentations 🙂

With deeply nested ASTs, combined with conditionals/filter etc, I like less visual nesting

yea it is nice if indentation is reserved for something really important

Otherwise the AST code starts drifting to the right, like a lot.

lol

right

Screen Shot 2021-09-01 at 2.13.08 PM.png

Notice how the 3rd/4th line is indented

That was not the default, I believe. It would indent under the {} and everything drifts.

yea exactly. That seems better

Also, 1 space indent… Definitely non-standard but I like it.

View/AST code is really different from regular Clojure code. It just makes little sense to split it up into short fns, like one would regular Clojure(Script) business logic code.

right