dash_kit 2.1.0 → 2.2.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 0cfb78242c30e17c1eaedd518a9f5fd1af0886d019506d04f6959c4bf91d7ef0
-  data.tar.gz: 45f2cb90222190e06ee5310754abd3e8e265c50c91f54dbdfc9f148717bac89a
+  metadata.gz: 752a3c52f25de0472afd8d1143e5066c7e2d6bc62b31d4542417313cc94310e6
+  data.tar.gz: 783e9571276247d55b6bbcb779f475688b3b0897885b784135df0df81c179dfc
 SHA512:
-  metadata.gz: 88d1e0a9aa4ac99d547c55e4605ad8d422e2301c35809dded1601a4f7b82d9c830afb2afa6a723c8d9f445b9e8f8e134176d40233fe01b0e812acf78c06ef758
-  data.tar.gz: d7556f33269eff33c48bf9fc37f86e9fae047744e6e8a6c75ee07c43d3f3f94ce961a7ae3be50fd552c9fba65ada04237a0ebf6090f8a35b188957f1b5b86ddd
+  metadata.gz: 74532c9d76d342563918d0b8542a2dc9c84b1ce7145162171f01564dc973b9e04184f4aaebc26423ad11d9b9db1c11aeb4f7e7b69038af1a9f7d125dc6956251
+  data.tar.gz: e6676dbc1e78d966e6a56f49189b010147fa4b4eaf414d7598a5332d976a59184e123a1683b5c4f0f0bb137a1762bfb15d1b05336b1ca14b501bd9260964f2a7

data/README.md

@@ -168,3 +168,16 @@ end
 ## Design Philosophy
 
 DashKit avoids data semantics by design. It treats datasets as opaque structures that can be rendered consistently, allowing teams to replace or evolve backends without rewriting dashboards. This deliberate decoupling keeps DashKit focused, composable, and stable over time.
+
+## Setting up to work on DashKit
+
+After cloning, install the bundle and run the setup command:
+
+```
+bundle install
+bundle exec dev_onboarder
+```
+
+It runs the test suite and checks the Claude Code tooling the repo expects, and records what it found
+inside the clone's git directory, where nothing is committed. `bundle exec dev_onboarder status` lists what the repo
+requires now that it did not at your last run. The requirements are declared in `Setupfile`.

data/app/helpers/dash_kit/dashboard_helper.rb

@@ -39,11 +39,11 @@ module DashKit
       config.available_widgets.dig(widget_key.to_sym, :label) || widget_key.to_s.humanize
     end
 
-    def dash_kit_render_widgets(config:)
+    def dash_kit_render_widgets(config:, &draw)
       return content_tag(:div, "", id: "dashboard-widgets") unless config
 
       content_tag(:div, id: dash_kit_widgets_id(config)) do
-        dash_kit_arrangeable?(config) ? dash_kit_widget_grid(config) : dash_kit_drawn_widgets(config)
+        dash_kit_arrangeable?(config) ? dash_kit_widget_grid(config, &draw) : dash_kit_drawn_widgets(config, &draw)
       end
     end
 
@@ -55,10 +55,10 @@ module DashKit
       DashKit.editable?(config, dash_kit_current_viewer)
     end
 
-    def dash_kit_widget_grid(config)
+    def dash_kit_widget_grid(config, &draw)
       safe_join([
         react_ui("dash_kit/dashboard-grid", config.layout_data.merge(base: dash_kit.dashboard_path(config), token: dash_kit_form_token)),
-        block_contents(config.blocks) { |block| dash_kit_block_frame(config, block) }
+        block_contents(config.blocks) { |block| dash_kit_block_frame(config, block, &draw) }
       ])
     end
 
@@ -66,14 +66,16 @@ module DashKit
       controller.send(:form_authenticity_token) if controller.respond_to?(:form_authenticity_token, true)
     end
 
-    def dash_kit_drawn_widgets(config)
+    def dash_kit_drawn_widgets(config, &draw)
       block_layout(config.blocks, kind: config.dashboard_type.to_sym) do |block|
-        dash_kit_block_frame(config, block)
+        dash_kit_block_frame(config, block, &draw)
       end
     end
 
-    def dash_kit_block_frame(config, block)
-      return dash_kit_widget_frame(block["type"], dashboard_id: config.id) unless block["type"] == WidgetRegistry::BUILT_WIDGET.to_s
+    def dash_kit_block_frame(config, block, &draw)
+      unless block["type"] == WidgetRegistry::BUILT_WIDGET.to_s
+        return draw ? capture(block["type"], &draw) : dash_kit_widget_frame(block["type"], dashboard_id: config.id)
+      end
 
       definition = config.widget_definitions.find_by(id: block.dig("content", "definition_id"))
       definition ? dash_kit_widget_definition_frame(definition) : dash_kit_loading_skeleton

data/lib/dash_kit/reference/guide.md

@@ -12,8 +12,9 @@ coupling the UI to any specific data backend.
 - A widget registry: dashboard types map to the widgets available on them.
 - A persistence layer for user preferences (which widgets show, in what order,
   with which filters) via an ActiveRecord `Dashboard` model.
-- A rendering layer that lazy-loads each widget through a Turbo Frame and
-  refreshes on configuration change.
+- A rendering layer that lazy-loads each widget through a Turbo Frame, or hands
+  each widget to a block the host passes so the host draws it inside the page,
+  and refreshes on configuration change.
 
 A dashboard renders two kinds of widget side by side:
 
@@ -81,16 +82,19 @@ The layers, all under the `DashKit` namespace:
   `dash_kit_available_sources`, `dash_kit_visualizations`, and
   `dash_kit_widget_definition_frame(definition)`. `dash_kit_render_widgets`
   renders the registered widgets in order, then appends one lazy Turbo Frame per
-  `widget_definition`.
+  `widget_definition`. Given a block, it calls the block with each shown
+  registered widget's key and draws what the block returns in that widget's
+  place, inside the page's own request and with no Turbo Frame.
 
 ### Data flow
 
 UI events -> dashboard update -> Turbo refresh -> widgets re-render via
-lazy-loaded Turbo Frames. A widget is never rendered inline; it loads through a
+lazy-loaded Turbo Frames. Without a block, a widget loads through a
 `<turbo-frame loading="lazy">` pointing at the widget's own route. The frame
 carries its dashboard's id, so the widget partial is handed the dashboard's
 `filter_state` to render against (DashKit passes the blob; the host interprets
-it).
+it). With a block, DashKit decides only which widgets show and where, and the
+host draws each one from data it has already loaded for the page.
 
 Built widgets follow the same flow. Each `widget_definition` lazy-loads through
 its own `<turbo-frame>` at `/widget_definitions/:id`;
@@ -255,7 +259,7 @@ The following manual steps remain:
   display order.
 - **Supply the data yourself.** A widget's partial is responsible for fetching
   and rendering its own data; DashKit only renders the partial inside a lazy
-  Turbo Frame. Keep partials self-contained around the owner DashKit scopes to.
+  Turbo Frame, or calls the host's block with the widget's key. Keep partials self-contained around the owner DashKit scopes to.
   This holds for registered widgets and for built-widget renderer partials
   alike — both receive `filter_state` and read it to shape their own request.
 - **Register a renderer for every visualization the builder offers.** A built
@@ -274,9 +278,10 @@ The following manual steps remain:
   `WidgetManagement` methods (`toggle_widget`, `move_widget_up`,
   `move_widget_down`, `update_filter`) or the engine routes; do not write
   `widget_order` / `hidden_widgets` / `filter_state` directly.
-- **Let widgets lazy-load.** Render through `dash_kit_render_widgets` /
-  `dash_kit_widget_frame` so each widget loads in its own Turbo Frame; do not
-  inline widget bodies.
+- **Draw widgets through `dash_kit_render_widgets`.** Without a block, each
+  widget loads in its own Turbo Frame. Pass a block when the page already holds
+  the widgets' data, so every widget is drawn in the page's own request rather
+  than one request per widget.
 - **Mobile-first, Tailwind, dark mode.** The shipped UI is styled with Tailwind
   and supports dark mode; host styling should match. The primary surface is
   often a native webview.

data/lib/dash_kit/the_local/agents/dash_kit-develop.md

@@ -20,8 +20,9 @@ coupling the UI to any specific data backend.
 - A widget registry: dashboard types map to the widgets available on them.
 - A persistence layer for user preferences (which widgets show, in what order,
   with which filters) via an ActiveRecord `Dashboard` model.
-- A rendering layer that lazy-loads each widget through a Turbo Frame and
-  refreshes on configuration change.
+- A rendering layer that lazy-loads each widget through a Turbo Frame, or hands
+  each widget to a block the host passes so the host draws it inside the page,
+  and refreshes on configuration change.
 
 A dashboard renders two kinds of widget side by side:
 
@@ -89,16 +90,19 @@ The layers, all under the `DashKit` namespace:
   `dash_kit_available_sources`, `dash_kit_visualizations`, and
   `dash_kit_widget_definition_frame(definition)`. `dash_kit_render_widgets`
   renders the registered widgets in order, then appends one lazy Turbo Frame per
-  `widget_definition`.
+  `widget_definition`. Given a block, it calls the block with each shown
+  registered widget's key and draws what the block returns in that widget's
+  place, inside the page's own request and with no Turbo Frame.
 
 ### Data flow
 
 UI events -> dashboard update -> Turbo refresh -> widgets re-render via
-lazy-loaded Turbo Frames. A widget is never rendered inline; it loads through a
+lazy-loaded Turbo Frames. Without a block, a widget loads through a
 `<turbo-frame loading="lazy">` pointing at the widget's own route. The frame
 carries its dashboard's id, so the widget partial is handed the dashboard's
 `filter_state` to render against (DashKit passes the blob; the host interprets
-it).
+it). With a block, DashKit decides only which widgets show and where, and the
+host draws each one from data it has already loaded for the page.
 
 Built widgets follow the same flow. Each `widget_definition` lazy-loads through
 its own `<turbo-frame>` at `/widget_definitions/:id`;
@@ -263,7 +267,7 @@ The following manual steps remain:
   display order.
 - **Supply the data yourself.** A widget's partial is responsible for fetching
   and rendering its own data; DashKit only renders the partial inside a lazy
-  Turbo Frame. Keep partials self-contained around the owner DashKit scopes to.
+  Turbo Frame, or calls the host's block with the widget's key. Keep partials self-contained around the owner DashKit scopes to.
   This holds for registered widgets and for built-widget renderer partials
   alike — both receive `filter_state` and read it to shape their own request.
 - **Register a renderer for every visualization the builder offers.** A built
@@ -282,9 +286,10 @@ The following manual steps remain:
   `WidgetManagement` methods (`toggle_widget`, `move_widget_up`,
   `move_widget_down`, `update_filter`) or the engine routes; do not write
   `widget_order` / `hidden_widgets` / `filter_state` directly.
-- **Let widgets lazy-load.** Render through `dash_kit_render_widgets` /
-  `dash_kit_widget_frame` so each widget loads in its own Turbo Frame; do not
-  inline widget bodies.
+- **Draw widgets through `dash_kit_render_widgets`.** Without a block, each
+  widget loads in its own Turbo Frame. Pass a block when the page already holds
+  the widgets' data, so every widget is drawn in the page's own request rather
+  than one request per widget.
 - **Mobile-first, Tailwind, dark mode.** The shipped UI is styled with Tailwind
   and supports dark mode; host styling should match. The primary surface is
   often a native webview.

data/lib/dash_kit/the_local/agents/dash_kit-info.md

@@ -20,8 +20,9 @@ coupling the UI to any specific data backend.
 - A widget registry: dashboard types map to the widgets available on them.
 - A persistence layer for user preferences (which widgets show, in what order,
   with which filters) via an ActiveRecord `Dashboard` model.
-- A rendering layer that lazy-loads each widget through a Turbo Frame and
-  refreshes on configuration change.
+- A rendering layer that lazy-loads each widget through a Turbo Frame, or hands
+  each widget to a block the host passes so the host draws it inside the page,
+  and refreshes on configuration change.
 
 A dashboard renders two kinds of widget side by side:
 
@@ -89,16 +90,19 @@ The layers, all under the `DashKit` namespace:
   `dash_kit_available_sources`, `dash_kit_visualizations`, and
   `dash_kit_widget_definition_frame(definition)`. `dash_kit_render_widgets`
   renders the registered widgets in order, then appends one lazy Turbo Frame per
-  `widget_definition`.
+  `widget_definition`. Given a block, it calls the block with each shown
+  registered widget's key and draws what the block returns in that widget's
+  place, inside the page's own request and with no Turbo Frame.
 
 ### Data flow
 
 UI events -> dashboard update -> Turbo refresh -> widgets re-render via
-lazy-loaded Turbo Frames. A widget is never rendered inline; it loads through a
+lazy-loaded Turbo Frames. Without a block, a widget loads through a
 `<turbo-frame loading="lazy">` pointing at the widget's own route. The frame
 carries its dashboard's id, so the widget partial is handed the dashboard's
 `filter_state` to render against (DashKit passes the blob; the host interprets
-it).
+it). With a block, DashKit decides only which widgets show and where, and the
+host draws each one from data it has already loaded for the page.
 
 Built widgets follow the same flow. Each `widget_definition` lazy-loads through
 its own `<turbo-frame>` at `/widget_definitions/:id`;
@@ -263,7 +267,7 @@ The following manual steps remain:
   display order.
 - **Supply the data yourself.** A widget's partial is responsible for fetching
   and rendering its own data; DashKit only renders the partial inside a lazy
-  Turbo Frame. Keep partials self-contained around the owner DashKit scopes to.
+  Turbo Frame, or calls the host's block with the widget's key. Keep partials self-contained around the owner DashKit scopes to.
   This holds for registered widgets and for built-widget renderer partials
   alike — both receive `filter_state` and read it to shape their own request.
 - **Register a renderer for every visualization the builder offers.** A built
@@ -282,9 +286,10 @@ The following manual steps remain:
   `WidgetManagement` methods (`toggle_widget`, `move_widget_up`,
   `move_widget_down`, `update_filter`) or the engine routes; do not write
   `widget_order` / `hidden_widgets` / `filter_state` directly.
-- **Let widgets lazy-load.** Render through `dash_kit_render_widgets` /
-  `dash_kit_widget_frame` so each widget loads in its own Turbo Frame; do not
-  inline widget bodies.
+- **Draw widgets through `dash_kit_render_widgets`.** Without a block, each
+  widget loads in its own Turbo Frame. Pass a block when the page already holds
+  the widgets' data, so every widget is drawn in the page's own request rather
+  than one request per widget.
 - **Mobile-first, Tailwind, dark mode.** The shipped UI is styled with Tailwind
   and supports dark mode; host styling should match. The primary surface is
   often a native webview.

data/lib/dash_kit/the_local/agents/dash_kit-install.md

@@ -20,8 +20,9 @@ coupling the UI to any specific data backend.
 - A widget registry: dashboard types map to the widgets available on them.
 - A persistence layer for user preferences (which widgets show, in what order,
   with which filters) via an ActiveRecord `Dashboard` model.
-- A rendering layer that lazy-loads each widget through a Turbo Frame and
-  refreshes on configuration change.
+- A rendering layer that lazy-loads each widget through a Turbo Frame, or hands
+  each widget to a block the host passes so the host draws it inside the page,
+  and refreshes on configuration change.
 
 A dashboard renders two kinds of widget side by side:
 
@@ -89,16 +90,19 @@ The layers, all under the `DashKit` namespace:
   `dash_kit_available_sources`, `dash_kit_visualizations`, and
   `dash_kit_widget_definition_frame(definition)`. `dash_kit_render_widgets`
   renders the registered widgets in order, then appends one lazy Turbo Frame per
-  `widget_definition`.
+  `widget_definition`. Given a block, it calls the block with each shown
+  registered widget's key and draws what the block returns in that widget's
+  place, inside the page's own request and with no Turbo Frame.
 
 ### Data flow
 
 UI events -> dashboard update -> Turbo refresh -> widgets re-render via
-lazy-loaded Turbo Frames. A widget is never rendered inline; it loads through a
+lazy-loaded Turbo Frames. Without a block, a widget loads through a
 `<turbo-frame loading="lazy">` pointing at the widget's own route. The frame
 carries its dashboard's id, so the widget partial is handed the dashboard's
 `filter_state` to render against (DashKit passes the blob; the host interprets
-it).
+it). With a block, DashKit decides only which widgets show and where, and the
+host draws each one from data it has already loaded for the page.
 
 Built widgets follow the same flow. Each `widget_definition` lazy-loads through
 its own `<turbo-frame>` at `/widget_definitions/:id`;
@@ -263,7 +267,7 @@ The following manual steps remain:
   display order.
 - **Supply the data yourself.** A widget's partial is responsible for fetching
   and rendering its own data; DashKit only renders the partial inside a lazy
-  Turbo Frame. Keep partials self-contained around the owner DashKit scopes to.
+  Turbo Frame, or calls the host's block with the widget's key. Keep partials self-contained around the owner DashKit scopes to.
   This holds for registered widgets and for built-widget renderer partials
   alike — both receive `filter_state` and read it to shape their own request.
 - **Register a renderer for every visualization the builder offers.** A built
@@ -282,9 +286,10 @@ The following manual steps remain:
   `WidgetManagement` methods (`toggle_widget`, `move_widget_up`,
   `move_widget_down`, `update_filter`) or the engine routes; do not write
   `widget_order` / `hidden_widgets` / `filter_state` directly.
-- **Let widgets lazy-load.** Render through `dash_kit_render_widgets` /
-  `dash_kit_widget_frame` so each widget loads in its own Turbo Frame; do not
-  inline widget bodies.
+- **Draw widgets through `dash_kit_render_widgets`.** Without a block, each
+  widget loads in its own Turbo Frame. Pass a block when the page already holds
+  the widgets' data, so every widget is drawn in the page's own request rather
+  than one request per widget.
 - **Mobile-first, Tailwind, dark mode.** The shipped UI is styled with Tailwind
   and supports dark mode; host styling should match. The primary surface is
   often a native webview.

data/lib/dash_kit/version.rb

@@ -1,3 +1,3 @@
 module DashKit
-  VERSION = "2.1.0"
+  VERSION = "2.2.0"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: dash_kit
 version: !ruby/object:Gem::Version
-  version: 2.1.0
+  version: 2.2.0
 platform: ruby
 authors:
 - Tyler Schneider