update-if-exists
is good to know about, but it wouldn't quite hit the nail on the head here..
The primary and overriding problem with the original procedure is that it complects per-key logic and map-updating logic and thereby obscures the nature of the translation (e.g., both keys and values change) and the relation of translations to each other (whether later translations depend on earlier translations).
Separate the two concerns, and each one gets easier to improve.
To translate 1 attribute, you could have a function (a multimethod maybe), or a lookup table. For example, suppose you had a function svg->cljfx
that took a [k v]
(e.g., a map entry) and produced a new [k v]
; then translating the whole svg-attributes
could be done by
(->> svg-attributes
(map svg->cljfx)
(into {}))
Easy to read, although not super CPU-efficient if unchanged attributes outnumber changed attributes.
Alternatively, suppose you had a lookup table (map) of svg key to a function (maybe anonymous) that yielded a new [key value]
pair. A loop could iterate the known conversions. It would have to skip missing keys, but at least that case could be covered once-and-for-all instead of once-per-key. The logic would be more involved, but it might run faster.