refactor(customer-analytics): remove REST endpoint tab from accounts#60717
Conversation
|
Size Change: -7.81 kB (-0.01%) Total Size: 80.8 MB 📦 View Changed
ℹ️ View Unchanged
|
|
|
✅ Visual changes approved by @arthurdedeus — baseline updated in 10 changed. |
83c025d to
0ab32f1
Compare
Backend API is preserved; the UI now renders the HogQL table directly. Role updates fetch the current account before patching to keep merged properties intact. Generated-By: PostHog Code Task-Id: 3f8b5bcc-1e21-4127-9113-32a0f65353c1
10 updated Run: 408bc974-76b7-4290-8689-df0c9cae382f Co-authored-by: arthurdedeus <54866778+arthurdedeus@users.noreply.github.com>
6647299 to
8028db9
Compare
Problem
No need to keep both, as the HogQL is capable of doing the same and more.
Changes
REST endpointtab and related componentsHow did you test this code?
Unit tests, refactored snapshot tests to assert the HogQL version and manual tests in the UI.
Automatic notifications
Docs update
🤖 Agent context
Authored by PostHog Code (Claude Opus 4.7). Considered two designs for keeping the role update flow correct without the REST loader:
propertiesobject through from the HogQL row. Rejected because the HogQL select only includes the visible columns, so non-displayed properties (stripe_customer_id, etc.) would be silently wiped on PATCH.accountsRetrievethen PATCH the merged properties. Chosen — costs one extra GET per role change but keeps the merge correct against any future property additions without coupling the UI to the column selection.Dropped optimistic UI updates with that change; the saving spinner on the role cell covers the in-flight window.
accountOverridesis still used to reflect the PATCH response so the cell updates without waiting for the HogQL refetch to come back.Decided not to delete
AccountsTab.stories.tsxeven though it was originally REST-mock-driven — the user pushed back on dropping it. Rewrote the mocks to dispatch onquery.kindso the HogQL table renders against deterministic rows.Created with PostHog Code