130 lines
4.3 KiB
Markdown
130 lines
4.3 KiB
Markdown
|
|
# 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
|
||
|
|
```javascript
|
||
|
|
// 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
|
||
|
|
```scss
|
||
|
|
// 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:
|
||
|
|
```bash
|
||
|
|
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.
|