@solidrt/components 0.0.38 → 0.0.39

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@solidrt/components",
-  "version": "0.0.38",
+  "version": "0.0.39",
   "license": "MIT",
   "author": "Antoine van Wel",
   "type": "module",
@@ -17,7 +17,7 @@
     "qrcode-generator": "^2.0.4"
   },
   "peerDependencies": {
-    "@solidjs/signals": "2.0.0-beta.20",
-    "@solidrt/core": "0.0.38"
+    "@solidjs/signals": "2.0.0-beta.26",
+    "@solidrt/core": "0.0.39"
   }
 }

package/src/button.tsx

@@ -24,6 +24,7 @@ export interface ButtonProps {
   size?: ButtonSize
   onPress?: () => void
   disabled?: boolean
+  ref?: (node: { id: number }) => void
   layout?: LayoutProps
   style?: StyleProps
 }
@@ -93,7 +94,10 @@ export function Button(props: ButtonProps) {
 
   return (
     <view
-      ref={press.ref}
+      ref={(n: { id: number }) => {
+        press.ref(n)
+        props.ref?.(n)
+      }}
       repaintBoundary
       flexDirection="row"
       alignItems="center"

package/src/press.ts

@@ -2,6 +2,10 @@ import { createSignal, onSettled, getBoundingBoxViewport } from "@solidrt/core"
 import type { PointerEvent } from "@solidrt/core"
 import { claim, release } from "./arena"
 
+// A live view of a recognizer's state, not a snapshot: both fields are getters,
+// so a consumer that reads one inside a JSX prop or child expression tracks that
+// signal there and nothing else re-runs. Read them in those positions, not
+// eagerly into a local, or the read lands in whatever scope destructured it.
 export type PressState = { pressed: boolean; hovered: boolean }
 
 export interface PressOptions {
@@ -43,7 +47,23 @@ export function createPress(options: PressOptions) {
   let active: number | null = null
   let inside = false
 
-  let state = (): PressState => ({ pressed: pressed(), hovered: hovered() })
+  // One stable object of getters, handed out as-is. Returning a fresh snapshot
+  // instead would read both signals at call time, making them dependencies of
+  // the caller's scope - and for render-prop children that scope is the one
+  // that builds the subtree, so a hover or press would rebuild it. A rebuild
+  // mid-gesture replaces a nested recognizer with a fresh one that never saw
+  // the down, so its up fires nothing: invisible with a mouse (hover settles
+  // long before the click) and fatal on touch, where the finger's arrival flips
+  // the ancestor's hover during the very gesture it is meant to recognize.
+  let live: PressState = {
+    get pressed() {
+      return pressed()
+    },
+    get hovered() {
+      return hovered()
+    },
+  }
+  let state = (): PressState => live
   let ref = (n: { id: number }) => {
     node = n
   }

package/src/pressable.tsx

@@ -7,7 +7,9 @@ export type { PressState } from "./press"
 
 export interface PressableProps extends PointerProps {
   // children and style may be functions of the press state, so a caller can
-  // restyle on press/hover without wiring their own signals.
+  // restyle on press/hover without wiring their own signals. The state is live
+  // (getters, not a snapshot): read it inside a prop or child expression, never
+  // eagerly into a local, or the value is captured once where it was read.
   children?: any | ((state: PressState) => any)
   ref?: (node: { id: number }) => void
   layout?: LayoutProps
@@ -29,6 +31,10 @@ export function Pressable(props: PressableProps) {
   // ((state) => ...) passes through it intact because flatten only unwraps
   // zero-arg functions.
   let resolved = children(() => props.children)
+  // The render prop runs once: the state it receives is a live object of getters
+  // (see press.ts), so a press or hover updates only the props that read it
+  // rather than rebuilding this subtree - which is what keeps a nested
+  // recognizer's in-flight gesture alive.
   let kids = () => {
     // children()'s return type erases the render-prop variant, hence the any.
     let c = resolved() as any

package/src/split-view.tsx

@@ -1,6 +1,5 @@
 import { Show } from "@solidrt/core"
 import type { LayoutProps } from "@solidrt/core"
-import { theme } from "./theme"
 import { policy } from "./policy"
 
 export interface SplitViewProps {
@@ -20,11 +19,18 @@ const LIST_WIDTH = 320
 
 /**
  * A list-detail container driven by the layout policy: two-pane shows the list
- * beside the detail with a hairline between, single-pane shows one pane at a
- * time per `showDetail`. Keep pane state (selection, scroll) in the app, not
- * in the panes: crossing a breakpoint re-arranges and can remount them.
+ * beside the detail, single-pane shows one pane at a time per `showDetail`.
+ * Keep pane state (selection, scroll) in the app, not in the panes: crossing
+ * a breakpoint re-arranges and can remount them.
  * SplitView draws no chrome; a back affordance in the single-pane detail is
  * the app's to render (fork on policy.layout, as the shell example does).
+ *
+ * Panes get no padding, max-width or alignment either - that is content, and
+ * SplitView cannot know the intended reading width. Give the single-pane
+ * detail the same treatment as the list (centered max-width column), otherwise
+ * crossing the breakpoint leaves the detail hugging the window's left edge
+ * while every other screen stays centered. Two-pane wants the opposite: the
+ * detail sits against the pane edge, since the pane already bounds its width.
  */
 export function SplitView(props: SplitViewProps) {
   return (
@@ -42,9 +48,6 @@ export function SplitView(props: SplitViewProps) {
         <view width={props.listWidth ?? LIST_WIDTH} flexDirection="column">
           {props.list}
         </view>
-        <view width={1}>
-          <d-rect color={theme.color.border} />
-        </view>
         <view flex={1} flexDirection="column">
           {props.detail}
         </view>