You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, we use clojure.walk/prewalk to walk the document hiccup structures and replace entries such as [:vega-lite {....}] with actual reagent component calls (e.g. [oz.core/vega-lite {...}]). The problem with this is that prewalk does not stop traversing the children of these nodes in the tree, and in particular end up iterating through all of the :data entries in the visualization specs, which is far from ideal. This potentially has an impact on performance for larger chunks of data (though probably not significant, since, we're already parsing and translating to json). More importantly though, while in general it's constructed so that it shouldn't actually edit any of the data, I don't like that I have to even think about it (and it's not impossible that there's some edge case where this could actually pose a problem).
Zippers may be the ideal solution, but are sort of a pain to write. We may be a able to get away with a custom recursion as well.
The text was updated successfully, but these errors were encountered:
metasoarous
changed the title
Use zippers or custom recursion on client for applying components to hiccup docs
Stop using prealk on client for applying components to hiccup docs
Oct 17, 2021
metasoarous
changed the title
Stop using prealk on client for applying components to hiccup docs
Stop using prewalk on client for applying components to hiccup docs
Oct 17, 2021
Right now, we use
clojure.walk/prewalk
to walk the document hiccup structures and replace entries such as[:vega-lite {....}]
with actual reagent component calls (e.g.[oz.core/vega-lite {...}]
). The problem with this is thatprewalk
does not stop traversing the children of these nodes in the tree, and in particular end up iterating through all of the:data
entries in the visualization specs, which is far from ideal. This potentially has an impact on performance for larger chunks of data (though probably not significant, since, we're already parsing and translating to json). More importantly though, while in general it's constructed so that it shouldn't actually edit any of the data, I don't like that I have to even think about it (and it's not impossible that there's some edge case where this could actually pose a problem).Zippers may be the ideal solution, but are sort of a pain to write. We may be a able to get away with a custom recursion as well.
The text was updated successfully, but these errors were encountered: