Fork me on GitHub
#hyperfiddle
<
2024-04-08
>
Geoffrey Gaillard13:04:01

We've been working on a datafy/nav based Electric datagrid. Premise: if one can datafy it, Electric can render it. Features: • efficient virtual scroll (server streamed rows, only in the client-visible scroll window) • datafy/nav rendering as forms and tables, with input filter and column sort - see screenshot • malli schema based rendering • progressive enhancement Demos: • https://electric-datagrid.fly.dev/(datagrid.gitbrowser%2FGitBrowser)https://github.com/hyperfiddle/electric-fiddle/blob/ed6e907111fd12d4d3f7966649c09b545dcfdcd4/src/datagrid/gitbrowser.cljc#L77https://electric-datagrid.fly.dev/(datagrid.file-explorer%2FFileExplorer)https://github.com/hyperfiddle/electric-fiddle/blob/ed6e907111fd12d4d3f7966649c09b545dcfdcd4/src/datagrid/file_explorer.cljc#L73https://electric-datagrid.fly.dev/(datagrid.datomic-browser%2FDatomicBrowser)https://github.com/hyperfiddle/electric-fiddle/blob/ed6e907111fd12d4d3f7966649c09b545dcfdcd4/src/datagrid/datomic_browser.cljc#L291 Request for feedback: We're going to spend a bit more time working on these datagrid apps, what should we build?

🔥 14
👌 3
🙌 4
💯 2
Geoffrey Gaillard13:04:26

Ideas: • Datomic schema explorer • Clojure namespace browser • JDBC explorer • Hackernews comment browser • S3 browser

Dustin Getz13:04:41

We're seeing lag from here in US East that we don't experience in Paris, we're investigating, unclear if fly issue or what

henrik13:04:53

This is what it looks like from Stockholm (using the worst broadband provider in Sweden)

👀 1
henrik13:04:39

Ping @U02DVTY209E, check it out

👀 1
Dustin Getz14:04:29

We currently believe it's the disk IO latency on the fly instance due to clj-git doing file system ops

henrik14:04:51

Cheat and load it into memory

Dustin Getz14:04:51

Additionally, making the window half screen (25 rows not 60) is much faster across all demos

wikipunk14:04:42

This is really cool thanks for sharing

henrik14:04:00

Limiting number of rows made a huge difference. What do you reckon is the bottleneck @U09K620SG? Something DE might improve, or completely orthogonal: network latency, disk perf?

👍 1
Dustin Getz14:04:41

suspect combination of network-attached cloud disk latency on the git demo (which is by far the worst), + overhead of electric v2 doing too many round trips (v3 is better and has the right infrastructure in place now to start working on algorithmically optimal network for which the design work is already done), and also the overhead of datafy/nav doing blocking IO outside of e/offload which we need to look into

👍 2
Ben Sless17:04:45

Ideas - generic database explorer with configurable sinks - not just s3 and jdbc, but redis, aerospike, druid, clickhouse, graphql

👍 2
Ben Sless17:04:59

Another idea - hijack some code analysis tool and make a code base explorer (maybe metazoa or clerk?)

👍 2
henrik17:04:25

In that vein, tap> target?

👍 1
Vincent19:04:04

Super cool!!

nivekuil22:04:38

not the feedback you asked for, but I can't see myself using any of these purely on a UX perspective (keyboard controls, column x row filters etc.) -- maybe you could think about a common interaction system for datagrids

nivekuil22:04:02

put another way, less focus on getting developers excited to make stuff with your system and more about how to get the end users to demand developers make stuff with your system

❤️ 1
nivekuil22:04:41

not sure if anyone currently likes being on the receiving end of low code tools

Geoffrey Gaillard07:04:00

All feedback is welcome, especially the one we don’t expect. You are definitely right. We are prioritizing what we consider the hardest, most difficult or most risky to outsource/offload. I’m sure we’ll prioritize differently soon enough. > not sure if anyone currently likes being on the receiving end of low code tools Food for thoughts 👌

Panel09:04:19

Data table, dropdown, forms ect.. are full of very hard UX / accessibility issue, in the react world a proper data grid implementation has probably more dev working on it than the whole hyper fiddle team.

grounded_sage06:05:37

Can one play with any of this yet? @U2DART3HA I'm currently doing a lot of work with data that I am rendering into tables and feel like I am just recreating a subset of what this is.

Dustin Getz00:05:16

@U05095F2K fair warning - this stuff isn’t mature and may be difficult to use, and there can be performance issues in nontrivial configurations

👍 1
grounded_sage02:05:16

Appreciate the warning.

JAtkins18:06:34

BTW some of your git sha dependencies seem to be breaking. Took a minute to find out that the SHA from that branch of eletric-fiddle depended on a missing ref in electric. Eventually discovered it's using electric -> feature/experiments

Daniel Manila14:04:00

Is there a way to call an e/fn directly? I admit that I don't fully understand how they work. I'm trying to do something like the following, where I only call a handler if it exists:

(e/defn Inner [handler]
  (e/client
    (dom/div (dom/on! "click" #(when handler (handler)))
             (dom/text "Click me"))))

(e/defn Outer []
  (e/client (let [h (e/fn [e] (println "Does this work?"))]
              (Inner. h))))

Will14:04:34

You cant call the electric function inside of a clojure function. If you change the dom/on! to dom/on and use an e/fn instead of #() it should work

Will14:04:37

Other than that, I think it should work? That being said, in your example, h is a pure clojure function, so you could define it without using e/fn and use it directly with dom/on! in Inner

Daniel Manila14:04:02

Hmm, I tried this code and got the error n is undefined

(e/defn Inner [handler]
  (e/client
    (dom/div (dom/on "click" (e/fn [e] (when handler (handler))))
             (dom/text "Click me"))))

(e/defn Outer []
  (e/client (let [h (e/fn [e] (println "Does this work?"))]
              (Inner. h))))

Will14:04:08

e.g. (when handler (dom/on! "click" handler ...

Daniel Manila14:04:50

Can you pass pure clojure functions to electric components, I think that wasn't working for me earlier

Will14:04:45

(e/defn Inner [handler]
  (e/client
    (dom/div 
      (when handler
        (dom/on! "click" handler))
      (dom/text "Click me"))))

(e/defn Outer []
  (e/client (let [h #(println "Does this work?")]
              (Inner. h))))

Daniel Manila14:04:53

Oh wait you can, I guess I was having another issue

Will14:04:55

try something like that, should hopefully work

Daniel Manila14:04:49

Yeah seems to work. Thought I had tried that, but thank you for talking me through!

Will14:04:51

In your last code snippet you passed in an electric function but called it like a clojure function (handler). If you wanted it to be an electric function, you could still make it work like this:

(e/defn Inner [handler]
  (e/client
    (dom/div 
      (when handler
        (dom/on "click" handler))
      (dom/text "Click me"))))

(e/defn Outer []
  (e/client (let [h (e/fn [e] (println "Does this work?"))]
              (Inner. h))))

Will14:04:59

note the change from on! to on

👍 1
Daniel Manila14:04:15

Any tips on how to debug errors like the following:

ERROR hyperfiddle.electric: #error {
 :cause fexpr__49599_49651 is null
:data {:hyperfiddle.electric.debug/trace [....]}
:via ...}
I'm getting it in code that appears to be working, so I'm not sure what's failing

Geoffrey Gaillard14:04:40

Does the error remains after a REPL restart?

Daniel Manila14:04:15

It does unfortunately

Geoffrey Gaillard14:04:46

Is this happening in dev mode or under advanced compilation?

Daniel Manila14:04:18

I cloned the electric-starter app, so I've been using its (dev/-main) to start up the compiler/server

Geoffrey Gaillard14:04:37

I’m thinking about a client / server program mismatch, which usually do not happen. It could be due to: • a cljc namespace failing to compile in clojure but succeeding on cljs. • a macro macroexpanding differently in clj vs cljs. Does it happen immediately after the repl is started? or after saving a change in a file?

Daniel Manila14:04:49

It happens when I'm calling a function (roughly the same pattern as https://clojurians.slack.com/archives/C7Q9GSHFV/p1712586660579119, but something seems to be different since it's not working properly)

Geoffrey Gaillard14:04:06

Can you show me the code?

Daniel Manila14:04:37

Yeah let me try and figure out how to display it, I haven't put it up on github yet

👍 1
Daniel Manila15:04:44

Here is the line that's getting https://github.com/DonyorM/Tree-King/blob/main/src/great_dalmuti/components/hand_wheel.cljc#L40occurs (I think, the error isn't super clear) The stack trace references the https://github.com/DonyorM/Tree-King/blob/main/src/great_dalmuti/components/card.cljc, since it's calling that handler

Geoffrey Gaillard15:04:44

You are calling Card with a clojure.core/fn :on-click, but inside Card you are calling (dom/on "click" on-click) and (dom/on "tap" on-click). dom/on takes an e/fn as argument dom/on! takes a regular fn as argument Try to change (dom/on "click" on-click) with (dom/on! "click on-click) in Card.cljc

Daniel Manila15:04:10

That did it, sorry that I seem to keep making that mistake

Geoffrey Gaillard15:04:18

The error is not clear at all and is not helping, for sure. We will improve it.

👍 1
Daniel Manila15:04:18

Thanks for making this library, it's certainly been fun to learn with

simple_smile 2
Geoffrey Gaillard15:04:20

Turns out today it is not that obvious for the compiler to detect fn vs e/fn and report an error. Hence it’s hard to produce a good error message.

Daniel Manila15:04:05

Yeah that makes sense. I worked on a project to improve clojure error messages a while back and our main conclusion was that it was harder than we'd thought 😛

🙂 1