Question 1

What problem did Spin the Wheel Feature solve?

Accepted Answer

The backend already owned the wheel: which segments existed, what each was worth, how many attempts a user had left. What it did not own was how any of that felt, and the design team had specified a wheel the off-the-shelf library could not draw. Rendered naively the page also showed an empty wheel before the configuration arrived, shifted as the rest of the data landed, and the wheel jittered and sat slightly off its segment when it stopped.

Question 2

How was Spin the Wheel Feature built?

Accepted Answer

The library went from a dependency to source I owned: cloned from GitHub and reworked until it matched the spec, covering segment appearance, the spin timing and easing, where it came to rest against the pointer, and how it rendered at phone sizes. Around that, nothing paints until the configuration is in hand, each phase of a spin is a named state, and the layout reserves its space up front. The app opens the URL with an access token on the query string, forwarded with every request, and attempts reset on the first spin of a new day rather than through a scheduled job.

Question 3

What was the outcome of Spin the Wheel Feature?

Accepted Answer

A wheel that matches the design rather than approximating it, arrives fully formed, gives each user three spins a day, and stops exactly on the prize it was given. The reward is shown immediately after the spin, with a list of past wins behind it on mobile.

Question 4

Why forking react-custom-roulette and rewriting its internals rather than working within what the published API exposed? (Spin the Wheel Feature)

Accepted Answer

The design covered segment styling, the easing and length of the spin, exactly where the wheel settled against the pointer, and how it held up at phone widths. None of that was reachable through props, and the alternative was shipping a wheel that was visibly not the one the design team drew. I cloned the source and changed the implementation instead, which kept the rotation maths I did not need to rewrite while making the parts the spec cared about mine to control.

Question 5

Why holding the render until the configuration arrived rather than mounting the wheel with defaults and filling it in? (Spin the Wheel Feature)

Accepted Answer

A wheel drawn with placeholder segments and then corrected reads as broken, and it is the first thing a user sees. Waiting for the configuration cost a moment on load and removed the flicker completely.

Question 6

Why a named state per phase of the spin rather than a pair of loading and result booleans? (Spin the Wheel Feature)

Accepted Answer

The spin has more phases than it looks: waiting for the result, animating, revealing, and the case where the request fails and the attempt should not be spent. Naming each one made those rules something the UI followed rather than something reconstructed from flag combinations.

Question 7

Why the access token forwarded from the query string rather than a separate login inside the web view? (Spin the Wheel Feature)

Accepted Answer

The user is already signed in to the app; asking again inside a web view would have been a visible seam. The app opens the URL with a token attached, and every request carries it through, so landing fresh on that page is already an authenticated session.

Question 8

Why resetting attempts on the first spin of a new day rather than a scheduled job resetting every user at midnight? (Spin the Wheel Feature)

Accepted Answer

A cron job means a fleet-wide write every night and a window where a user near the boundary sees the wrong count. Calculating the reset when they actually spin keeps it correct per user, needs no scheduler, and does no work for users who never come back.

Spin the Wheel Feature

The problem

The approach

Overview

Key decisions

What I built

The outcome

Stack