aioff.
中文
Product design
PRODUCT DESIGN·5 min

Spotify Jam: choose songs together and know who can skip

Spotify provides music and other audio, while Jam lets friends join a shared listening session. Everyone can add songs from their own device, and the host manages the shared queue and playback permissions.

Break down the problem and try your own design and implementation first. Then explore the reasoning to check states, edge cases, trade-offs, and ways to test your approach. The guide offers a reasoning path, not a complete implementation.

01
CODE EXERCISE

Share one action-permission policy across a player

Suppose you are building a party music player. Button visibility and action handling must use the same permission policy, so a visible button does not offer an action that its handler rejects. Implement the small canPerform(session, role, action) module.

  1. Inputs: session is the shared-listening session. Its Boolean active says whether it is running, and guestsCanSkip says whether guests may skip tracks. role is host or guest. action is add (add a song), skip (move to the next track), or end (end the session). Inputs are guaranteed to use these types.
  2. Rules: If active=false, deny every action with {allowed:false,reason:"inactive"}. In an active session, hosts may perform all three actions. Guests may always add, may skip only when guestsCanSkip=true, and may never end the session. Other denials return {allowed:false,reason:"not-permitted"}; allowed actions return {allowed:true}. Do not change the session or play audio.
  3. Check: With active=true and guestsCanSkip=false, guest/add is allowed and guest/skip is denied. After changing guestsCanSkip to true, guest/skip is allowed but guest/end remains denied. With active=false, even host/end must return inactive.
  4. Deliver: Submit the policy module, a short calling example in which button visibility and the check before handling a click share the function, and the local verification results above. A complete player is not required.
Explore the reasoning

  1. Put the conditions every caller must follow behind one entry point, rather than keeping separate rules in buttons and handlers.

  2. Check whether the session is active before considering role and action. Use the inactive-host case to verify which reason takes priority.

  3. Repeat the guest cases after changing guestsCanSkip. Confirm that only the specified ability changes and ending the session does not become allowed.