refactor: introduced the useApi composable, refactored loading configuration

[Frodigo]

Description

💅 Refactors

composables

• fixed type error in the useCart composables that appeared when cart was empty
• added debug log in the useConfig loadConfig method in the useConfig composable
• made the useCustomQuery composable depraacated

theme

• refactored the useMagentoContiguration composables to load only config
• added StoresModal component and moved loading stores there
• added CurrenciesModal component and moved loading currencies there
• make those components lazy-loaded
• refactored styles of the CurrencySelector and the StoreSwitcher components
• refactored the TobBar component, moved all business logic to the useTopBar composable

🚀 Features

theme

• added the useApi composable (which replaces the useCustomQuery composable) and the possibility to run GraphQL requests without using composables

🏡 Chore

theme

• added graphql-request lightweight GraphQL client

Motivation and Context

Performance

First of all, we want to reduce main thread working but make components lazy laded and move composables execution to components that are not rendered on page load.

In this case:

1. useConfig composable loads data when user clicks on StoreSwitcher and opens stores modal
2. useCurrencycomposable load currency data when user click on currency switcher and opens currencies modal

State management

Until now we were using the apiClient and composables to load every data.

On the one hand, composables produce singletons and allow to use of data in different places. On the other hand, there are many cases when we don't want to keep data globally and use those mechanisms that are redundant and cause some performance issues when the page is loading.

In addition, API defined in APiClient typically gets a lot of data that is not necessary for specific situations. For example, storeConfig query gets all config objects from Magento, but on page load, we need only a few properties.

To avoid over-fetching we should use small queries. In this case, the query looks like this:

query getStoresAndCurrencies {
      availableStores {
        store_code
      }
    currency {
      available_currency_codes
    }
  }

To do so we added the possibility to execute queries and mutations directly from the app.

• operations fired in the onMounted hooks are fired on client-side
• operations fired in the useAsync, or useFetch are fired on the server-side

Bussiness logic in components

Adding business logic in components makes components hard to extend so the new approach assumes that components with business logic use compostable that returns all necessary things like methods, computed values, etc.

Take a look at the example

<template>
<!-- content here --> 
</template>

<script>
import { SfButton, SfTopBar } from '@storefront-ui/vue';
import useTopBar from './useTopBar';

export default {
  components: {
    CurrencySelector: () => import('../CurrencySelector'),
    SfTopBar,
    SfButton,
    StoreSwitcher: () => import('../StoreSwitcher'),
  },
  setup() {
    const { hasStoresToSelect, hasCurrencyToSelect } = useTopBar();

    return {
      hasStoresToSelect,
      hasCurrencyToSelect,
    };
  },
};

</script>
<style lang="scss" scoped>
// styles here
</style>

The setup function returns business logic from the useTopBar composable. In fact, it can look like this:

 setup() {
    return ...useTopBar();
  },

but in my opinion, the first example is more readable.

Thanks to that, business logic is separated from visual representation, and it's a good first step to provide an extensibility framework in the future

Vuex or Pinia stores

This approach allows developers to add an additional building block and use Vuex or Pinia store for state management instead of using sharedRefs. This is not implemented yet, but I wanted to open a discussion.

Requesting other APIs

The useApi composable allow making a request to other endpoints that Magento endpoint so this adds some flexibility and additional options to integrate with other services.

Note: CORS configuration

Magento does not allow to make requests to GraphQL API directly from the browser, and additional CORS configuration is needed on the Magento side. This open-source module allows to properly configure CORS.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.