Design Raw and Computed Spreadsheet Views

Design a spreadsheet object model that can display both a cell's raw content and its computed value. A raw value may be a literal or a formula; changing a cell from one kind to the other must correctly update dependencies and cached values. ### Constraints & Assumptions - Preserve the user's raw expression for editing, separately from the parsed expression and computed result. - Dependent cells must reflect changes to their inputs, including formula-to-literal and literal-to-formula replacements. - This is an object/API design exercise. Choose and state a formula grammar and error policy only as needed to illustrate the design; the report does not give a complete callable contract. - Begin with one writer and an in-memory sheet. Persistence, undo/redo, and concurrent editing are possible extensions, not assumed product requirements. ### Clarifying Questions to Ask - Should `getRaw` preserve exact user formatting or a normalized expression? - Should an invalid or cyclic edit be rejected, or stored and shown with a computed error? - Do reads need to be constant time, or can values be evaluated lazily? ```hint Treat an edit as a dependency change Replacing a formula can remove edges as well as add them. A cached numeric result alone cannot tell you which old dependencies must be detached. ``` ### What a Strong Answer Covers - Separate raw, parsed, computed, and error representations. - An atomic edit path that updates forward and reverse dependency edges consistently. - Correct invalidation when a formula becomes a literal or the reverse. - APIs that keep edit views and value views consistent without discarding the raw input. - Tests that expose stale dependencies, cycles, and transitive updates. ### Follow-up Questions - How would undo/redo restore the raw value and derived graph state safely? - What must change if a client reads several cells while another client edits the sheet?