Clojurians Log v2

I got it working. Not sure if it’s the best way. Turns out that datascript does have a datafy implementation, it just doesn’t get required by default. Requiring it partially solves the problem. Next I have the portal middleware, which means all my evals get wrapped in a map. That doesn’t work with the portal datafy example submit code. Manually tapping or datafying switching the code for something like (update value :result datafy/datafy) makes that work. Now everything kind of works, but it isn’t enjoyable to use. That’s because in the default datascript implementation every nav returns an object that still needs to be datafied. Changing the implementation of datascripts datafy to call datafy on all the result of nav feels dirty but makes it much easier to use in practice.

Interesting 🤔 btw you can do something like:

(cond-> value
  (:portal.nrepl/eval (meta value))
  (update :result datafy/datafy))

In term of datafy-ing nav'd values, I'm not sure what is a good default behavior. For those who want objects, calling datafy would be an issues, for those who want data, not calling datafy would be an issue.

Ah that nrepl code looks a lot less accident prone, thanks 🙂 For me, I can't return them as is from nav, since they'd be infinite again. So the only way to be save is for nav to also datafy. nav+datafy command in portal would also do the trick I guess, but it would be a bit annoying while we can't set hotkeys for custom coomands

Maybe it's time to add that feature 😂

Should have let clojurists together sponsor it 😛

I'm thinking of an api like:

(defn command-name
  "Docs"
  {:portal.shortcut/default #{:control :enter}
   :portal.shortcut/osx     #{:meta :enter}}
  [& args]
  ...)

There would also be a programmatic shortcut api, not 100% sure what that would look like yet 🤔

Might be nice to start by passing it into the open fn

The static one seems completely reasonable as a start. And passing it in will also solve most of the use cases 👍 I'm always pro simple MVP anyways 🙂

Well it sounds like you are volunteering to put up a PR 😏

Somewhat related question: when I doubleclick a value, it currently runs nav on that, right? You probably don't plan on making those kinds of behaviors easily customizable? So if I wanted nav + datafy on double click I'd have to fork the viewer?

(fork = take your code and create a custom viewer from it 🙂 )

I think the handler is currently inlined, but I don't see a reason why it couldn't be lifted out and dispatched into

Then all events (mouse + keyboard) can be handled in a centralized place which would make it easy to make user customizable.

Although I'm not certain why I'm even thinking about having an extra command + replacing the handler. Running datafy inside nav feels ugly but it's working perfectly, so there's no actual practical reason to complicate everything 😉

Having it customizable might be nice for other situations though 🤷

I'll see how hard it is to accomplish 👌

Nice. Your presentation inspired me to get back into doing more of this type of thing, so it's nice to see you also get back into it 😛

One thing that would be interesting, but might also be too much work:

{
 :a [{:datafy :object}]
 }

I do think it's up to nav implementations to include that metadata on children values, kinda like I did here https://github.com/djblue/portal/blob/master/src/examples/hacker_news.cljc#L84-L91

Especially because that type of implementation is more likely to be better supported across different tools.

I guess you're right I should look into adding the nav data immediately and not only when you go into the seq. On the other hand I still like my nav on expanding the inspector idea. Having to leave the parent to be able to see the deeper value isn't as nice as seeing the whole thing for a while.

Yeah, although I'm not sure about coupling it to expand. I feel like Portal should have a fn/transform viewer. Where you can run any fn on any value and the result get's inlined. Kinda like how all the parsing viewers work.

Huh, that sounds even nicer, more general and more composable 👏

We'd have to have some way of saying which values should have which version of that viewer, but at least for datafy that's not that difficult. Harder for other cases. Might be a good place to look at the kindly integration we talked about a long time ago 🙂

Not there yet, but getting closer https://github.com/djblue/portal/commit/6532943ab53b6dcd23473f90b4bef92e18d8a144

Looks good. Do you intend to expose mouse keys as well?

Eventually, not there yet.

I still want to play with how keyboard shortcuts are specified. My hope is that mouse events can be specified in a similar way 👌