As discussed in #233 , it was suggested to use productVariant.withProductVariant(AttributeAccessor::asMap) and then a variant of attributes.get("attrName").withAttribute(AttributeAccessor::asType).
However, this makes it a bit hard to handle nullable attributes, because we'll need constant null checking or provide defaults, which makes asMap a bit limited.
Suggestion: additionally provide an abstraction (wrapping the map?) that more easily handles nullable parameters.
It should be trivial to create one on user code, but it feels like this is something the SDK should make it easier to handle? At least this feels a bit harder to work with than SDK1.
To exemplify what I'm thinking, a possible solution that eases such cases:
interface NiceAdapter {
@Nullable
Attribute getAttribute(String attrName);
// doWith would only be applied if attributes[attrName] != null, otherwise return null
// AttributeAccessor methods could be reused
@Nullable
default <T> T withAttributeIfPresent(String attrName, Function<Attribute, T> doWith) {
Attribute attr = getAttribute(attrName);
if (null == attr) return null;
return doWith.apply(attr);
}
}
and usage:
var attributes = productVariant.withProductVariant(AttributeAccessor::asNiceAdapter);
var attribute = attributes.withAttributeIfPresent("nullableAttribute", attr -> AttributeAccessor::asType);
// handle nullable attribute or not, if I know attr is never null
Hi!
As discussed in #233 , it was suggested to use
productVariant.withProductVariant(AttributeAccessor::asMap)
and then a variant ofattributes.get("attrName").withAttribute(AttributeAccessor::asType)
.However, this makes it a bit hard to handle nullable attributes, because we'll need constant null checking or provide defaults, which makes
asMap
a bit limited.Suggestion: additionally provide an abstraction (wrapping the map?) that more easily handles nullable parameters.
It should be trivial to create one on user code, but it feels like this is something the SDK should make it easier to handle? At least this feels a bit harder to work with than SDK1.
To exemplify what I'm thinking, a possible solution that eases such cases:
and usage:
Thanks