Add Entitlement and EntitlementValueType #16
Conversation
dontlaugh
force-pushed
the
new-types-schy-9
branch
from
0863857 to
3a0807e
Compare
dontlaugh
force-pushed
the
new-types-schy-9
branch
from
3a0807e to
5cf2f0b
Compare
|
New types will need to be introduced into this library before backend changes. |
models.go
Outdated
| Traits []*Trait `json:"traits"` | ||
| Rules []*Rule `json:"rules"` | ||
| mu sync.Mutex `json:"-"` // mutex for thread safety | ||
| Entitlements []*FeatureEntitlement `json:"entitlements"` |
There was a problem hiding this comment.
should this be tagged with omitempty?
There was a problem hiding this comment.
@bpapillon I think the original design was to have a map[string]*FeatureEntitlement here; I would strongly recommend we use a slice, though. It will be more flexible for us in the long run.
There was a problem hiding this comment.
I went back and forth on this - in practice, we would probably create a map in memory regardless, because we're going to be checking entitlements by a flag key, so we'd set up the data structure for that to be O(1). But I agree that this is more flexible and that is the tradeoff.
wyt about that @cbrady ?
also, yes I would likely omitemty this
There was a problem hiding this comment.
I've added omitempty
|
|
||
| type FeatureEntitlement struct { | ||
| FeatureID string `json:"feature_id"` | ||
| FeatureKey string `json:"feature_key"` |
There was a problem hiding this comment.
Yes, this is a term that Ben came up with for flag/feature.
There was a problem hiding this comment.
not a blocker for me but i feel like because we're going to be matching flags to this value we should call it flag key.
These will be populated after additional work on the backend