Hello folks, I need your help. For the future version of Orchard/CIDER, I plan to either remove or simplify the Inspector's support for datafy/`nav` . Time has shown that these facilities have not been widely picked up by the community. Few libraries are implementing the corresponding protocols for their custom types. For the base Clojure types that support datafication out of the box, the Inspector does a reasonable job of having specialized rendering/navigation capabilities on its own, without resorting to datafy.
Having said that, I'm interested to hear if anybody would miss having the --- Datafy section in the inspector, and if so, what types of objects do you inspect that makes this section useful.
➕ – crave datafy support in the inspector.
➖ – won't miss it.
I realize I need to look into the Cider inspector much more, with or without datafy support. I really want to use datafy more, but I have missed knowledge of a good viewer. So catch 22 for me.
Out of curiosity, what is the upside of not having it?
The implementation is too idiosyncratic for my liking (the last few iterations on it being mine). It mostly assumes how the datafy functionlity might be used, but knowing the exact usecases would allow to simplify/improve them. Or cut altogether if nobody uses it, less code to maintain.
I don't use it on cider inspector but when I implemented it for FlowStorm was for things like jdbc.next or datascript that allows you to retrieve one thing and then using datafy/nav traverse the graph without extra queries
Just out of curiosity... I had been vaguely under the impression that the use case for Datafy and Nav was "inspectors" so this catches me by surprise. ?
CIDER Inspector, in particular, achieves a lot of what datafy offers without using it. For example, you can freely navigate through arbitrary object fields without "beanifying" it. So, what's left is the intricate APIs like jdbc.next that implement lazy data pulling through datafy, and I wonder if anybody uses CIDER Inspector to utilize that.