clojuredesign-podcast

Discussions around the Functional Design in Clojure podcast - https://clojuredesign.club/
Stefan 2019-11-14T08:19:56.028500Z

I enjoyed that episode, thanks! The concept of lenses itself is kind of new to me, so it is great having a look at it through your Clojure-lens. Iā€™m intrigued about the reuse vs implement yourself decision by the way. Iā€™m getting the impression (not just from you) that the Clojure community is a bit less keen on taking dependencies in than e.g. the JavaScript community. Not sure if this is because of Clojure, FP, or JavaScript šŸ™‚

nate 2019-11-14T16:54:18.029100Z

Hahaha, I think it's likely all three to some degree.

nate 2019-11-14T16:54:44.029300Z

I've learned that different communities have different values

nate 2019-11-14T16:56:54.029500Z

the Clojure community values simplicity, and that leads many to look at something that has a lot of general functionality (and usually more complexity because of it) and decide to write something small that just does what they need

1šŸ‘
nate 2019-11-14T17:20:12.037900Z

@joshlemer I think the answer depends on what the purpose of your data is. You could flatten it into 4 rows, like this:

[{:user/id 1 :user/name "josh" :friend/id 2}
 {:user/id 1 :user/name "josh" :friend/id 3}
 {:user/id 1 :user/name "josh" :comment/id 1 :comment/text "hi there"}
 {:user/id 1 :user/name "josh" :comment/id 2 :comment/text "hi there again"}]
This would allow for quick queries and transforms to be written using only core functions. We don't usually have heterogeneous maps like these in the same list, but it's OK if there's enough in there to differentiate each subset. Figuring out a primary key is an interesting angle. For instance, what is the primary key of the last map above? :user/id or :comment/id? They are both part of the unique identification of the record. We could make a composite key, but having both individual keys is helpful because it helps us reference other data. We tend to not get confused because each key/value pair is more information about the entity, in this case one user's comment. We can add more key/value pairs related to that entity and the map only gets richer. Also, while the above format is good for querying and aggregation, it's not a very friendly data structure to send to someone outside your program. We tend to have things flatter for internal data (or data that only our own clients, like a UI, are going to use) and something with one or two levels of nesting for outside consumers.