Naming Convention for Component .tsx files

[mjarosch]

Is your suggestion related to a problem? Please describe.

If a large component is spread across multiple .tsx files, each .tsx file is picked up by the bootstrapping code.

Describe the solution you'd like

While it is simple to come up with a naming scheme for these helper files and add it as an exclusion for the bootstrap code. It would be nice to either have a naming convention for the main component, so that additional exclusions do not need to be added. Or, have a configuration file for the exclusions, so that we don't have to modify the bootstrap code directly, making future upgrades easier.

Is there a way to achieve this functionality with exisiting tools?

No response

Additional information

No response

[art-alexeyenko]

Hey @mjarosch !

We've added a "filter" feature to our backlog so that files can be configured to be ignored by component factory / component builder.
We will update here once this change is in the product.

[bewards]

Hey @art-alexeyenko - is there currently any approach we can take with the latest JSS version (21.6.0) to filter out stories files that live under src/components? (e.g., /src/components/Footer/Footer.stories.tsx)

I tried updating the ComponentBuilderPlugin to filter out the registered components, but config.components ends up being empty after generateComponentBuilder(config):

/**
 * Generates the component builder file.
 */
class ComponentBuilderPlugin implements ComponentBuilderPluginType {
  order = 9999;

  exec(config: ComponentBuilderPluginConfig) {
    generateComponentBuilder(config);

    console.log('AFTER generateComponentBuilder:');
    console.log(JSON.stringify(config.components));

    config.components = config.components.filter((c) => {
      console.log(`module name: ${c.moduleName}`);
      console.log(`component name: ${c.componentName}`);
      console.log(`component path: ${c.path}`);
      return !c.componentName.includes('.stories') && !c.componentName.includes('.spec') && c.componentName !== 'index';
    });

    return config;
  }
}

Update: I can see that writeComponentBuilder within the next-js package ultimately controls the output of the component-builder file, so anything that comes after that call to generateComponentBuilder(config); will just be more of an "after" event. Looks like I'll just have to separate these test and stories files out of each component folder.

[art-alexeyenko]

The component-builder plugins in the app are designed to add more components or packages to the ones imported from src/components by JSS itself. generateComponentBuilder(config); call is where this default import is performed.

What you can do is a couple of tweaks to retrieve and filter components strictly on the app side.

1. In \scripts\generate-component-builder\index.ts file, extend ComponentBuilderPluginConfig with componentRootPath:

export interface ComponentBuilderPluginConfig {
  watch?: boolean;
  packages: PackageDefinition[];
  components: ComponentFile[];
  componentRootPath?: string
}

2. The hacky part. In the same file, provide some dummy path with no components in it into defaultConfig:

const defaultConfig: ComponentBuilderPluginConfig = {
  watch: process.argv.some((arg) => arg === '--watch'),
  packages: [],
  components: [],
  path: 'src/empty-folder',
};

3. Now generateComponentBuilder will retrieve nothing and you can do something like:

import { getComponentList } from '@sitecore-jss/sitecore-jss-dev-tools'
...
config.components = getComponentList('src/components').filter((c) => {
      console.log(`module name: ${c.moduleName}`);
      console.log(`component name: ${c.componentName}`);
      console.log(`component path: ${c.path}`);
      return !c.componentName.includes('.stories') && !c.componentName.includes('.spec') && c.componentName !== 'index';
    });

in either \scripts\generate-component-builder\plugins\component-builder.ts or \scripts\generate-component-builder\plugins\components.ts

I haven't tried this myself, but this is a certified ShouldWork™ solution :)

[bewards]

Appreciate it @art-alexeyenko - I'll take a look at this!