Metafield value support or documentation

[stevenpslade]

I found it confusing to use the shopify_function crate for the metafield data types being passed between Shopify and the Function.

One issue was the inability to preview / see the generated types, which I see an existing issue for: #17

Here is an example of a function API that sends metafields: https://shopify.dev/docs/api/functions/reference/order-routing-location-rule/graphql/common-objects/metafield

The metafield value is passed from Shopify to the function as a string and I found the support for this in shopify_function not clear.

When not using this crate and generating types myself in api.rs, I ended up doing something like this to handle the metafield format:

pub struct Metafield {
    pub value: Option<String>,
}

pub struct Configuration {
  pub value: Option<ExampleGroups>,
}

impl Configuration {
  fn from_str(value: &str) -> Self {
    // ExampleGroups::from_str constructs the JSON from the metafield string value
    Configuration { value: Some(ExampleGroups::from_str(&value)) }
  }

  fn default() -> Self {
    Configuration {
      value: None,
    }
  }
}

pub fn parse_function_configuration_value(metafield: Option<Metafield>) -> Configuration {
  match metafield.and_then(|m| m.value) {
    Some(value) => Configuration::from_str(&value),
    None => Configuration::default(),
  }
}

[DuncanUszkay1]

FYI @surma @nickwesselman

[surma]

Hm the problem is that the metafield really is just a string, and you as the developer can decide not only what data you store in there, but also in which format. We usually recommend and use JSON, but it could technically be anything else.

If you look at the example in this repo, you can see that we are manually decoding it using serde_json — the shopify_function macro does not touch the metafield at all.

That being said, we have talked about making JSON-encoded metafields the default case and providing more help to handle those.

[stevenpslade]

the problem is that the metafield really is just a string, and you as the developer can decide not only what data you store in there, but also in which format

This is fair. The example you provided looks nice! It gives folks working with metafields a great example and seems less complex than the way I handled it as per my post.

It might not be apparent when first working with functions and using shopify_function that the metafield value will not be handled, though. I think this goes back to #17 and knowing to use cargo-expand to see the generated types. This would make it immediately clear that the metafield value is a string and further manual decoding needs to be done.

Overall I think viewing the generated types and knowing to look at the metafield example fixes my original confusion.