hemilabs / hemilabs/umami-analytics
loaded state is not reset when src/websiteId change after mount
- Dominant language
- TypeScript
- Stars
- 0
- Forks
- 0
- Avg merge
- 14h 48m
- Merged PRs (30d)
- 4
Description
### Context
Raised while reviewing #7, which reworks tracker script loading in `appendTrackerScript` (`src/utils.ts`) / `UmamiAnalyticsProvider` (`src/index.tsx`).
### Problem
The `loadTracker` effect in `UmamiAnalyticsProvider` depends on `[autoTrack, domainList, src, websiteId]`, so it re-runs when `src`/`websiteId` change after mount. But `loaded` (the state gating `useUmami()`) is only ever set to `true` by `onLoad`, never reset to `false` when the effect re-runs for a new `src`/`websiteId`.
Consequence: if `src` or `websiteId` change post-mount, `loaded` stays `true` from the previous script, so `useUmami()` immediately hands back a live track function while `window.umami` may still be mid-swap between the old and new tracker script — tracking can briefly use stale or incomplete config.
Note: the README documents that "changing any of the properties below after mount does not reconfigure a script that is already on the page," so this isn't officially a supported flow today. But the effect already reacts to these props (they're in the dependency array), so the fix mostly just makes `loaded` consistent with that existing reactivity, for close to no added complexity.
### Suggested fix
At the top of the `loadTracker` effect, call `setLoaded(false)` before the `if (!src || !websiteId)` check, so `loaded` is reset whenever the effect re-runs (including when `src`/`websiteId` become unset). On the initial mount this is a no-op (state is already `false`).
### Scope check
Worth confirming when picked up: is this worth fixing given `src`/`websiteId` are expected to be static app config in practice, or should the README's "not supported" caveat just be reinforced instead? Leaning toward the one-line fix since it's cheap and removes a real inconsistency.
Contributor guide
Research direction
Start in src/index.tsx at the loadTracker effect in UmamiAnalyticsProvider, and review how its [autoTrack, domainList, src, websiteId] dependencies interact with loaded and useUmami(). Done means loaded is reset whenever the effect reruns, including when src or websiteId become unset, before the existing guard; confirm the behavior against the surrounding provider logic.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- react, typescript
- Domain
- analytics, frontend
- Issue type
- Bug
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 88/100