这是indexloc提供的服务,不要输入任何密码
Skip to content

Conversation

@lsdch
Copy link
Contributor

@lsdch lsdch commented Feb 10, 2025

Hi!

I need a way to handle null values in query parameters (and apparently I am not the only one #438 🙂 ) so here is a PR that gives the possibility to wrap query parameter fields with custom types.

It relies on implementing the ParamWrapper interface, which exposes as a reflect.Value the internal field that we want to use when parsing request parameters.
ParamReactor (bad name, I know 🙈 ) is another interface that can be implemented to specify a callback when a request parameter was parsed into our custom type.

type ParamWrapper interface {
	Receiver() reflect.Value
}

type ParamReactor interface {
	OnParamSet(isSet bool, parsed any)
}

Example usage:

type OptionalParam[T any] struct {
	Value T
	IsSet bool
}

// Define schema to use wrapped type
func (o OptionalParam[T]) Schema(r huma.Registry) *huma.Schema {
	return huma.SchemaFromType(r, reflect.TypeOf(o.Value))
}

// Expose wrapped value to receive parsed value from Huma
// MUST have pointer receiver
func (o *OptionalParam[T]) Receiver() reflect.Value {
	return reflect.ValueOf(o).Elem().Field(0)
}

// React to request param being parsed to update internal state
// MUST have pointer receiver
func (o *OptionalParam[T]) OnParamSet(isSet bool, parsed any) {
	o.IsSet = isSet
}

I believe it resolves validation issues we had with #438, but there might be other caveats I am not aware of. Also I am not 100% convinced with the proposed API, what do you think ?

@codecov
Copy link

codecov bot commented Feb 10, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.78%. Comparing base (f9ffb6a) to head (a928ac2).
Report is 7 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #722      +/-   ##
==========================================
- Coverage   92.79%   92.78%   -0.02%     
==========================================
  Files          22       22              
  Lines        5027     5061      +34     
==========================================
+ Hits         4665     4696      +31     
- Misses        312      314       +2     
- Partials       50       51       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Owner

@danielgtaylor danielgtaylor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lsdch nice idea! I think this looks good, just left one comment for how we can precompute the underlying type so we don't modify the param definition in an unsafe way.

huma.go Outdated
receiver = f.Addr().Interface().(ParamWrapper).Receiver()
// Feels like a hack, but we need to override the type of the wrapper from the cache
// There might a be a better way
p.Type = receiver.Type()
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect we want to find the right type in findParams at https://github.com/danielgtaylor/huma/blob/main/huma.go#L102 by calling Receiver() once on a dummy value, then we don't have to do this check/swap on each request.

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (1)

huma.go:699

  • [nitpick] The variable name 'receiver' is ambiguous. It should be renamed to 'wrappedValue' or 'paramValue' for better clarity.
var receiver = f

@lsdch lsdch force-pushed the custom-query-types branch from 4bbd9f3 to 297fc17 Compare February 13, 2025 14:03
@lsdch
Copy link
Contributor Author

lsdch commented Feb 13, 2025

Thanks for the feedback @danielgtaylor ! And for the pointer to fix the type precomputation, feels way better now 🙂

edit: not sure how we get a test coverage regression here 🤔

@danielgtaylor danielgtaylor merged commit 151aa1e into danielgtaylor:main Feb 15, 2025
4 of 5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants