Hiccdown Development Notes
Showing only ideas leading to #5857.
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 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.
Turbo 8 already does most of this. With broadcasts_refreshes and morphing, each viewer's page re-renders in their own request when a record changes, keeping scroll position and form state. Components would only save rendering and sending the rest of the page.
On large pages, like Veritula's discussions, that's too expensive: a refresh re-renders the whole page for every viewer, sends all of it, and morphs all of it, for a change to one idea. Components re-render, send and morph only what changed, so they'd give the same result as morphing on pages where morphing the whole page is too slow to use.