Rambox: group your apps and keep their sign-ins clear
Rambox brings email, chat and other web apps into one desktop window. It helps people who switch between clients or work accounts organize apps in workspaces and separate accounts through sign-in profiles.
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.
How should inherited profiles and private sessions resolve?
Design a session-ownership resolver for a teaching model. Input includes a workspace map indexed by workspaceId and a set of valid profileIds. Each workspace has workspaceId and profileId. An app has appId, workspaceId and mode. The modes are inherit, private and custom; custom also supplies profileId. Output a sessionKey so the caller can tell which apps share a session. This is not a description of Rambox's implementation.
- Resolve inherit to the workspace's profileId and custom to the app's profileId. Private must be unique by appId. All apps must reference an existing workspace. Inherit must also reference a valid workspace profileId; custom validates its own profileId; private does not need a profile reference. Return an explicit error for a required missing reference, never a shared default session. IDs are case-sensitive, nonempty strings.
- Example: workspace W uses P; app a inherits, b explicitly uses P, and c is private. Which share? P and Q are both valid. Change W to Q and list ownership again. What happens if a new app d explicitly references P-missing, which is absent from the valid set?
- Deliver the rules, a key design that avoids collisions between ID types and a test table. Cover missing references, equal names with different IDs, two private apps, repeated calculation and profile changes.
Explore the reasoning
- Validate required references before resolving inheritance. Missing configurations must not fall into a shared default session. Workspace display names are not stable IDs. A nonempty custom P-missing must still produce an error; string validation alone is insufficient.
- Initially a and b resolve to P and share it; c has an app-specific key. After W changes to Q, a uses Q, b retains P and c stays unchanged.
- Give shared profiles and private apps different key types. Identical profileId and appId text must not collide. Explain the tradeoffs of a structured pair or unambiguous encoding without providing a full implementation.
- Test individual resolutions and invalidation of stale cached results after changes. Resolution returns ownership; it does not migrate cookies or guarantee sign-in across websites.
How can a reload confirmation keep settings consistent?
Design the Profile interaction in an app's settings page. It initially shows saved profile P. Choosing Q requires confirmation of a reload; only a successful save makes Q the saved value. This is a simulated interaction, with no real Rambox account required. The simulated service delivers final receipts over an event channel with requestId, value and success/failure. A receipt may arrive more than once, always with the same result. The first final receipt settles the request; later receipts with that ID are duplicates.
- Separate saved value, edited value and submission state. Canceling confirmation restores the original display and sends no save. Prevent duplicate submission while a request is pending, but explain its status.
- Walk through “choose Q → cancel,” “choose Q → confirm → save fails” and “request q saves Q successfully → request r fails to save R → q's success receipt arrives again.” Accept only the first final receipt for the currently valid submission. In the last case, retain saved Q, edited R ready for retry, and r's error message.
- Deliver a state sketch, keyboard and focus behavior for the confirmation dialog, success/failure messages and an asynchronous response test table. Do not provide complete component code.
Explore the reasoning
- Keep edited and saved values separate. Selecting Q changes only the edited value; other areas should not claim that the change is already saved before confirmation.
- Cancel restores edited P and returns focus to the profile control. Explain the reload and possible new sign-in in the dialog, with both choices reachable by keyboard.
- On failure, retain the last successfully saved value before that submission and allow an explicit retry. If the first Q submission fails, keep P; if Q succeeded and R then fails, keep Q. Reject duplicate or stale receipts using request identity and settlement state, rather than the dropdown text alone.
- Give success, failure and waiting readable feedback. Control delivery order. In the q-success, r-failure, q-duplicate sequence, verify saved Q, edited R and r's error all remain. This tests UI consistency, not whether login data was safely migrated.