This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-05-19
Channels
- # announcements (5)
- # beginners (7)
- # boot (1)
- # calva (1)
- # cider (7)
- # circleci (2)
- # clara (5)
- # clj-kondo (1)
- # clojure (19)
- # clojure-chicago (1)
- # clojure-dev (3)
- # clojure-europe (1)
- # clojure-spec (1)
- # clojure-sweden (5)
- # clojure-uk (25)
- # clojurescript (4)
- # cursive (2)
- # data-science (1)
- # datomic (44)
- # graphql (9)
- # hoplon (2)
- # klipse (2)
- # luminus (1)
- # nrepl (1)
- # off-topic (38)
- # planck (1)
- # precept (1)
- # quil (1)
- # re-frame (3)
- # reagent (5)
- # shadow-cljs (12)
- # spacemacs (13)
- # sql (2)
- # xtdb (10)
I quite enjoyed the broadcast. I hadn't prepared anything, yet felt comfortable using a loop/recur, recursive function, repeat/map-indexed, and iterate/take approaches to solve the challenge.
I think this is the first time I've used map-indexed
, it's neat.
I find map-indexed
very useful when you need to generate dynamic react elements and you can use the index value of the lazy sequence for the key
attribute of each react element
I don't find myself doing this very often. I'm undecided whether it's a good idea, or if it is just cheating the react system. I think it depends on how your data will change.
Yea of course there might be other ways to setting keys . How do you do it ? Why do you think the map-indexed might not be a good idea ?
Using map indexed can be bad because if you delete an item, it will cause a cascading rerender, but most of the DOM nodes can be reused
> We donโt recommend using indexes for keys if the order of items may change. This can negatively impact performance and may cause issues with component state.
Luckily I've only used it in generating lists where members are not deleted or re-ordered but sooner or later I would have come across one and used this same technique which might potentially be dangerous ! Phew ! Thanks again ๐
I'm not sure why I'm always pessimistic about obvious solutions ๐ but it leads me to stuff like this.
phew, finished my serverless-cljs workshop materials
the funny thing about writing a workshop is you figure it's done when it's done, but if you have to run it more than once it usually needs mostly rewriting
Does make me conclude that haskell is maybe a better fit
Well, or at least
That node is garbage because of callbacks
So the conclusion is to use promises
But promises are like rubbish monads as you can't deref them anyway (like you can with async forms on the JVM)
So you end up always setting up an io situation to test the damn things anyway (at least lambdas aren't big, I suppose)
But you do think my gosh there has to be a better way is a better way
Hahaha