12451 b553c4e519 feat: API 统一 + 设备详情补全 + H5 导航优化
- API 路由统一: 移除 /api/h5/,统一 /api/pms/ 入口
- 二进制改名: api-server -> pms-api(与服务名一致)
- nginx: 合并 /api/ + /pms/api/ 为 /api/pms/
- 新增 docs/API.md 接口文档
- 后端: CabinetDetail 增加 rssi/pow_fail/address/soc 等字段
- Redis 管道批量读取仓体实时数据(SOC/电压/电流/功率)
- DB: 所有 TIMESTAMP 列改为 DATETIME(修复类型不匹配)
- 用户管理: 新增创建时间/修改时间列,状态改用 Switch
- 角色管理/用户管理: 操作按钮改为图标
- PC 设备详情: 基本信息补全 RSSI/ICCID/电源/地址
- PC 卡片: 通道统计改用 Lucide 图标,颜色统一
- PC 二维码: canvas 渲染,含编号文字,支持右键下载
- H5: 按 uni-app 规范修正导航(navigateTo 替代 reLaunch)
- H5: 详情页加返回导航条
- H5: 扫码支持摄像头(jsQR)+ ?id= 参数
- H5: 底部 tabBar 在所有页面常显
- H5: 首页统计改为 6 项(设备/通道/空闲/充电/充满/故障)
- H5: 下拉刷新 / 上拉加载
- 产品首页: 添加业务联系
- 文档: 清理过时文件,补充缺失规范章节
2026-07-04 04:03:02 +08:00

5.1 KiB

title, impact, impactDescription, type, tags
title impact impactDescription type tags
Use Options Object Pattern for Composable Parameters MEDIUM Long parameter lists are error-prone and unclear; options objects are self-documenting and extensible best-practice
vue3
composables
composition-api
api-design
typescript
patterns

Use Options Object Pattern for Composable Parameters

Impact: MEDIUM - When a composable accepts multiple parameters (especially optional ones), use an options object instead of positional arguments. This makes the API self-documenting, prevents argument order mistakes, and allows easy extension without breaking changes.

Task Checklist

  • Use options object when composable has more than 2-3 parameters
  • Always use options object when most parameters are optional
  • Provide sensible defaults via destructuring
  • Type the options object for better IDE support
  • Required parameters can be positional; optional ones in options

Incorrect:

// WRONG: Many positional parameters - unclear and error-prone
export function useFetch(url, method, headers, timeout, retries, onError) {
  // What was the 4th parameter again?
}

// Usage - which boolean is which?
const { data } = useFetch('/api/users', 'GET', null, 5000, 3, handleError)

// WRONG: Easy to get order wrong
export function useDebounce(value, delay, immediate, maxWait) {
  // ...
}

// Is 500 the delay or maxWait? Is true immediate?
const debounced = useDebounce(searchQuery, 500, true, 1000)

Correct:

// CORRECT: Options object pattern
export function useFetch(url, options = {}) {
  const {
    method = 'GET',
    headers = {},
    timeout = 30000,
    retries = 0,
    onError = null,
    immediate = true
  } = options

  // Implementation...
}

// Usage - clear and self-documenting
const { data } = useFetch('/api/users', {
  method: 'POST',
  timeout: 5000,
  retries: 3,
  onError: handleError
})

// CORRECT: With TypeScript for better IDE support
interface UseFetchOptions {
  method?: 'GET' | 'POST' | 'PUT' | 'DELETE'
  headers?: Record<string, string>
  timeout?: number
  retries?: number
  onError?: (error: Error) => void
  immediate?: boolean
}

export function useFetch(url: MaybeRefOrGetter<string>, options: UseFetchOptions = {}) {
  const {
    method = 'GET',
    headers = {},
    timeout = 30000,
    retries = 0,
    onError = null,
    immediate = true
  } = options

  // TypeScript now provides autocomplete for options
}

Pattern: Required + Options

Keep truly required parameters positional, bundle optional ones:

// url is always required, options are not
export function useFetch(url, options = {}) {
  // ...
}

// Both key and storage are required for this to make sense
export function useStorage(key, storage, options = {}) {
  const { serializer = JSON, deep = true } = options
  // ...
}

// Usage
useStorage('user-prefs', localStorage, { deep: false })

Pattern: Reactive Options

Options can also be reactive for dynamic behavior:

export function useFetch(url, options = {}) {
  const {
    refetch = ref(true),  // Can be a ref!
    interval = null
  } = options

  watchEffect(() => {
    if (toValue(refetch)) {
      // Perform fetch
    }
  })
}

// Usage with reactive option
const shouldFetch = ref(true)
const { data } = useFetch('/api/data', { refetch: shouldFetch })

// Later, disable fetching
shouldFetch.value = false

Pattern: Returning Configuration

Options objects also work well for return values:

export function useCounter(options = {}) {
  const { initial = 0, min = -Infinity, max = Infinity, step = 1 } = options

  const count = ref(initial)

  function increment() {
    count.value = Math.min(count.value + step, max)
  }

  function decrement() {
    count.value = Math.max(count.value - step, min)
  }

  function set(value) {
    count.value = Math.min(Math.max(value, min), max)
  }

  return { count, increment, decrement, set }
}

// Clear, readable usage
const { count, increment, decrement } = useCounter({
  initial: 10,
  min: 0,
  max: 100,
  step: 5
})

VueUse Convention

VueUse uses this pattern extensively:

import { useDebounceFn, useThrottleFn, useLocalStorage } from '@vueuse/core'

// All use options objects
const debouncedFn = useDebounceFn(fn, 1000, { maxWait: 5000 })

const throttledFn = useThrottleFn(fn, 1000, { trailing: true, leading: false })

const state = useLocalStorage('key', defaultValue, {
  deep: true,
  listenToStorageChanges: true,
  serializer: {
    read: JSON.parse,
    write: JSON.stringify
  }
})

Anti-pattern: Boolean Trap

Options objects prevent the "boolean trap":

// BAD: What do these booleans mean?
useModal(true, false, true)

// GOOD: Self-documenting
useModal({
  closable: true,
  backdrop: false,
  keyboard: true
})

Reference