Félix Malfait
840c6d0129
Stacked on #23424 (mobile chip navigation). Review that one first; the diff shown here is only the delta. ## Problem `recordIndexOpenRecordInState` was a global atom mirroring `view.openRecordIn`. It was written whenever any index view loaded and never reset, so a record chip behaved according to whichever view had been browsed last: - Companies view set to "record page". Open a Company, tap a related Opportunity chip. The Opportunities view says "side panel", but the chip reads the leftover Companies setting and opens a full page. - Visit the Opportunities index first, then the same Company page, and that same chip now opens a side panel. The setting is per view in the database, but the frontend kept it in one slot as though it were a user preference. ## Approach The value already lives on the view, so the mirror is deleted rather than scoped: - `useResolveOpenRecordIn` reads the current view of the surrounding context store. On a record index that is the view being displayed. On a record show page `MainContextStoreProvider` resolves a view for the object in the URL — the last visited view for that object, falling back to its index view — so chips there follow a view belonging to the object they sit on, rather than whatever was loaded last. - Where no context store is mounted at all (a mention inside a note, for instance) there is no view to take a setting from, so the hook falls back to `DEFAULT_VIEW_OPEN_RECORD_IN`. The instance lookup is non-throwing on purpose: `RecordChip` renders in a lot of places, and an existing test caught this crashing when the read was strict. - The options dropdown now reads and writes `currentView.openRecordIn` directly, the same way `isCompact` beside it already works, so `setAndPersistOpenRecordIn` only has to persist. - `useGetOpenRecordIn` is gone; every call site had the object name available at render, so the reactive hook covers all of them. ## Behaviour change A chip whose behaviour previously came from an unrelated view now follows the view in scope. That is the point of the change, but it does mean some chips will open somewhere different from before, always in the direction of "what this list is configured to do" rather than "what the last list was configured to do". ## Testing - New `useResolveOpenRecordIn` tests: falls back to the default with no context store, follows the context store's view when there is one. - Full frontend suite: 951 suites, 5598 tests passing. Typecheck and lint clean. - Not exercised in a running app: no database in this environment. The dropdown's optimistic behaviour in particular relies on the same view store refresh that `isCompact` already depends on, so it is worth a click-through before merge.
Run yarn dev while server running on port 3000