Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(hono/client): Simplified Path Parameters Syntax for hc() #3968

Open
zohayrslileh opened this issue Mar 1, 2025 · 0 comments
Open

feat(hono/client): Simplified Path Parameters Syntax for hc() #3968

zohayrslileh opened this issue Mar 1, 2025 · 0 comments
Labels
enhancement New feature or request.

Comments

@zohayrslileh
Copy link

What is the feature you are proposing?

🚀 Enhanced hono/client API: Simplified Path Parameters

Summary

Propose a more intuitive and concise syntax for handling path parameters in the Hono Client (hc).

Current vs Proposed Syntax

Current Usage

// Current syntax requires explicit param mapping
const response = await hc<AppType>('/api')
  .users[':id']
  .$get({ param: { id: '123' } })

// Multiple parameters are verbose
const response = await hc<AppType>('/api')
  .users[':userId']
  .posts[':postId']
  .$get({ 
    param: { 
      userId: '123', 
      postId: '456' 
    } 
  })

Proposed Usage

// Direct value in path segment
const response = await hc<AppType>('/api')
  .users['123']
  .$get()

// Multiple parameters are cleaner
const response = await hc<AppType>('/api')
  .users['123']
  .posts['456']
  .$get()

Benefits

  1. Improved Developer Experience

    • More intuitive API design
    • Less boilerplate code
    • Reduced chance of parameter mapping errors
  2. Better Code Readability

    • Path structure directly reflects the URL
    • Clearer intention in the code
    • Easier to maintain and review
  3. Type Safety

    • Maintains full TypeScript support
    • Parameter types can be inferred from the route definition

Implementation Considerations

  1. Proxy Handler Updates

    • Modify the proxy to detect parameter values in path segments
    • Automatically generate the params object
    • Preserve existing functionality for backward compatibility
  2. Type System

    • Enhance type definitions to support both styles
    • Ensure proper type inference for path parameters
  3. Documentation

    • Update documentation to reflect the new syntax

Backward Compatibility

The current syntax would be maintained for backward compatibility, allowing gradual adoption of the new syntax.

Examples

REST API Calls

// Get user
await hc<AppType>('/api').users['123'].$get()

// Create post for user
await hc<AppType>('/api').users['123'].posts.$post({
  json: { title: 'Hello' }
})

// Update specific post
await hc<AppType>('/api').users['123'].posts['456'].$put({
  json: { title: 'Updated' }
})

Query Parameters

// Still supports query parameters
await hc<AppType>('/api').users['123'].$get({
  query: { include: 'posts' }
})

WebSocket Connections

// WebSocket with path parameters
const ws = hc<AppType>('/api').users['123'].live.$ws()

Discussion Points

  1. Should we consider any additional syntax improvements?
  2. Are there edge cases we need to address?
  3. How should we handle validation of parameter values?
@zohayrslileh zohayrslileh added the enhancement New feature or request. label Mar 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request.
Projects
None yet
Development

No branches or pull requests

1 participant