Wx_WxCheck_Prod/openspec/changes/fix-frontend-issues/implementation.md

Fix Frontend Issues - Implementation Details

1. Theme Store Initialization Order Fix

Problem

The application encountered a ReferenceError: Cannot access 'themeStore' before initialization error. This occurred because:

1. The themeStore was being used in Element Plus configuration
2. But Pinia was not yet initialized when the themeStore was accessed

Solution

Reorder the initialization sequence in main.js to:

1. Initialize Pinia first
2. Then use the themeStore
3. Finally configure Element Plus with the themeStore value

Code Changes

// Before (incorrect)
app.use(ElementPlus, {
  locale: zhCn,
  dark: themeStore.isDark // ❌ themeStore not initialized yet
})
app.use(pinia)
const themeStore = useThemeStore()

// After (correct)
app.use(pinia) // ✅ Initialize Pinia first
const themeStore = useThemeStore() // ✅ Then create store instance
themeStore.initTheme() // ✅ Initialize theme
app.use(ElementPlus, {
  locale: zhCn,
  dark: themeStore.isDark // ✅ Now themeStore is properly initialized
})

Best Practice

Always initialize Pinia before using any stores. The correct initialization order for Vue applications is:

1. Create Vue app instance
2. Initialize Pinia (if using)
3. Initialize any stores needed for configuration
4. Configure plugins (like Element Plus) with store values
5. Initialize Vue Router
6. Mount the app

2. Sass @import Deprecation Warnings Fix

Problem

Sass @import rules are deprecated and will be removed in Dart Sass 3.0.0. The build process was showing warning messages:

Deprecation Warning [import]: Sass @import rules are deprecated and will be removed in Dart Sass 3.0.0.

Solution

Replace all @import rules with @use rules in SCSS files. The @use rule is the recommended way to include Sass files in modern Sass.

Code Changes

// Before (deprecated)
@import './variables.scss';
@import './responsive.scss';

// After (recommended)
@use './variables.scss' as *;
@use './responsive.scss' as *;

Best Practice

• Always use @use instead of @import for including Sass files
• Use as * to import all variables, mixins, and functions into the current scope
• Important: Each file must explicitly import the variables it uses. Variables are not automatically shared between files when using @use
• For larger projects, consider using namespace imports to avoid naming conflicts
• Example: If responsive.scss uses variables from variables.scss, it must include @use './variables.scss' as * at the top

3. Additional Frontend Best Practices

Store Management

• Always initialize Pinia before using any stores
• Keep store initialization separate from plugin configuration
• Use descriptive names for store actions and mutations

SCSS/Sass

• Use @use instead of @import for including Sass files
• Define variables in a central location (like variables.scss)
• Use descriptive names for variables and mixins
• Organize SCSS files by functionality (variables, mixins, components, etc.)

Plugin Configuration

• Configure plugins after all dependencies are initialized
• Use store values for plugin configuration only after stores are initialized
• Keep plugin configuration minimal and focused

Build Process

• Always run npm run build to verify no warnings or errors before committing
• Fix all deprecation warnings promptly
• Monitor build output for new issues

4. Verification

Build Verification

Run npm run build to verify that no warnings or errors appear during the build process:

npm run build

Expected output should show no deprecation warnings:

vite v7.3.0 building client environment for production...
✓ 1515 modules transformed.
dist/index.html                                0.46 kB │ gzip:   0.29 kB
...

Functionality Verification

1. Start the development server: npm run dev
2. Access the application at http://localhost:5173
3. Verify that:
   • No console errors appear in the browser
   • Theme switching works correctly
   • All pages load properly
   • API calls function correctly

5. Conclusion

By following these best practices, we can ensure that our frontend applications are:

• More maintainable
• Less error-prone
• Compatible with future versions of dependencies
• Free of deprecation warnings

These changes will help us build better frontend applications and avoid common pitfalls in future development.