Hiccdown Development Notes
Showing only ideas leading to #5856.
See full discussion·See most recent related ideasLog in or sign up to participate in this discussion.
With an account, you can revise, criticize, and comment on ideas.Make Hiccdown reactive, like Reagent: a proc as the first element marks a component, as in [->(product) { [:li, product.name] }, @product].
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.
Procs can't be found again in a later request. The lambda a helper built while rendering the page is gone by the time the page asks for the component, so the server has no way to call it again.