#Query builder patterns for nullable fields
1 messages · Page 1 of 1 (latest)
I was having trouble following this so took the liberty of creating a thread @ruby ore @dry siren 🙂
I was wondering about this a while back (when writing my fantasy go DX) and the LLB pattern seemed the most natural
After all we're using the llb pattern for chaining too...
yeah, so I think the LLB pattern is great from a code readability standpoint, my only complaint is sometimes it's hard to discover the available options. having LSP completion helps a lot since it can infer that you're trying to call a method with a e.g. RunOption return type, but it's not as simple as just setting fields on a struct.
having said all that, I still think it's probably the best choice. having to always pass in a nil options struct or nil for every optional parameter would be kind of clunky.
it's also nice that Go docs group them together properly: https://pkg.go.dev/github.com/moby/buildkit@v0.10.4/client/llb#RunOption (particularly in the big function list up top, which I can't deep-link to)
I've had that experience getting lost in the llb go docs
Maybe the pattern could be refined? For example instead of:
Directory(DirectoryID("foo"))
We could do:
Directory(DirectoryOpts().WithID("foo"))
meh
Actually why is a struct not viable? Because of string pointers being weird?
a struct would be simple and really not that bad. you mean like .Directory(&DirectoryOpts{ID: "foo"})? and .Directory(nil)? I think the GitHub API works that way.
the only downside imo is having the nil (or worse, DirectoryOpts{}) but that's really not a big deal. and maybe we could make it a sneaky variadic arg