One thing I'd lightly flag - the Go lib feels very...
# give-feedback
One thing I'd lightly flag - the Go lib feels very "non-Go-like" - there's no safe way to detect that feature/featuremap parsing has failed, as it always returns non-nil values from functions like
, and
- even if the input is totally invalid. Offering more of a typical Go interface would require breaking changes though. Would you be open to a PR around this?
It's also a little surprising that you don't just put json tags onto the feature structs, rather than having to manually iterate over maps to build the features - maybe there's a reason for that?
We're definitely open to PRs. I prefer maintaining backwards compatibility when possible, so maybe there's a way to just make new functions for parsing features that throw errors properly and deprecate the old ones.
It's kind of a difficult one because these APIs work in a super, super unusual way - there would be no common code between them on the parsing side (in order to maintain exactly the same behaviour anyway) So might be more sensible to release as a v2 module, then both remain independently available
Ok, I'm fine with a new major version instead then.
I'll have a peek at it when I get a chance 👌
Actually I guess one alternative is to just add the json tags and basically deprecate all the parsing/build methods - I don't think they should be necessary, as you could just do:
Copy code
var featureMap map[string]growthbook.Feature
json.Unmarshal(data, &featureMap)
Maybe would benefit from some minor extra thing to validate the final objects though