Preview UI feedback

[wendigo]

• Broken live plan when plan is complex (gets rendered out of box)
• Slow rendering of query json when it's large

[wendigo]

cc @koszti

[koszti]

wrt broken live plan. can you please share an sql that’s using tpch data so we can reproduce the issue?

[wendigo]

TPCDS Q01 is enough:

WITH
  customer_total_return AS (
   SELECT
     "sr_customer_sk" "ctr_customer_sk"
   , "sr_store_sk" "ctr_store_sk"
   , "sum"("sr_return_amt") "ctr_total_return"
   FROM
     tpcds.sf10.store_returns
   , tpcds.sf10.date_dim
   WHERE ("sr_returned_date_sk" = "d_date_sk")
      AND ("d_year" = 2000)
   GROUP BY "sr_customer_sk", "sr_store_sk"
)
SELECT "c_customer_id"
FROM
  customer_total_return ctr1
, tpcds.sf10.store
, tpcds.sf10.customer
WHERE ("ctr1"."ctr_total_return" > (
      SELECT ("avg"("ctr_total_return") * DECIMAL '1.2')
      FROM
        customer_total_return ctr2
      WHERE ("ctr1"."ctr_store_sk" = "ctr2"."ctr_store_sk")
   ))
   AND ("s_store_sk" = "ctr1"."ctr_store_sk")
   AND ("s_state" = 'TN')
   AND ("ctr1"."ctr_customer_sk" = "c_customer_sk")
ORDER BY "c_customer_id" ASC
LIMIT 100

[wendigo]

Plan will be rendered off box:

[wendigo]

When you scroll it, it's there:

[wendigo]

Same query causes JSON tab to hung for a bit

[koszti]

@wendigo, I see two possible approaches:

1. Dynamically position the first stage so it’s always visible.
2. Use the built-in fitView, which zooms and centers the entire flow.

Both have trade-offs:
Option 1 keeps the first stage in view but the full graph isn’t visible by default. Option 2 ensures the whole flow is shown but it may appear too small initially.

I’ll open a PR with option 1 but I’m open to feedback. Both options are easy fixes I’m just unsure which behavior makes more sense as the default. what do you think?

option 1) - positioning first stage to middle

option 2) - fitView:

[wendigo]

Can we have 2) but add a button "zoom to first stage"?

[koszti]

Can we have 2) but add a button "zoom to first stage"?

@wendigo #26794 is ready to review, it's implemented as you suggested.

[koszti]

Same query causes JSON tab to hung for a bit

It's because the react-syntax-highlighter is noticeably slow with large code blocks and the JSON here is about 1.5 MB and takes a while to render. Without highlighting rendering is fast. I'm unsure what's the best approach here. I’ll experiment with adding a loading indicator, try to apply some tweaks to optimize rendering and also look into alternative highlighter libraries that might perform better.

[wendigo]

@koszti https://carlosnz.github.io/json-edit-react maybe this one?

[koszti]

I tested carlosnz/json-edit-react and a few other options, including a low-level and custom async prismjs setup but none of them performed well.

I then tried monaco-editor (the editor behind VS Code) and it looks excellent. It renders very large JSON files with syntax highlighting instantly. Furthermore since monaco-editor is already used in trino-query-ui adopting it here would also give us consistency across projects. The trade-off is a slightly larger bundle size (~2 MB) but given that we regularly download JSONs of similar size from the trino server, I don’t think it’s an issue.

I’ll go ahead and replace the current implementation and will send PR soon.

[wendigo]

@koszti sounds great!