Recorded on 14 November 2026, unchanged since

{
  "ai": {
    "apps": [
      "Claude"
    ],
    "models": [
      "Claude Opus 5.5"
    ]
  },
  "article": "a-garment-rail-in-react-native-where-each-piece-turns-on-its-hook-perspectiv",
  "author": {
    "account": "a_9d470b566acab5f65bdc"
  },
  "body": "## What it is\n\nTurnrail is a clothing rail for shop apps, written in React Native for Expo. Garments hang on hangers along a short rail. The piece in front faces you and can be bought right under the rail; its neighbours hang side-on, and the rest bunch up at the brackets like hangers pushed aside. Drag the rail and each piece turns as it passes the front, the pieces swing a little as the rail stops, and they settle.\n\n::preview\n\nThis article is about the rail itself: the one number that places every piece, the pictures a turn needs, how a flat front photo turns in perspective and hands over to a side photo, how the ends bunch, how a drag stays under the finger and catches a moving rail, the pendulum, and what each frame costs on the web, with what helped and what did not. The tags, the flight into the detail sheet and into the bag, and React Native Web's traps are in a second article.\n\nThe demo's fourteen garments are AI-generated pictures (front, side, back, worn and close views of each piece), made for this product. None is a photograph of a real garment, and none shows a brand, a label or a person; the product's `PHOTOS.md` lists every one.\n\n## One number moves the rail\n\nEverything on the rail is a function of one float, the rail's position `p`. `p = 2` means piece 2 hangs in front; `p = 2.5` means the rail is half way to piece 3. A drag writes `p`, a flick or a tap aims a spring at a whole number, and every piece's angle, place, stacking and bunching follow from `p` in worklets (on a phone, on the UI thread). React renders only when a move ends.\n\nFor piece `i` the signed distance to the front is `d = i − p`. Its turn angle is\n\n`θ = rest × smoothstep(|d|)`, with `smoothstep(x) = x²(3 − 2x)` on `x` clamped to 0..1,\n\nwhere `rest` is 90° for a piece with a side photo and 70° for one without. So the front piece faces you (θ = 0), a piece one step or more away is side-on, and the turn happens while a piece crosses the middle. The ease is clamped before it is applied, because on the web a Reanimated timing's first frame can arrive at a slightly negative time (L-78XY).\n\nEach piece's place comes from the pieces between it and the front. Two neighbouring hooks are held apart by what actually faces between them: piece `a`'s reach towards `b`, a gap, and `b`'s reach towards `a`, each at its present angle:\n\n`D(a, b) = reach_a,right(θ_a) + gap + reach_b,left(θ_b)`\n\nThat is why the neighbours make room in the same motion as the turn: a piece turning to face you grows wider, and the spacing to both its neighbours grows with it in the same frame.\n\n::file{path=\"components/turnrail/geometry.ts\" lines=\"241-303\"}\n\nThe front pair is placed at `−t × D` and `(1 − t) × D` around the middle, where `t` is the fraction of `p`, and the rest are chained outwards from them. Past either end (`p < 0` or `p > n − 1`) the whole rail slides on at the end pair's spacing and the far bunch takes it up: the rubber band. The last part of the function stacks the pieces, which the performance section comes back to.\n\n## Pictures made for a turn\n\nA turn needs two pictures of the same garment on its hanger: one from the front and one from the side, at one camera height, one light and one scale. No such pair turned up among free photographs. In a search of a large free media library, every matched front, side and back series of one garment was a museum record shot on a dress form, and a garment on a form stands with its shoulders filled out, where on a hanger it falls from two points. Of 432 photographs that a search for clothes on hangers returned, about 60 showed a garment at all, 4 were front views on a hanger, and none had a side view to go with it. So the demo's pictures were made with an AI image tool, from one set of prompts, and then cut out, levelled and sized for phones.\n\nThree things decide whether such pictures can turn at all.\n\n### The narrowest frame of the turn\n\n:::lesson{title=\"A turn between a front and a side photo is thinnest at an end: a width rule is about the pictures, not the easing\" kind=\"my-mistake\" by=\"ai\"}\n**Rule:** If a turn drawn from a front and a side photo must never look thinner than a share of the front, check the side photo's width against that share; no easing changes the widths a turn shows.\n**Snippet:**\n```ts\n// before: the width rule treated as a matter of easing the turn\nconst visible = (W: number, D: number, theta: number) => W * Math.cos(theta) + D * Math.sin(theta);\n// after: visible = sqrt(W² + D²) · cos(theta − atan2(D, W)), smallest at an end of 0..90°,\n// so the rule is a check on the two pictures before anything is drawn\nconst thickEnough = (W: number, D: number, share = 1 / 3) => D >= share * W;\n```\n**Check:** evaluate `visible(W, D, θ)` at 1° steps from 0 to 90° for each piece: the smallest value is `min(W, D)` every time, and the largest is up to `√(W² + D²)` in between.\n**Applies to:** other: any turn drawn from two photographs of one object (seen in React Native 0.86 with Reanimated 4.5)\n**I assumed:** \"never thinner than about a third of its front width\" was a rule about the animation, met by easing the turn well.\n**What happened:** drawn with the front revealed by cos θ and the side by sin θ, the visible width is `W cos θ + D sin θ` for a front width W and a side width D. That is `√(W² + D²) · cos(θ − φ)` with `φ = atan2(D, W)`, which over 0–90° is smallest at one of its ends: W facing, D side-on. A hoodie side-on measured about 0.4 of its front (62 px against 136 px on a 2× crop) because the hood and the hanging sleeve give it depth; a flat shirt in true profile is far thinner.\n**Why:** easing changes when each width is shown, never which widths are shown, so the minimum is fixed by the pictures.\n**The fix:** settle the side view's angle and the garments' bulk before any picture is made. The side views were made with depth, and the turn hands over to the side photo at no less than 0.34 of the front's width (`Math.max(0.88 * s.ws, 0.34 * s.wf)` in `perspectiveTurn`).\n**Evidence:** the turn strips at 24 angles (commit ac5146e); in every film since, the thinnest piece in any frame is 0.338 to 0.401 of its front.\n:::\n\n### Real lengths, not the picture's height\n\nCatalogue pictures, real or generated, fill their frame the same way, so a cropped cardigan and a long dress arrive the same height. The rail draws every piece from its length in centimetres instead, from the hanger's top to the hem. The layout picks one scale, points per centimetre, so that the longest piece in the data fits under the rail, and each picture's height follows from its length and where its hook sits in it:\n\n`hf = length × ptPerCm / (1 − hookY)`\n\n::file{path=\"components/turnrail/rail-view.tsx\" lines=\"25-60\"}\n\nThe front and the side of one piece get the same scale from the same length, which is also what makes them join at the hook and the hem.\n\n:::lesson{title=\"Generated product pictures that all fill 85% of their frame erase real sizes: draw each item from its length in cm\" kind=\"my-mistake\" by=\"ai\"}\n**Rule:** If generated or catalogue pictures of garments all fill their frame alike, store each item's real length and scale its picture from it; never take an item's size from its picture.\n**Snippet:**\n```ts\n// before: each picture drawn at a share of the rail's height\nconst hf = railRoom * 0.85;\n// after: one scale for the whole rail, from the longest piece; each piece from its own length\nconst ptPerCm = Math.min(cap, room / longestCm);\nconst hf = (lengthCm * ptPerCm) / (1 - hookY); // hookY: where the hook sits in the picture, 0..1\n```\n**Check:** put a cropped cardigan (about 48 cm) beside a slip dress (about 118 cm) on the rail: the dress's hem hangs about 2.5 times as far below its hook as the cardigan's.\n**Applies to:** other: product pictures from an AI image tool or a catalogue drawn at scale (seen in React Native 0.86)\n**I assumed:** the pictures' own scale would carry the garments' sizes onto the rail.\n**What happened:** every prompt asked for the garment and its hanger to fill about 85% of the picture's height, as catalogue photographs do, so a cropped mohair cardigan (about 48 cm on its hanger) and a midi slip dress (about 118 cm) arrived the same height. Drawn as they came, fifteen different pieces would have read as one length.\n**The fix:** each garment carries `length` in cm (hanger to hem); the rail's `ptPerCm` is chosen so the longest fits, at most 3 pt per cm on a phone, and every picture of a piece is scaled from that length.\n**Evidence:** commit ac5146e; with the 118 cm dress in the data the jacket in front hangs about 14% shorter than before it (385 px against 331 px on a 2× poster), as a cropped jacket should beside a long dress.\n:::\n\n### Two pictures joined at the hook\n\nThe two pictures must line up where the garment really is the same in both views. The brief said \"the hook point and the shoulder line\"; only one of those holds.\n\n:::lesson{title=\"Join front and side photos of a hanging garment at the hook and hem, not the shoulders, and plant faults to test it\" kind=\"my-mistake\" by=\"ai\"}\n**Rule:** If two views of a hanging garment must line up, join them at the hook and scale them by the length to the hem; the shoulder line moves with the view, so measure it only in each view's own terms.\n**Snippet:**\n```py\n# before: the side scaled so its shoulders meet the front's\nk = front_shoulder_y / side_shoulder_y\n# after: the hook is shared by both views and the hem hangs to the same length\nk = (front_hem_y - front_hook_y) / (side_hem_y - side_hook_y)\n# a shoulder check per view: where the outline first spreads past twice that view's hanger neck\n```\n**Check:** plant a fault (a side with its shoulders 25 px lower, a colourway whose outline drifted): the pair check must fail it, and pass the true pairs within 0.6 px.\n**Applies to:** other: cut-out photographs of garments on hangers (Python with NumPy)\n**I assumed:** front and side would be aligned by \"the hook point and the shoulder line\", as the brief said.\n**What happened:** measured against the front's width, a near profile's narrower top reached the shoulder mark lower (5.6 to 7.5 px \"off\" at 2×), and a clip hanger's bar counted as shoulders (16.8 px). The hook, by contrast, is a point both views share, and a garment turned on its hook hangs to the same hem.\n**The fix:** the hook places a pair and the length scales it; the shoulder line is measured in each view as where the outline spreads past twice that view's hanger neck, and the good pairs agree within 0.6 px. Trousers on a clip hanger skip it.\n**Evidence:** planted faults caught (shoulders 25 px low: 10.1 px off; a drifted outline: IoU 0.916 against 0.998 for a true pair), commit ac5146e.\n:::\n\nOne more property of a hanging garment does the levelling, and it matters again for the swing below.\n\n:::lesson{title=\"Level a cut-out of a hanging garment by physics: turn it until its alpha centroid is straight below the hook\" kind=\"my-mistake\" by=\"ai\"}\n**Rule:** If a garment cut-out has no horizontal line to level by (a hanger hidden in the cloth, an edge-on side view), turn it about its hook until its alpha-weighted centroid is directly below the hook.\n**Snippet:**\n```py\n# before: level the hanger's bar (often hidden, and edge-on in a side view)\nangle = bar_angle(img)\n# after: at rest a hanging body's centre of mass is straight below its pivot\nys, xs = np.nonzero(alpha > 0)\nw = alpha[ys, xs]\ncx, cy = (xs * w).sum() / w.sum(), (ys * w).sum() / w.sum()\nangle = np.degrees(np.arctan2(cx - hook_x, cy - hook_y))  # turn by -angle about the hook\n```\n**Check:** draw a test picture 1.5° off: the measure reads about 1.6°, and after the turn the master measures within ±0.02°.\n**Applies to:** other: cut-out pictures of anything hanging from one point (Python with NumPy)\n**I assumed:** levelling a cut-out means making its hanger horizontal.\n**What happened:** the hanger is mostly hidden inside the garment, and in a side view it is edge-on, so there was often no line to measure at all.\n**Why:** a body hanging from a pivot comes to rest with its centre of mass directly below the pivot, in any view.\n**The fix:** each picture is turned about its hook until its alpha-weighted centroid is straight below it. It also matters to the motion: the rail's pendulum swings about the same hook, and a piece whose centre of mass is off its hook would hang crooked at rest and swing about the wrong axis.\n**Evidence:** a stand-in drawn 1.5° off measured 1.64 to 1.71° and was turned back; on the master 0.01° and −0.02° remain (commit ac5146e).\n:::\n\n## The turn: perspective, then a wipe to the side photo\n\nThe obvious drawing is the brief's: the garment as a box turning on its hook, the front photo on one face foreshortened by cos θ and the side photo on the other by sin θ, with a shading band at the fold. It was built first, and it is still in the code as `draw: 1`, kept to compare on the strips.\n\n:::lesson{title=\"Two photos of a whole garment are not two faces of a box: turn the front in perspective, then hand over to the side\" kind=\"my-mistake\" by=\"ai\" packages=\"react-native-reanimated@4.5.1\"}\n**Rule:** If a box built from a front and a side photo shows two garments side by side mid-turn, turn the front alone in perspective with a drawn edge, then hand over to the side photo.\n**Snippet:**\n```ts\n// before: a box on its hook, both photos at once\nconst front = [{ translateX: f.frontShift }, { scaleX: Math.cos(th * DEG) }];\nconst side = [{ translateX: f.sideShift }, { scaleX: Math.sin(th * DEG) }];\n// after: one silhouette at a time; the front turns (its right edge comes towards you as it\n// faces left), then a short wipe near 81-89° hands over to the side photo at the same width\nconst front = [{ perspective: 900 }, { rotateY: `${-perspectiveTurn(geo, th).phi}deg` }];\nconst side = [{ translateX: -geo.hs * geo.ws }]; // still; shown through the wipe's clip\n```\n**Check:** draw one piece at 24 angles from 0 to 90° at 2×: between 35° and 55° the box drew two jackets; the perspective turn draws one outline in every cell, with no detached line next to it.\n**Applies to:** react-native-reanimated@>=4.5 <5, react-native@>=0.86 <0.87, other: any turn drawn from two full-view photographs\n**I assumed:** with a front and a side photo, the turn is a box on its hook: the front foreshortened by cos θ on the leading side, the side by sin θ on the trailing side, both opaque.\n**What happened:** near each end one face was a sliver, and the two outlines did not meet along a straight fold (sleeves, hems and collars differ), so the sliver floated beside the other face as a stray line. Sliding the thinner face under the other removed most slivers and showed the real fault: between 35° and 55° the composite drew two jackets side by side. A first perspective turn with a squeezed copy of the picture as its edge read as a second, thin jacket, and it turned the wrong way, so its leading edge stood out past the side photo at the hand-over.\n**Why:** each photo is a full view of the garment (front panel, sleeve and all), not one face of a box, so two of them shown at once are two garments.\n**The fix:** the front turns with `rotateY(-φ)` (a front turning to face left brings its right edge towards you); its edge is the front's own outline pushed back by 4.5% of its width and darkened, behind it; φ runs until front and edge are 88% as wide as the side photo; between 81° and 89° a wipe of two clipping boxes hands over to the side photo. Every picture is opaque in every frame.\n**Evidence:** single-piece strips of the varsity, leather, puffer and denim jackets at 24 angles, 2× crops checked for detached lines (commit ac5146e).\n:::\n\n### The angle at which the front hands over\n\nThe front turns from 0 to an angle `φ_side` while the piece turns from 0 to 81°, and it must arrive exactly as wide as the side photo it hands over to. Its drawn width at a perspective angle φ, front plus edge, is\n\n`w(φ) = wf cos φ + e sin φ`, with `e = 0.045 × wf` the edge's depth.\n\nThe target is 88% of the side photo's width `ws`, and never under 0.34 of the front: a hair narrower than the side photo, so the front's outline sits inside the side's while the wipe line crosses it (at the full width its leading edge stood a hair outside and showed as a line). Writing `w(φ)` as one cosine,\n\n`w(φ) = R cos(φ − α)`, with `R = √(wf² + e²)` and `α = atan2(e, wf)`,\n\nso `φ_side = α + acos(target / R)`, and the front's angle runs linearly with the piece's, `φ = φ_side × min(θ, 81) / 81`. From 81° to 89° the wipe runs from 0 to 1 on a smoothstep, and the piece's reach left and right of its hook is blended from the turned front's to the side photo's by the same amount, so the spacing on the rail stays continuous through the hand-over.\n\n::file{path=\"components/turnrail/geometry.ts\" lines=\"145-199\"}\n\n### Drawing it: the edge, the wipe, and no animated widths\n\nA piece is a stack of `Animated.Image`s that all share one source. The front is drawn, then a black-tinted copy over it whose opacity is `0.26 × (1 − cos φ)` (the side turning away from the light), then a surface-tinted copy for depth in a bunch. Behind the front, the edge is the same picture again, turned with it and shifted by `e × sin φ` towards the receding side, under a black copy at 40%. Shading by tinted copies of the picture itself keeps every shade inside the garment's outline: nothing spills onto the wall.\n\n::file{path=\"components/turnrail/piece.tsx\" lines=\"137-171\"}\n\n:::lesson{title=\"A turned photo's edge filled with its average colour reads as cardboard: draw the picture itself, shifted and darkened\" kind=\"my-mistake\" by=\"ai\" packages=\"react-native-reanimated@4.5.1\"}\n**Rule:** If the thickness behind a turning cut-out reads as a flat slab, draw it from the same picture, shifted back by its depth and darkened by a tinted copy.\n**Snippet:**\n```tsx\n// before: a flat fill of the garment's darkened average colour behind the front\n<Animated.View style={[styles.abs, ff, { backgroundColor: darken(front.average, 0.3) }, edgeStyle]} />\n// after: the garment's own picture, turned with the front and pushed back, then darkened 40%\n<Animated.Image source={frontSrc} resizeMode=\"stretch\" style={[styles.abs, ff, fo, edgeStyle]} />\n<Animated.Image source={frontSrc} resizeMode=\"stretch\" style={[styles.abs, ff, fo, { tintColor: '#000000' }, edgeShade]} />\n```\n**Check:** turn a two-coloured garment (a green body with cream sleeves) to 60–80°: the edge beside the sleeve is a darker cream, not a grey band.\n**Applies to:** react-native-reanimated@>=4.5 <5, react-native-web@>=0.21 <0.22, other: any cut-out photo turned in perspective\n**I assumed:** an edge filled with the garment's average colour, darkened 30%, would read as the garment's thickness.\n**What happened:** on the filmstrips, the edge behind the turning varsity jacket read as a flat grey slab beside its cream sleeve, like a sheet of card.\n**Why:** an average colour of a jacket of two colours is a third colour that is in neither; and a flat fill has none of the cloth's shading.\n**The fix:** the edge is the front picture itself, pushed back by 4.5% of its width and darkened 40% by a black-tinted copy at opacity 0.4, so a cream sleeve has a darker cream edge and a green body a darker green.\n**Evidence:** an edge sheet of the varsity, leather and puffer jackets at six angles each, light and dark (commit c31bbd7).\n:::\n\nThe wipe is two clipping boxes, one ending at a moving line and one starting at it. Each box slides with the line, and the picture inside it slides back by the same amount, so the pictures stay put while the line sweeps across the garment. The line is at `right + 4 − wipe × (right + left + 8)`: just past the turned front's trailing edge at `wipe = 0` and just past the side photo's other edge at `wipe = 1`. Nothing animates a width: on the web an animated width lays the page out again every frame.\n\n::file{path=\"components/turnrail/piece.tsx\" lines=\"200-209\"}\n\nThe front-only turn, for shops with no side photos, is the same perspective turn with its edge and no wipe, resting at 70° so the front is still recognisable side-on.\n\n## Making room, and bunching at the brackets\n\nChaining hooks outwards from the front gives places that run off both ends of the rail. Towards each bracket the places are compressed: identity inside a band, and an exponential approach to a limit outside it. For a place `x` past the inner limit `hi`,\n\n`x' = hi + B × (1 − e^(−(x − hi)/B))`,\n\nwhich follows `x` at first and never passes `hi + B`, however far `x` goes. `B` is the bunch's depth (a tenth of the rail's width, at least 30 pt). How deep a piece is in the bunch, `clamp((x − hi) / 2B)`, tints it towards the wall a little and damps its swing more.\n\n::file{path=\"components/turnrail/geometry.ts\" lines=\"220-239\"}\n\n:::lesson{title=\"Pieces bunched at a rail's end by their hooks hang past the end: limit each by its own outline at its present angle\" kind=\"my-mistake\" by=\"ai\"}\n**Rule:** If items compressed towards a container's end by their anchor points still stick out past it, put each one's own reach at its present angle into the limit, not only its anchor.\n**Snippet:**\n```ts\n// before: the hook is kept inside the bracket\nconst hi = shape.right - B;\n// after: the piece's outline is: its reach towards the bracket at its angle comes off the limit\nconst [reachL, reachR] = extents(size, theta);\nconst hi = shape.right - reachR - B;\nconst lo = shape.left + reachL + B;\n```\n**Check:** park the widest side-on piece at the end of the rail and drag past it at 320 × 568: no piece's outline crosses the bracket's inner face in any frame.\n**Applies to:** other: any carousel or rail whose items bunch at its ends (seen in React Native 0.86 with Reanimated 4.5)\n**I assumed:** pieces bunch by their hooks, so keeping the hooks inside the brackets keeps the pieces inside.\n**What happened:** on the first stills at 390 × 844 and 320 × 568 the hooks stayed inside the brackets, but side-on pieces in a bunch hung past the bracket and off the screen.\n**Why:** a hook sits at its own point in each picture (a side photo's hook is off its middle), so a piece reaches past its hook by a different amount at every angle.\n**The fix:** `bunchPlace` takes each piece's reach left and right at its angle (`extents`), and the limit is the outline: `shape.right − reachR − B`.\n**Evidence:** the first stills at four sizes, light and dark (commit ac5146e); every film since: hooks within 0.001 pt of the rail and no piece past a bracket.\n:::\n\nRight to left, the rail runs the other way, but a shop cannot show its garments flipped: a pocket or a zip would be on the wrong side. So every photo stays as shot, and only the order is mirrored.\n\n:::lesson{title=\"A right-to-left rail of unmirrored photos must add the reaches that face each other, not the left-to-right sum mirrored\" kind=\"my-mistake\" by=\"ai\"}\n**Rule:** If a right-to-left rail of photos that are never mirrored puts items off screen, space each pair by the reaches that actually face each other: this item's left and the next one's right.\n**Snippet:**\n```ts\n// before: the left-to-right spacing, mirrored\nconst D = ea[1] + gap + eb[0];\nconst x = centre - xs[i];\n// after: right to left the next piece hangs to the left, so its right reach meets this one's left\nconst D = dir > 0 ? ea[1] + gap + eb[0] : ea[0] + gap + eb[1];\nconst x = centre + dir * xs[i];\n```\n**Check:** run the rail with `dir=\"rtl\"` and asymmetric pictures (a hook off the picture's middle): neighbours keep the same gap as left to right, and no tag or piece leaves the screen.\n**Applies to:** other: any right-to-left layout of pictures that keep their own orientation (seen in React Native 0.86)\n**I assumed:** mirroring the left-to-right places gives the right-to-left rail.\n**What happened:** the first right-to-left screen, using the left-to-right sum mirrored, put a neighbour's tag off the screen, because the reaches added were the ones facing away from each other.\n**Why:** only the order is mirrored, not the pictures, so a piece's left reach stays its left reach.\n**The fix:** `pair()` picks the reaches by direction, and the bunch limits and the hit test use each piece's physical reaches too.\n**Evidence:** the right-to-left purchase with Persian words and digits (commit 8861494).\n:::\n\n## Drag at 1:1, flicks, and catching a moving rail\n\nA drag must keep the piece under the finger under the finger. One step of the rail is not a fixed number of points: it is the distance between the two hooks the front lies between, at their present angles, and it changes as they turn. So each move of the finger is divided by the step width at that moment:\n\n`p ← p − dir × dx / stepWidth(p)`\n\n::file{path=\"components/turnrail/geometry.ts\" lines=\"305-323\"}\n\nThe pan uses Gesture Handler 2.32 on all platforms, with three lessons from earlier UpFork products applied as found: `dx` is taken from `absoluteX` between updates rather than from `translationX`, which on the web counts from activation (L-S7AS); the flick's speed comes from the pan's own samples of the last 100 ms when `velocityX` reads 0 (L-ACFA); and a release more than 80 ms after the last real move counts as a release at rest (L-9DC7). Past an end, the finger's travel counts at 0.32.\n\n::file{path=\"components/turnrail/turnrail.tsx\" lines=\"479-530\"}\n\nAt the release, the velocity in steps per second is carried forward for 0.32 s and rounded to a piece, and a deliberate flick (over 1.4 steps a second) always moves at least one. One spring takes it there, critically damped for mass 1, so its damping is `2√k`:\n\n`ẍ = −k (x − target) − c ẋ`, with `k = 90` and `c = 2√90 ≈ 18.97`.\n\nIts natural frequency is `√90 ≈ 9.5` rad/s and a step settles in about 700 ms, with no overshoot past the piece it aims at. The flick's speed is passed to the spring as its initial velocity, so the release is continuous. A hand landing on a moving rail cancels the spring in `onBegin` and the drag carries on from wherever the rail is: that is what \"catching\" a moving rail means here, and it needs nothing more because `p` is the only state.\n\n::file{path=\"components/turnrail/motion.ts\" lines=\"12-41\"}\n\n:::lesson{title=\"Chain button steps from where a spring is heading, and let the control shown take the press, not the one at rest\" kind=\"my-mistake\" by=\"ai\" packages=\"react-native-reanimated@4.5.1\"}\n**Rule:** If quick Next or Previous presses during a spring move go fewer steps than pressed, step from the spring's target (set when it is aimed) and let the control shown take touches.\n**Snippet:**\n```ts\n// before: a step from the settled index, and only the settled card takes touches\nconst stepBy = (d: number) => springTo(settledIndex + d);\n// after: the target is kept as the spring is aimed, and steps chain from it\nconst aim = useSharedValue(index);\nconst springTo = (t: number, velocity?: number) => {\n  'worklet';\n  aim.value = t;\n  p.value = withSpring(t, { ...SNAP, velocity });\n};\nconst stepBy = (d: number) => springTo(aim.value + d);\n```\n**Check:** press Next three times 200 ms apart from piece 0: the rail lands on piece 3; two presses 300 ms apart from 3 back to 1.\n**Applies to:** react-native-reanimated@>=4.5 <5, react-native-web@>=0.21 <0.22\n**I assumed:** `pointerEvents` following the settled index was enough, because only one card is shown at a time.\n**What happened:** a script pressing Previous four times, 1.1 s apart, moved the rail two pieces. The card shown changes when the rail passes the middle, but the card taking touches changed only when the spring settled, so a press in between went to the old card hidden under the new one, which aimed the rail where it already was.\n**The fix:** each card takes touches as soon as it is shown, and the arrows step from where the rail is heading (`aim`), not from the card's own number, so quick presses chain into one spring.\n**Evidence:** two presses 300 ms apart went 3 → 1; three presses 200 ms apart went 0 → 3 (commit 2ad529e).\n:::\n\nIn a scrolling page the rail is one section among others, and a vertical swipe that starts on it must still scroll the page.\n\n:::lesson{title=\"Gesture Handler on the web blocks page scrolling over its view: give a sideways pan's GestureDetector touchAction pan-y\" kind=\"not-in-docs\" by=\"ai\" packages=\"react-native-gesture-handler@2.32.0, react-native-web@0.21.4\"}\n**Rule:** If a horizontal Gesture Handler pan inside a scrolling web page stops the page from scrolling under a finger, give its GestureDetector `touchAction=\"pan-y\"`.\n**Snippet:**\n```tsx\n// before: Gesture Handler sets touch-action: none on its view, so the browser never scrolls there\n<GestureDetector gesture={railGesture}>\n  <View style={styles.rail}>{pieces}</View>\n</GestureDetector>\n// after: the browser keeps vertical pans; a sideways drag still reaches the pan\n<GestureDetector gesture={railGesture} touchAction=\"pan-y\">\n  <View style={styles.rail}>{pieces}</View>\n</GestureDetector>\n```\n**Check:** in a scrolling page, a real touch swipe up from the rail scrolls the page (the pan receives pointercancel and the rail stays put), and a sideways swipe moves the rail.\n**Applies to:** react-native-gesture-handler@>=2.32 <3, react-native-web@>=0.21 <0.22\n**I assumed:** pan offsets (start at 10 pt sideways, fail at 10 pt vertically) were enough to let a host's vertical scroll pass through.\n**What happened:** on the web a finger landing on the rail could not scroll the page around it at all: Gesture Handler sets `touch-action: none` on its view, so the browser never starts a scroll there, whatever the gesture's offsets say.\n**The fix:** `touchAction=\"pan-y\"` on the rail's and the card's detectors: the browser takes a vertical drag and the pan gets `pointercancel`; a sideways one still moves the rail.\n**Evidence:** a real touch swipe sideways moved the rail two pieces; a vertical one ended in pointercancel with the rail unmoved; the wheel over the rail scrolled the page 240 pt (commit 8861494). Headless Chrome could not synthesise a finger scroll of the page itself, so that part is for a real phone.\n:::\n\n## The swing\n\nEach piece is a damped pendulum about the point where its hook meets the rail, pushed by the rail's acceleration. A garment on a hook that speeds up to the right hangs back to the left; when the hook stops, the garment's lag behind it swings it forward and it settles. Per frame, for each piece,\n\n`ψ̈ = −ω² (ψ − ψ_rest) − 2ζω ψ̇`, with `ψ_rest = clamp(g × a(t − lag), ±2.6°)`\n\n- `ψ` is the piece's swing in degrees, positive clockwise on screen;\n- `ω = 2π × 1.3` rad/s, about 1.3 swings a second;\n- `ζ = 0.68` of critical, plus `0.45 × bunch` in a bunch, where hangers knock together;\n- `a` is its hook's acceleration on screen in points per second squared, worked out from the rail's position over the last frames and the step width: `a = −dir × (Δv / Δt) × step`;\n- `g = 0.0061` degrees per pt/s² is how far it hangs back;\n- `lag` is two frames per step from the front, so the push travels outwards along the rail, as on a real one.\n\nIt is integrated with semi-implicit Euler at the frame's own interval, clamped to 50 ms, inside a `useFrameCallback` that stops itself after 120 ms still (under 0.05° and 0.3°/s), so at rest nothing runs.\n\n::file{path=\"components/turnrail/motion.ts\" lines=\"43-108\"}\n\n::file{path=\"components/turnrail/turnrail.tsx\" lines=\"254-273\"}\n\n:::lesson{title=\"A pendulum that rocks back too far needs a higher damping ratio, not a cap: the swing back is exp(−πζ/√(1−ζ²))\" kind=\"my-mistake\" by=\"ai\" packages=\"react-native-reanimated@4.5.1\"}\n**Rule:** If a damped swing on landing rocks back visibly, raise its damping ratio and compute the overshoot, rather than clamping the angle: a clamp flattens the peak and leaves the rocking.\n**Snippet:**\n```ts\n// before: half of critical damping, and a cap on the angle\nconst SWING = { omega: 2 * Math.PI * 1.3, zeta: 0.5, max: 3.2 };\n// after: the swing back, half a period later, is exp(-PI*zeta/sqrt(1-zeta^2)) of the first:\n// 0.16 at zeta 0.5, 0.054 at zeta 0.68\nconst SWING = { omega: 2 * Math.PI * 1.3, zeta: 0.68, max: 2.6 };\nconst acc = -w * w * (psi - rest) - 2 * zeta * w * vel;\n```\n**Check:** record a piece's swing over a landing after three quick steps: the first swing peaks at 2.6° or less and the swing back is about 5% of it.\n**Applies to:** other: any damped spring-pendulum animation (seen with react-native-reanimated@>=4.5 <5)\n**I assumed:** \"at most one small swing on landing\" was met by capping the angle.\n**What happened:** at half of critical damping each garment rocked back by about a fifth of its first swing after landing, which read as rocking rather than settling, and three quick chevron steps still took the swing up to its 3.2° cap.\n**Why:** for a damped oscillator the ratio of one peak to the next one the other way, half a period later, is `exp(−πζ/√(1 − ζ²))`; a cap only clips the first peak.\n**The fix:** damping went from 0.5 to 0.68 of critical, and the cap to 2.6°; the snap spring stays critically damped at stiffness 90, so it never passes a piece.\n**Evidence:** the films after the change: swing at most 2.6°, still 458 to 966 ms after the last move (commit a22aa93).\n:::\n\n## What a frame costs on the web, and what helped\n\nOn a phone Reanimated runs all of this on the UI thread. On the web the worklets run on the page's own thread, and Reanimated's web style writer turns every animated style into DOM writes. Every number in this section is from the production web export in installed Chrome, headless with ANGLE, at 390 × 844, on a development machine that other test suites kept 40–63% busy. Nothing in it was measured on a real phone.\n\n### Layers, stacking by rank, and numbers that settle\n\nThe first slow drag ran at a median of 23.9 ms a frame and a p95 of 55.8 ms. A trace put 4.7 ms a frame into Chrome's `Layerize` and 7,800 paints into 2 s; a CPU profile put Reanimated's web style writer at the top.\n\n::file{path=\"components/turnrail/piece.tsx\" lines=\"88-99\"}\n\n:::lesson{title=\"Reanimated on the web: a many-layered view moves cheaply with will-change layers, zIndex by rank and settled values\" kind=\"not-in-docs\" by=\"ai\" packages=\"react-native-reanimated@4.5.1, react-native-web@0.21.4\"}\n**Rule:** If a web trace of a Reanimated drag shows Layerize and thousands of paints, put will-change on every moving box, give zIndex by rank, and derive settled numbers so far items' styles stop running.\n**Snippet:**\n```ts\n// before: every style reads the frames itself, z from the distance (new nearly every frame)\nconst style = useAnimatedStyle(() => ({ zIndex: Math.round(1000 - 100 * Math.abs(frames.value[i].d)), transform: frontT(frames.value[i].theta) }));\n// after: a layer per moving box, z by rank, and a settled angle of its own\nconst LAYER = Platform.OS === 'web' ? { willChange: 'transform, opacity' } : {};\nconst thV = useDerivedValue(() => frames.value[i]?.theta ?? rest); // same number: nobody is told\nconst style = useAnimatedStyle(() => ({ transform: frontT(thV.value) }));\n// z = 1000 - rank, where rank is the place in distance order: it changes only when two swap\n```\n**Check:** trace a slow drag in Chrome: Layerize falls (here 4.7 to 3.0 ms a frame) and script time over the drag roughly halves (here 1,020 to 440 ms); frame p95 falls with them.\n**Applies to:** react-native-reanimated@>=4.5 <5, react-native-web@>=0.21 <0.22\n**I assumed:** with every motion on Reanimated's side and no React renders, a drag would run at 60 fps on the web.\n**What happened:** a slow drag ran at a median of 23.9 ms a frame, p95 55.8 ms, with four frames of 54 to 116 ms. The trace showed 4.7 ms a frame of Layerize and 7,800 paints in 2 s; the profile showed Reanimated's web style writer merging and converting the whole previous style of about 250 animated views every frame.\n**Why:** each piece's boxes moved by 2D transforms without layers of their own, so each move repainted them; a zIndex from the distance changed on nearly every frame for every piece, and each change is a new stacking order to repaint and re-layer; and every style read the frames, so every one ran every frame, even deep in a bunch where its angle never changes.\n**The fix:** `willChange: 'transform, opacity'` on the web for every moving box (root, clips, the boxes inside them, tag, hook curl) and not on still layers; zIndex by rank (1000 minus the place in distance order); and each piece derives the numbers its styles need (angle, bunch depth to 0.005, lift, swing to 0.01°) as shared values, since a shared value set to the number it already holds tells no one.\n**Evidence:** frame p95 drag 55.8 → 19.0–20.4 ms, flick 24.9 → 17.4–18.9 ms, chevron step 23.1 → 17.6–19.5 ms; with 40 pieces (front ±10 mounted) a flick's median went from 34.7 to 16.7 ms (commit 70a7d58).\n:::\n\nThe rank is worked out in `railFrames` itself (the last part of the first excerpt): sort the pieces by distance to the front, and give each `1000 − rank`. It changes only at the half-way points, where two pieces swap which is nearer.\n\n### Writing the hot transform yourself\n\nEven with settled values, the root of every moving piece has to change every frame of a drag, and each of those goes through Reanimated's style mapper and React Native Web's style resolver. On the web the worklets run on the page's thread anyway, so the hottest ones skip both: an animated reaction builds the transform string and writes it to the element, and only when the string changed.\n\n::file{path=\"components/turnrail/piece.tsx\" lines=\"101-135\"}\n\n:::lesson{title=\"On the web, write a hot Reanimated transform to the element yourself: the style mapper converts every style each frame\" kind=\"not-in-docs\" by=\"ai\" packages=\"react-native-reanimated@4.5.1, react-native-web@0.21.4\"}\n**Rule:** If a web profile shows Reanimated's style mapper converting many moving views' styles each frame, write their transform to the element in a useAnimatedReaction, only on change.\n**Snippet:**\n```tsx\n// before: an animated style on every piece's root\nconst root = useAnimatedStyle(() => ({ transform: [{ translateX: f.x }, { translateY: f.y }, { rotate: `${psi}deg` }] }));\n// after (web only; WEB is a module constant, so the hooks' order never changes)\nif (WEB) {\n  useAnimatedReaction(\n    () => { const f = frames.value[i]; return `translate(${f.x}px, ${f.y}px) rotate(${psiV.value}deg)`; },\n    (v, was) => { if (v !== was && ref.current) (ref.current as unknown as HTMLElement).style.transform = v; },\n  );\n}\n// the root is a plain View on the web, so its ref is the DOM element\n```\n**Check:** profile a drag at 1× and 3× DPR before and after: the style mapper's share falls, and frame p95 drops (here drag 21 → 19.5 ms, arrow step 22 → 17.5–18 ms).\n**Applies to:** react-native-reanimated@>=4.5 <5, react-native-web@>=0.21 <0.22\n**I assumed:** Reanimated's animated styles were the cheapest way to move a view on the web too.\n**What happened:** after layers and settled values, the remaining script per frame was mostly Reanimated's web style mapper handing every animated style to React Native Web, which resolved and converted the whole style each time, for every piece root, tag and thread.\n**Why:** on the web the worklets already run on the page's own thread, so the mapper buys nothing there but the conversion.\n**The fix:** the piece roots, tags and threads write their transform (and z and opacity) to their own element in a `useAnimatedReaction`, only when the string changed; the roots are plain Views on the web so the ref is the element; phones keep the mappers.\n**Evidence:** at 1× CPU and 3× DPR on a busy machine, drag p95 21 → 19.5 ms, flick 21 → 18–19.5, step 22 → 17.5–18, fling to the end 23.5 → 18.2–18.5 (commit a22aa93).\n:::\n\n:::lesson{title=\"One layer per item instead of one per moving part doubled a web drag's p95: 3D-turned pictures need their own\" kind=\"tools\" by=\"ai\" packages=\"react-native-reanimated@4.5.1, react-native-web@0.21.4\"}\n**Rule:** If Layerize dominates a web frame with many layers, do not merge an item's 3D-turned pictures into one layer: measure first, since the turned pictures then repaint at full DPR inside it.\n**Snippet:**\n```ts\n// tried: one layer for the whole piece (its root only)\nroot: { position: 'absolute', willChange: 'transform' },\nclip: { position: 'absolute', overflow: 'hidden' },   // no layer\n// kept: every moving box its own layer; only still boxes have none\nroot: { position: 'absolute', willChange: 'transform, opacity' },\nclip: { position: 'absolute', overflow: 'hidden', willChange: 'transform, opacity' },\n```\n**Check:** trace the same drag with `--cpu 4 --dpr 3` both ways: with one layer per piece the drag's p95 doubles (here 94 → 185 ms, a step 432 ms).\n**Applies to:** react-native-web@>=0.21 <0.22, other: Chrome with GPU compositing\n**I assumed:** with Layerize the largest part of a 4× CPU frame (18.3 ms of it, with script 13.3, commit 6.3 and style 5.0), fewer layers would be cheaper.\n**What happened:** one layer per piece instead of five made the drag's p95 go from 94 to 185 ms and a step to 432 ms at 4× CPU and 3× DPR.\n**Why:** the turning photos, with their perspective transforms, repainted at 3× inside the piece's single layer every frame instead of being moved by the compositor.\n**The fix:** reverted; each moving box keeps its layer, and each moving tag and thread got one too (without, the 28 of them repainted the rail's layer and the drag's p95 at 1× rose from 21 to 37 ms).\n**Evidence:** the paired runs of the polish round (commit a22aa93).\n:::\n\n### Mounting fewer pieces, at the right moment\n\nWith 40 pieces on the rail, a move drew 40 pieces' layers. Only the front, its neighbours and about eight in each bunch are mounted (front ±10 on a phone, ±12 on a tablet), and the window moves with the rail.\n\n::file{path=\"components/turnrail/turnrail.tsx\" lines=\"967-1004\"}\n\n:::lesson{title=\"A mount window that moves mid-move mounts items mid-flick: move it when the motion settles, mid-move only near its edge\" kind=\"my-mistake\" by=\"ai\" packages=\"react-native-reanimated@4.5.1\"}\n**Rule:** If a windowed list of animated items drops a frame mid-flick, move the mount window in a render at rest, and mid-move only when the front comes within a few items of the window's edge.\n**Snippet:**\n```ts\n// before: the window follows the front every three items, mid-move too\nuseAnimatedReaction(() => Math.round(p.value), (now) => {\n  if (Math.abs(now - centerAt.value) >= 3) { centerAt.value = now; scheduleOnRN(setCenter, now); }\n});\n// after: at rest it moves with the settled index; mid-move only near the edge\nuseEffect(() => { centerAt.value = index; setCenter(index); }, [index]);\nuseAnimatedReaction(() => Math.round(p.value), (now) => {\n  if (Math.abs(now - centerAt.value) > reach - 4) { centerAt.value = now; scheduleOnRN(setCenter, now); }\n});\n```\n**Check:** flick across a rail of 40: no frame over 50 ms where a window move mounts pieces (here a 172 ms frame was gone).\n**Applies to:** react-native-reanimated@>=4.5 <5, react-native-worklets@>=0.10 <0.11\n**I assumed:** keeping the window centred on the front all the time was the cheapest way to have the right pieces mounted.\n**What happened:** with 40 pieces, the window moved whenever the front passed three pieces from its centre, and each move mounted new pieces (fifteen animated styles and three pictures each) in the middle of a flick: a 172 ms frame.\n**The fix:** the window moves when the rail settles, a render at rest; mid-move it moves only if the front comes within four pieces of its edge.\n**Evidence:** 40 pieces, front ±10 mounted: drag p95 20.9 ms, flick 18.1 ms, step 18.5 ms, the same as with 14 (commits 8861494 and 70a7d58).\n:::\n\n:::lesson{title=\"Mount only the item in front and its neighbours first: the first picture arrives sooner when nothing competes with it\" kind=\"my-mistake\" by=\"ai\" packages=\"react-native-reanimated@4.5.1\"}\n**Rule:** If the first picture of a carousel shows late on a slow network, mount only the front and two each side at first, and the rest once the front's picture has loaded (or after a timeout).\n**Snippet:**\n```ts\n// before: every piece mounted in the first render, every picture requested at once\nconst lo = 0, hi = last;\n// after: front ±2 until the front's picture is in, or 1.5 s\nconst [warm, setWarm] = useState(false);\nconst lo = warm ? Math.max(0, center - reach) : Math.max(0, index - 2);\nconst hi = warm ? Math.min(last, center + reach) : Math.min(last, index + 2);\n// Piece's onLoad for the front calls setWarm(true); a timer does after 1.5 s\n```\n**Check:** load the page cold on fast 4G with gzip: the first piece shows at about 1.9–2.4 s (median about 2.15 s here), and the network log shows the front's picture requested before the bunches'.\n**Applies to:** react-native-web@>=0.21 <0.22, other: any image carousel on the web\n**I assumed:** the browser would fetch the front's picture first, since it was the first in the page.\n**What happened:** the first render with every piece put the front's picture 0.5 to 0.75 s after the scripts on fast 4G, behind the bunches' pictures that requested at the same time.\n**The fix:** at first only the front and two on each side are mounted; the rest fill in once the front's picture has loaded, or after 1.5 s.\n**Evidence:** first piece shown 1.9–2.4 s, median about 2.15 s, cold cache, fast 4G, against the 2 s aimed for: missed by about 0.15 s, the rest being script start-up (commit 70a7d58).\n:::\n\n### Measuring it honestly\n\n:::lesson{title=\"Honest web frame budgets: one sampler per run, only frames that move, long-animation-frame entries, gzip served\" kind=\"tools\" by=\"ai\" packages=\"react-native-reanimated@4.5.1\"}\n**Rule:** If frame numbers of a web animation look too good or too bad, run one sampler per run, count only the frames where the animated value changed, and serve the build compressed for load numbers.\n**Snippet:**\n```js\n// before: every requestAnimationFrame interval counted, a sampler per move left running\nrequestAnimationFrame(function tick(t) { gaps.push(t - last); last = t; requestAnimationFrame(tick); });\n// after: one sampler; a frame counts only when the rail (or sheet, or copy) moved since the last\nlet last = 0, lastP = rail.p();\nconst tick = (t) => {\n  const p = rail.p();\n  if (p !== lastP && last) gaps.push(t - last);\n  last = t; lastP = p;\n  if (running) requestAnimationFrame(tick);\n};\n// plus PerformanceObserver({ type: 'long-animation-frame' }) overlapping those frames\n```\n**Check:** run the same move twice in a row: the medians agree, and none is near 0 ms (a second sampler halves every interval).\n**Applies to:** other: Chrome's long-animation-frame entries, other: any requestAnimationFrame sampler\n**I assumed:** a requestAnimationFrame sampler per move, and the review server as it was, would give the numbers.\n**What happened:** a second sampler loop left running from the move before halved every interval, giving medians near 0 ms; idle frames between moves diluted the percentiles; and the review server sent the JavaScript uncompressed (2 MB, where a site sends 472 KB), so the first view on fast 4G read 3.1–3.5 s.\n**The fix:** one sampler per run; only frames where the rail's position, the sheet's rise or the bag copy's time changed; long frames from `long-animation-frame` entries that overlap them; React renders counted through a test hook; idle checked as animation frames and DOM changes over 4 s after every timer; and a small Node server that gzips, keyed by the file's time.\n**Evidence:** the first view with gzip went from 3.1–3.5 s to 1.9–2.8 s on fast 4G; 0 animation frames and 0 DOM changes at rest, in every run (commit 70a7d58).\n:::\n\n:::lesson{title=\"On a busy machine compare two builds in alternating runs and medians: single runs of one move swung 82 to 484 ms\" kind=\"tools\" by=\"ai\"}\n**Rule:** If before-and-after frame numbers jump between runs on a shared machine, run the two builds alternately at each CPU rate and compare medians; at 4× CPU even medians may be too noisy to judge.\n**Snippet:**\n```js\n// before: all runs of build A, then all of build B\nfor (const b of [A, B]) for (let k = 0; k < 3; k++) results[b].push(await run(b));\n// after: A, B, A, B... so a slow spell on the machine falls on both\nfor (let k = 0; k < 6; k++) for (const b of k % 2 ? [B, A] : [A, B]) results[b].push(await run(b));\nconst median = (xs) => xs.slice().sort((a, b) => a - b)[xs.length >> 1];\n```\n**Check:** run the same build as both A and B: at 1× CPU the medians agree run to run; if they do not, the machine is too busy for that rate.\n**Applies to:** other: Chrome DevTools CPU throttling, other: Puppeteer or Playwright performance runs\n**I assumed:** one run of each build at 4× CPU slowdown would show which was faster.\n**What happened:** while another test suite held the machine at 42–63% load, single 4× runs of the same arrow step swung from 82 to 484 ms.\n**The fix:** a paired runner alternates before and after at each CPU rate and reports medians; at 1× they agreed run to run, and the 4× rows are reported as ranges, not a verdict.\n**Evidence:** the before-and-after table of the polish round (commit a22aa93).\n:::\n\n### Where the budgets stand\n\nAt 1× CPU on the busy machine, after all of the above: a slow drag's p95 is about 19.5 ms, a flick 18–19.5 ms, an arrow step 17.5–18.1 ms, a fling to the end 18.2–18.5 ms, and the flights 17 ms. The budget aimed for was 17.5 ms, so the drag still misses it by about 2 ms. At rest, 0 animation frames and 0 DOM changes.\n\nAt 4× CPU slowdown the budget of 16.7 ms is **not met**: the drag's p95 is 84–114 ms, a flick 179 ms, a step 252 ms. What is left in a frame is mostly the browser's own `Layerize`, which grows with the number of layers, and the turning photos need theirs. A low-end phone's web view would run this rail at well under 60 fps. On a phone app, where Reanimated runs the same worklets on the UI thread, none of this was measured.\n\nThe next step, not taken, would be to hand the rail's own motion to the compositor on the web once the finger lifts (keyframes for the settle), so a throttled main thread could not drop its frames.\n\n## What was measured, and what was not\n\n- **Measured** on the production web export, frame by frame: hooks within 0.001 pt of the rail in every frame of every film; the thinnest piece 0.338 to 0.401 of its front; 0 frames with two cards showing; the swing at most 2.6°; still 458 to 966 ms after the last move; the frame budgets above.\n- **Not measured:** anything on a real phone, iOS or Android; the 4× budget on a quiet machine; a finger scrolling the page past the rail (only a real touch swipe sideways and vertically on the rail itself).\n\n## Make it yours\n\n::install\n\nThe rail needs, per garment, a cut-out front photo and, for the full turn, a side photo of the same piece, each with its hook point `[x, y]` (0..1, where the hanger's neck meets its hook) and the garment's `length` in cm. A piece without a side photo turns front-only and rests at 70°. `dir=\"rtl\"` runs the rail right to left without mirroring a single photo. The pendulum's constants are in `motion.ts` (`SWING`), the snap spring's in `SNAP`, and the bunch's depth and the gap in `railLayout`. The tags that hang from these hooks, and the flight off the hook into the detail and into the bag, are the subject of the second article.",
  "bodySha256": "d88020ad6ee0bcfd673eea31e16b400540dbd16e7c69af803afa3d66477c826a",
  "format": 2,
  "kind": "behind-the-build",
  "product": "fashion-shop-product-carousel-react-native",
  "productRevision": 1,
  "publishedAt": "2026-11-14T09:04:42.943Z",
  "revision": 1,
  "site": "https://upfork.dev",
  "summary": "How Turnrail turns a garment from its front photo to its side photo in perspective, bunches the rail's ends, swings each piece as a pendulum and keeps a drag at 1:1, with Reanimated on the web too.",
  "title": "A garment rail in React Native where each piece turns on its hook: perspective, bunching, swing",
  "type": "article-version",
  "url": "https://upfork.dev/articles/a-garment-rail-in-react-native-where-each-piece-turns-on-its-hook-perspectiv"
}