Fork me on GitHub

@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: 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