feat: show api call status when adding insights to dashboards #9817
Conversation
There was a problem hiding this comment.
I normally use this as an example of an anti-pattern in the kea docs 🙃.
In the spirit of minimalism, at first sight, for sure at least the *Started events can be omitted, and the reducers can be set to true on the addToDashboard and removeFromDashboard events directly. Perhaps there's some other action that also always dispatches when the loading is done.
Also, what if there is more than one row? 🤔
|
disabled buttons rather than allow and track multiple API calls at the same time |
|
|
||
| return ( | ||
| <div style={style} className={clsx('modal-row', isHighlighted && 'highlighted')}> | ||
| <Link to={urls.dashboard(dashboard.id)}>{dashboard.name || 'Untitled'}</Link> | ||
| <LemonButton | ||
| type={isAlreadyOnDashboard ? 'primary' : 'secondary'} | ||
| loading={dashboardWithActiveAPICall === dashboard.id} | ||
| disabled={adding || removing} |
There was a problem hiding this comment.
Is it worth tracking these separately anymore?
| false, | ||
| { | ||
| removeFromDashboard: () => true, | ||
| reportRemovedInsightFromDashboard: () => false, |
There was a problem hiding this comment.
I don't know why, but this feels dirty somehow -> depending on some auxiliary reporting action to fire, and updating an internal state because of that. But I'm too tired to nit any more 🙃
| buttonLabel: [ | ||
| (s) => [s.adding, s.dashboardWithActiveAPICall], | ||
| (adding: boolean, dashboardWithActiveAPICall: number | null) => | ||
| (dashboardId: number, isAlreadyOnDashboard: boolean) => { | ||
| if (dashboardWithActiveAPICall === dashboardId) { | ||
| return adding ? 'Adding' : 'Removing' | ||
| } else { | ||
| return isAlreadyOnDashboard ? 'Added' : 'Add to dashboard' | ||
| } | ||
| }, | ||
| ], |
There was a problem hiding this comment.
Can't we derive whether the adding/removing action is being performed from isAlreadyOnDashboard?
|
on a fast network the changing label was an annoying brief flash... and on a slow network no better than the loading state... yanked it |
However, if I read the situation well, a |
😆 |
* master: refactor(ingestion): Make `KAFKA_ENABLED` true by default and set `KAFKA_HOSTS` default (#9844) feat(apps): transpile frontend.tsx (#9828) feat: show api call status when adding insights to dashboards (#9817) feat: track metrics on zapier hook firings (#9866) fix(onboarding): instrumentation (#9845) feat(whitelabel-shared-dashboard): Hide branding on shared dashboards paid (#9849) fix(apps): plugin source quickfix (#9862) refactor(plugin-server): Remove `ts-jest`, use `jest.mocked` (#9861) refactor(plugin-server): Trigger public jobs with graphile insted of celery queue (#9811) chore: upgrade pip tools (#9859) feat(apps): plugin source in its own model, part 2 (#9854) chore: Update sprint_planning_retro.md (#9791) feat(apps): plugin source in its own model, part 1 (#9853) feat(matrix): Add option to save `simulate_matrix` like `setup_dev` (#9836) fix(cohort): add mapping from event to person (#9841) feat(person-on-events): Enable CI to run using both old and new queries (#9814)
* show api call status when adding insights to dashboards * so the linter doesn't care about the PR name * homer-into-the-hedge.gif * don't track adding and removing separately * further into the hedge * respond to error as well * connect an action before using it
Problem
API calls are slower in production than local dev and the modal to add insights to dashboards gives no user feedback 🤦
Changes
Updates UI so the user knows what is happening
How did you test this code?
running it locally