I'd appreciate ideas to simplify https://gist.github.com/mbertheau/ebdf995dc3c635e1f55e . Thanks!

@mbertheau At a syntactic level, i'd start by * move contains-in? update-in-maybe and the two inline fns at bottom into their own defns, with docstrings. they're pretty simple functions, but inline fns dramatically increase the analytical surface area * encapsulate the update-in-maybe steps and the initial js->clj step into their own defns as well, with docstrings * rewrite init as a simple pipeline over those fns, e.g. (-> js-product-form-data convert-to-clj update-formats) Semantically, this fn is traversing a nested-maps data structure using paths and applying formatting changes at various places in the structure. If the consumer of this isn't just a user-facing view and additional semantic transformations are performed on the structure, it may be worth looking at a library called Specter, from Nate Marz, of Storm, Cascalog and Lambda Architecture fame: https://github.com/nathanmarz/specter Hope that helps.

@jonahbenton: Thanks a lot! Specter certainly looks interesting.

@mbertheau contains-in? might not be strictly necessary

update-in is sufficient, you can move the nil check into there i believe

@mbertheau @ghadi yeah, though update-in will return a structure with new maps in intermediate levels in the path if they didn't exist before, and then each transformation may want to be wrapped in an fnil