meteor3: react-meteor-data 0.2.16 -> 3.0.6 (fixes blank fire-detail pages)
0.2.16 (React-15/16-era withTracker) looped forever on fire-detail pages under React 18: the withTracker subscription never reached ready() so the page stayed blank and pegged a CPU core. Publications were already correct (subscribing standalone from the console readied instantly). 3.0.6 (the React-18 line for Meteor 3.1) fixes it with zero call-site changes. Also drops tmeasday:check-npm-versions (the constraint that pinned 0.2.16). Browser-verified at /fire/archive/<id>: full render (map, NASA/satellite, FalsePositives widget, Comments box), zero console errors. REST smoke byte-identical (12/12).
This commit is contained in:
parent
efa1e30bcb
commit
696789e2b1
3 changed files with 29 additions and 28 deletions
|
|
@ -15,7 +15,7 @@ standard-minifier-js@3.0.0 # JS minifier run for production mode
|
|||
ecmascript@0.16.10 # Enable ECMAScript2015+ syntax in app code
|
||||
shell-server@0.6.1 # Server-side component of the `meteor shell` command
|
||||
|
||||
react-meteor-data
|
||||
react-meteor-data@3.0.6
|
||||
fourseven:scss@5.0.0
|
||||
accounts-base@3.0.3
|
||||
accounts-password@3.0.3
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ raix:eventemitter@1.0.0
|
|||
random@1.2.2
|
||||
rate-limit@1.1.2
|
||||
react-fast-refresh@0.2.9
|
||||
react-meteor-data@0.2.16
|
||||
react-meteor-data@3.0.6
|
||||
reactive-var@1.0.13
|
||||
reload@1.3.2
|
||||
retry@1.1.1
|
||||
|
|
@ -112,7 +112,6 @@ templating-compiler@2.0.1
|
|||
templating-runtime@2.0.2
|
||||
templating-tools@2.0.1
|
||||
themeteorchef:bert@1.1.0
|
||||
tmeasday:check-npm-versions@0.3.2
|
||||
tracker@1.3.4
|
||||
typescript@5.6.3
|
||||
underscore@1.6.4
|
||||
|
|
|
|||
52
UPGRADE.md
52
UPGRADE.md
|
|
@ -307,7 +307,7 @@ MONGO_CONTAINER=tcef-mongo7 MONGO_SHELL=mongosh MONGO_PORT=27019 ./smoke/smoke.s
|
|||
| raven / flowkey:raven | 2.4 | @sentry/node + @sentry/browser 8.x | ✅ done — `flowkey:raven` (Sentry legacy SDK, dead on 3.x, spammed the boot log with 502s against the dead sentry.comunes.org) replaced by the modern SDKs behind the same `ravenLogger.log()` facade (6 call sites unchanged). Backend: **GlitchTip** self-hosted on `aaron` (Sentry-compatible DSN/API; Sentry proper needs 16 GB RAM, didn't fit), deployed via the Comunes ansible (`glitchtip.yml`, org "comunes" / project "tcef-web"), fronted at `https://sentry.comunes.org` (nginx on `assange` → `aaron:8000`). DSN set in `settings-development.json`; end-to-end verified (a test exception sent from the dev server showed up in GlitchTip within seconds). |
|
||||
| nodemailer | 4 | 6.10 | ✅ done — drop-in for our usage: `email.js` only calls `nodemailer.createTransport(MAIL_URL)` and reads `transport.options.auth.user` (in the production-only `from()` branch); both verified unchanged in v6. Sending goes through `ostrio:mailer` (MailTime 2.5), which is v6-compatible. |
|
||||
| Babel | 7 beta | 7 stable | ✅ done (escala 1) |
|
||||
| react-meteor-data | 0.2.16 | 2.x (useTracker) | ⚠️ debt — 0.2.16 is React-15/16-era; on React 18 its `withTracker` loops on the fire-detail pages (never-ready → blank). See "Known bug" above. Upgrade needed to fix fire-detail + Comments. |
|
||||
| react-meteor-data | 0.2.16 | 3.0.6 | ✅ done — 0.2.16 (React-15/16-era) looped `withTracker` on fire-detail pages under React 18 (never-ready → blank). `meteor add react-meteor-data@3.0.6`; no call-site changes (HOC API kept). Also dropped `tmeasday:check-npm-versions` (the constraint pinning 0.2.16). See section above. |
|
||||
| i18next | 10 | current | debt — pin; not on the critical path |
|
||||
| Leaflet | 1.3.1 | current | debt — pin; not on the critical path |
|
||||
| arkham:comments-ui | 1.4.x | — | ✅ replaced with in-repo React feature |
|
||||
|
|
@ -325,30 +325,32 @@ compiles, but the comments UI itself is **not exercised by the smoke test**
|
|||
verification: on a fire archive page — logged-in post/edit/remove, like/dislike,
|
||||
and image/YouTube embed.
|
||||
|
||||
### ⚠️ Known bug: fire-detail pages don't render (blocks the Comments check)
|
||||
### ✅ Fixed: fire-detail pages now render (react-meteor-data 0.2.16 → 3.0.6)
|
||||
|
||||
Browser-verifying the above surfaced a **pre-existing client bug**: the
|
||||
fire-detail pages (`/fire/{active,archive,alert}/:id`, component
|
||||
`imports/ui/pages/Fires/Fires.js`) stay blank — the page's `withTracker`
|
||||
subscription (`fireFromActiveId` / `fireFromId`) never reaches `ready()`, so
|
||||
`loading` stays true and nothing renders. It pegs a CPU core (re-subscribe
|
||||
loop). Since the Comments box only mounts once a fire renders, the Comments
|
||||
feature can't be verified until this is fixed.
|
||||
Browser-verifying the Comments feature surfaced a **pre-existing client bug**:
|
||||
the fire-detail pages (`/fire/{active,archive,alert}/:id`, component
|
||||
`imports/ui/pages/Fires/Fires.js`) stayed blank — the page's `withTracker`
|
||||
subscription (`fireFromActiveId` / `fireFromId`) never reached `ready()`, so
|
||||
`loading` stayed true and nothing rendered, pegging a CPU core in a
|
||||
re-subscribe loop.
|
||||
|
||||
Diagnosis (isolated, not guessed):
|
||||
- **The publications are fine.** Subscribing to `fireFromActiveId` /
|
||||
`fireFromId` *standalone* from the browser console (`Meteor.subscribe(...)`,
|
||||
outside the page) readies immediately and delivers the doc. So the async
|
||||
publications are correct — this is **not** a server/publication bug.
|
||||
- **The bug is client-side**, in the `Fire` component's `react-meteor-data`
|
||||
`withTracker`: in the page context it re-subscribes in a tight loop and never
|
||||
stabilizes to ready. Prime suspect: **`react-meteor-data@0.2.16`** — an
|
||||
ancient version (React-15/16 era, `componentWillMount` + legacy context;
|
||||
these are the deprecation warnings flooding the console) that misbehaves under
|
||||
React 18 for a component that gates its whole render on
|
||||
`subscription.ready()`.
|
||||
- Likely fix: upgrade `react-meteor-data` to a React-18-compatible release
|
||||
(2.x, `useTracker`), which may need touching the `withTracker` call sites.
|
||||
Tracked as debt below; not yet done.
|
||||
- Note: `/` and `/fires` (which also use `withTracker` but don't gate render on
|
||||
`ready()`) render fine — so the app is usable, but fire-detail pages are not.
|
||||
- **The publications were fine.** Subscribing to `fireFromActiveId` /
|
||||
`fireFromId` *standalone* from the browser console readied immediately and
|
||||
delivered the doc — not a server/publication bug.
|
||||
- **The bug was `react-meteor-data@0.2.16`** — a React-15/16-era version
|
||||
(`componentWillMount` + legacy context, the source of the deprecation
|
||||
warnings flooding the console) that misbehaves under React 18 for a component
|
||||
gating its whole render on `subscription.ready()`.
|
||||
|
||||
Fix: **`meteor add react-meteor-data@3.0.6`** (the React-18-compatible line for
|
||||
Meteor 3.1; 4.x targets Meteor 3.2+). No call-site changes were needed — 3.x
|
||||
keeps the `withTracker` HOC API, and all 19 call sites work unchanged. The old
|
||||
constraint that pinned 0.2.16 was **`tmeasday:check-npm-versions`**, pulled in
|
||||
by 0.2.16 itself; the upgrade dropped it, which also silenced the
|
||||
"npm peer requirements not installed (react@15-16)" boot/console warning.
|
||||
|
||||
Verified in a real browser at `/fire/archive/c0000000000000000000000c`: the
|
||||
page renders fully (title, Leaflet + NASA/satellite map, the "not a wildfire"
|
||||
FalsePositives widget, and the **Comments** box — all `withTracker`-driven),
|
||||
zero console errors. REST smoke byte-identical (12/12).
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue