You can use automated tools like the VSCode plugin for ScandiPWA or a CLI, or just do it manually. Here we show how to override component classes, but the same mechanism can be extended to query, route, and store class overrides as well

Overriding component classes manually

Virtually always, you will want to keep part of the default functionality and only modify some aspect of the existing class. This is how the theme is usually extended.

For example, when overriding ProductCard, suppose we want to keep the default ScandiPWA implementation of the component, but with one change - we don't want the product images to be visible in the product cards.

In order to do this, we will make sure our class extends the base ProductCard class. Then, it will inherit the default functionality from its parent class, and we will be able to override any part of it.

All we need to do is import the original ProductCard class, extend it, and re-export the modified version. But there is one challenge: as mentioned before, if we try to import from Component/ProductCard/ProductCard.component, the import mechanism will resolve this to our overridden implementation, not the desired original class. Hence, it is impossible to import the original class from the parent theme using the Component alias if we intend to override this class.

<aside> ℹ️ The solution is to use another alias, SourceComponent to extend classes from the parent theme. The ScandiPWA import mechanism provides the Source aliases to enable you to directly import from the parent theme, regardless of whether there is an overridden version available**.** Similarly, you can use the SourceRoute alias to import directly from a route defined in the parent theme, or the SourceUtil alias to import an utility file from the parent theme.

</aside>

import { PureComponent } from 'react';

// we use the SourceComponent alias to explicitly import from the parent theme
// (if we would use Component/ProductCard/... instead, we would be trying to import
// the current file, which would result in an error)
import { ProductCard as SourceProductCard } from 'SourceComponent/ProductCard/ProductCard.component';

// we imported the original ProductCard class defined in the parent theme.
// we aliased the import to `SourceProductCard` to indicate that SourceProductCard
// is the parent theme version of the class

// you should always copy over the namespace declaration when overriding an existing class
// to avoid breaking plugins
/** @namespace Component/ProductCard/Component */
export class ProductCard extends SourceProductCard { // we can now extend SourceProductCard,
    // and override any methods we want to change

    // this method overrides the default implementation provided in the original ProductCard class
    renderPicture()  {
        // returning null in a React component means rendering nothing
        return null;
    }
}

// we now export the extended and modified version of the class
export default ProductCard

<aside> ✅ You should never have to copy any code from the parent theme to reuse it. It is a good practice to always import functions, classes, and values from the parent theme when you want to extend them, as shown above. Following this pattern will result in cleaner code - it will be immediately clear which functions your code changes by overriding them. In addition, there will be less code to maintain, resulting in faster development.

</aside>

<aside> ➡️ You should always copy over the namespace declaration when overriding an existing class to avoid breaking plugins.

</aside>

Indeed, we can check that now, the ProductCard component is the same as in the default theme, with one change: it no longer has a picture.

Untitled

<aside> ⚠️ When overriding a JavaScript file, you should make the same exports as the file you are overriding. If the original theme file exports a certain constant, it is possible that other classes (or third party plug-ins) will expect that they can import this value. If you forget to re-export it when overriding the file, these imports will break. You are of course allowed to add new exports and modify existing ones, but please be careful to never leave out an export.

</aside>

Overriding Constructors

ScandiPWA uses magic __construct functions instead of constructors. This is done to enable overriding of these functions, which you can override like any other function.

Overriding component classes using VSCode plugin

  1. Open ScandiPWA project folder in VSCode and press F1 key
  2. Search for and choose "ScandiPWA: Extend a component" action
  3. Enter the name of the component. See How can I find a component name?
  4. Choose to determine a source module by Fallback plugin
  5. Follow rest of the instructions and choose every part of the component you want to override

This will generate necessary files in the src/ folder with template code in them so you can easily get going. You can take code you need from the original files. How can I find the original files?

See the actions for overriding other classes:

Overriding component classes using ScandiPWA CLI

You should first know the name of the component. See How can I find a component name?

Then use a ScandiPWA CLI command:

scandipwa override component [--styles=<"extend"|"override"|"keep">] [--source-module=<module>] [--target-module=<module>] <name>

Command option description:

This is how prompts from this CLI command look like:

scandipwa override component Header
? Choose things to extend in Header.component.js Header
? What would you like to do with styles? Extend
? Choose things to extend in Header.config.js 
? Choose things to extend in Header.container.js 

NOTE!

     The following files have been created:
     src/component/Header/Header.override.style.scss
     src/component/Header/Header.component.js

This command will generate necessary files in the src/ folder with template code in them so you can easily get going. You can take the code you need from the original files. How can I find the original files?

See the commands for overriding other classes in the Documentation.