Hiccdown Development Notes

Showing only ideas leading to #5860.

See full discussion​·​See most recent related ideas
  Log in or sign up to participate in this discussion.
With an account, you can revise, criticize, and comment on ideas.

Discussions can branch out indefinitely. You may need to scroll sideways.
Dennis Hackethal’s avatar
Dennis HackethalOP​·​#5858​·​​·​AI-assisted
Only version leading to #5860 (3 total)

Make Hiccdown reactive, like Reagent: a helper method as the first element marks a component, as in [method(:product_card), @product]. A Method knows its module and name, so a later request can call ProductsHelper#product_card again for the same records.

The server keeps track of which components each page rendered, with which records, and gives each component's element the id dom_id(record), as turbo streams do. When a record changes (after_commit, checking that it actually changed), the server tells the pages showing it, over Action Cable. Each page then requests just that component, which renders in the viewer's own request, with their user, session, locale, time zone and CSRF token, and swaps it in with a turbo stream.

Rendering the component in the request that changed the record would save that round trip, but that request has none of the viewers' context: it would render for the wrong user, or have to rebuild each viewer's context and render once per viewer.

A first pass can skip checking whether a change affects what a component shows, as when a product's name changes on a page that only shows its price.

Dennis Hackethal’s avatar
Dennis HackethalOP​·​#5860​·​​·​AI-assisted

Measured on Veritula locally, on a discussion of 213 ideas:

  • The whole discussion page, which a Turbo refresh re-renders: 211 ms and 506 KB, of which loading the whole tree (Idea.tree) takes 18 ms and Hiccdown.to_html 35 ms.
  • One idea's own markup, without its replies: 0.4 ms (median; 0.9 ms at the 90th percentile).
  • One idea's HTML with its replies: 3.3 KB (median).

A component request would cost the request's fixed overhead, loading that idea's part of the tree (18 ms at most) and about a millisecond of rendering: an estimated 10–30 ms and a few KB, about ten times faster and a hundred times smaller than the whole page. The whole page grows with the discussion while a component stays about the same, and the browser morphing 500 KB of DOM, which I didn't measure, comes on top.

  • Rationally adoptable.
  • Not rationally adoptable.
  • Older versions with pending criticisms.
  • Ideas are blue, criticisms red, comments small and gray.
  • Hover over ideas to expand them.
  • Click on ideas to jump to their place in the discussion.