Root cause: themeStyle was on .container only, but modals (picker,
day-detail) were siblings of .container in the WXML tree. CSS custom
properties set via inline style on .container don't cascade to
sibling elements — those elements fall back to app.wxss page-level
defaults (always orange). Users saw modal buttons in orange and
concluded the whole page didn't follow theme.
Fixes:
- index.wxml: Move picker modal inside .container so it inherits
themeStyle CSS variables (position:fixed is viewport-relative,
so nesting doesn't affect modal positioning)
- index.js, records.js: Add applyThemeToPage in onLoad alongside
onShow, preventing a flash of default orange before onShow fires
- timer.js: Add onShow with applyThemeToPage as lifecycle safety
net; extract _init from onLoad for clean separation
Bug 1 (critical): setTheme lacked try/catch around wx.setStorageSync.
If storage write throws (full / permission), the theme silently
fails to persist but UI has already changed → on next cold start
getCurrentTheme falls back to orange.
→ Wrap in try/catch; still apply UI change even if storage fails
(better to see the right color now than revert immediately).
Bug 2 (display): settings onShow called applyThemeToPage (updates
'theme' object) but never refreshed 'currentThemeId'. After tab
switching, the radio highlight showed the wrong theme.
→ Add setData({ currentThemeId }) in onShow.
Redundancy: theme now also saved as themeId in user_settings.
getCurrentTheme falls back to user_settings.themeId if app_theme
key is unexpectedly missing, providing a recovery path.
- var→const/let, function→arrow/class across all 13 JS files
- Timer: prototype→class with ES6 getters
- plan days: IIFE→Array.from declarative generation
- storage/plan: unified formatDate via util.js
- Bugfix: getPlanDay now filters by planId (plan switch accuracy)
- Bugfix: getTodayRecord searches all months (cross-month boundary)
- WXML/WXSS unchanged; public API unchanged
lc