What is extension’s config and why we may need it in FE?

Most magento extensions have set of configurable or pre-defined data which can either be changed from admin panel or through code. Usually, this data is needed to allow for customization of different features of the extension, this can be anything starting with positioning of certain elements on the page, for example, for some arbitrary payment methods it could be: Whether or not to place payment button on the PDP, Minicart, Cart, or Checkout pages, or whether or not to enable ability to save or re-use the credit cards and etc, or for an arbitrary extension which enables custom reviews it could be: Whether or not there should be number of reviews displayed and so on.

How is extension configuration accessed in magento luma extensions?

For different extensions this set of features/configurations will vary widely, but, there is also a common pattern in creating and using the configuration from code architecture perspective.

Specifically, usually the extension configuration will have it’s own MVC model which will be used as point of access. It might be something like: SomeExtension\\Model\\ConfigProvider . This Config model will be imported possibly somewhere in block.

How to transform config model into a resolver?

In order to get the configuration to ScandiPWA front-end, we need to transform the model into resolver, which can be queried.

Create in your vendor folder which is app/code/Scandiweb/EXTname the following directories along with the files:

a) Model/Resolver/extensionNameConfig.php

b) etc/schema.graphqls

a) You will need to look into the original extension and find out the file responsible for getting the config data in our example will be Amasty\\Label\\Model\\ConfigProvider;

class AmastyLabelsConfig implements ResolverInterface

b) You will need to use that class by dependency injection in the resolver

/**
* @var ConfigProvider
*/
private $config;

public function __construct(
    ConfigProvider $config
) {
    $this->config = $config;
}

c) You will need to implement the resolve method:

As in the following example we’re using the $config object which can help us get the required config data and we return in the resolve method an object that contains 3 attributes (showSeveralOnPlace, labelsAlignment, and marginBetween) that we extract from the $config object

/**
* @param Field $field
* @param ContextInterface $context
* @param ResolveInfo $info
* @param array|null $value
* @param array|null $args
* @return array|Value|mixed
* @throws \\Exception
*/
public function resolve(
  Field $field,
  $context,
  ResolveInfo $info,
  array $value = null,
  array $args = null
) {
  return [
      'showSeveralOnPlace' => (int) $this->config->isShowSeveralOnPlace(),
      'labelsAlignment' => $this->config->getLabelAlignment(),
      'marginBetween' => $this->config->getMarginBetween()
  ];
}

The second step:

We implement our schema: a) Creating the return type of the config object:

type AmastyLabelsConfigType {
    showSeveralOnPlace: Int @doc(description: "Show Several Labels on the Same Place."),
    labelsAlignment: Int @doc(description: "Labels Alignment."),
    marginBetween: Int @doc(description: "Margin between labels, px.")
}

This type of object query consists of three things:

  1. showSeveralOnPlace

  2. labelsAlignment

  3. marginBetween

As you remember these three attributes have the same naming as attributes in the object returned by the resolve method in the resolver we created, each of these attributes has a type as you can see it’s Int and @doc to add a comment that explains what this attribute contains.

b) In our example that FE will do a query not a mutation to get the extension’s config data, so we will create a query as follows:

type Query {
    amastyLabelsConfig: AmastyLabelsConfigType @resolver(class: "Scandiweb\\\\AmastyProductLabels\\\\Model\\\\Resolver\\\\AmastyLabelsConfig"),
}

This query consists of three things:

  1. The query name amastyLabelsConfig that FE will request it.

  2. The return type of config object AmastyLabelsConfigType

  3. The resolver responsible for providing the data to FE. You will need to add the path as in the example above.

What are the real examples of this?

In this example, you will find the complete source code of the resolver that we used to explain how to create a resolver.

In this example, you will find the complete source code of the schema that we used to explain how to create a schema