This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-02-09
Channels
- # announcements (4)
- # babashka (25)
- # beginners (11)
- # calva (32)
- # clj-kondo (5)
- # clojure (130)
- # clojure-dev (11)
- # clojure-europe (17)
- # clojure-nl (1)
- # clojure-norway (96)
- # clojure-spec (1)
- # clojure-uk (3)
- # clojurescript (9)
- # conjure (2)
- # cursive (8)
- # datalevin (1)
- # etaoin (14)
- # ghostwheel (2)
- # hyperfiddle (13)
- # joker (2)
- # leiningen (82)
- # malli (3)
- # pathom (4)
- # polylith (12)
- # releases (3)
- # spacemacs (7)
- # sql (3)
Sure: (for-by identity [x y] …)
. You can also read the source:
(defmacro for
{:style/indent 1}
[bindings & body]
`(hyperfiddle.electric/for-by identity ~bindings ~@body))
As you can see it’s just calling for-by
.each item in coll ought be reference-able and therefore for-by makes more sense to me also
The identity
case does have use-cases, such as when iterating through a sequence of IDs, or other things that are expected to be unique and stable (a range
, for example). Still, it’s better to be explicit about it.
Is this (e/def var (init-expr...))
still supposed to work this way?
https://github.com/hyperfiddle/electric/blob/7ef1612c9659d1e88f2f41223f5c7c045a5eb399/src/contrib/electric_goog_history.cljc#L62-L63
I have a history implementation based on electric goog history but navigation isn't working properly anymore. From breakpoints in closure library JS it seems as though new-goog-history might be getting called too often (maybe every time !history is referenced in a new context?)
seems that moving the value part of those two definitions out into nested (binding [...]) expressions (since they refer to each other) makes it work as it used to pre-IC
could be a regression IDK i logged a ticket to take a closer look in the next couple weeks when we re-release the next set of demos in electric-fiddle
at a very quick glance it looks like a known regression in resolving e/def that I don't think we addressed yet