🚀 tech-insights: Make plugin customizable in new frontend system

[simondose1012]

Workspace

tech-insights

🔖 Feature description

The tech-insights scorecards should be customizable in the new frontend system.

This used to be possible by calling the old frontend system's components with self-defined props. In the new frontend system, it is currently not possible to customize the passed props without exchanging the whole component with a self-written one because the used JSX components are not exported.

🎤 Context

You should be able to customize e.g. the checksId like this:

techInsightsPlugin.withOverrides({
  extensions: [
    techInsightsPlugin.getExtension('entity-content:tech-insights/scorecards').override({
      params: {
        loader: () =>
          import('@backstage-community/plugin-tech-insights/alpha').then(m => {
            return compatWrapper(
              <m.ScorecardsContent title="Scorecards" checksId={[/* ... */]} />,
            );
          }),
      },
    }),
  ],
});

✌️ Possible Implementation

Export the components.

tech-insights/plugins/tech-insights/src/components/index.ts:

export * from './ScorecardsBadge';
export * from './ScorecardsCard';
export * from './ScorecardsContent';
export * from './ScorecardsGauge';
export * from './ScorecardsInfo';
export * from './ScorecardsList';
export * from './ScorecardsPage';

tech-insights/plugins/tech-insights/src/alpha/index.ts:

// ...

export * from '../components';

👀 Have you spent some time to check if this feature request has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

Are you willing to submit PR?

Yes I am willing to submit a PR!

[kurtaking]

Hey @simondose1012, we don't want to export the components directly. That's an anti-pattern and the new frontend system solves for this another way.

The entityTechInsightsScorecardContent extension is created with EntityContentBlueprint.make({ ... }) right now. This needs to be updated to EntityContentBlueprint.makeWithOverrides({ ... }) and provided the supported schema for customizations.

// something like this 
config: {
  schema: {
    // schema should support all existing props on the ScorecardsContent component
    ...
    checksId: z => z.array(z.string()).optional(),
    ...
  },
},

Here are some docs on the topic. Would you like to contribute this feature?

[simondose1012]

Hi, @kurtaking, thank you for this advice!

I will try the approach and open a new pull request.

[kurtaking]

Hi, @kurtaking, thank you for this advice!

I will try the approach and open a new pull request.

#5883 is a similar refactor you can use as an example. Looking forward to the contribution!

[simondose1012]

After looking into the approach, I realized that your proposed solution does not suit our needs for the integration of the plugin.

On our use case: We want to apply different checks with the Scorecard EntityContent, depending on the entity. So, e.g. a Group should show differing checks from a Component. Since we can only statically define the applied config once, a customization on a per-entity-kind base is not possible, as far as I can see.

I do not believe, that our use case is uncommon - by the nature of tech-insights plugin, a static configuration does not make a lot of sense.

Of course we could configure the applied checks with the config schema on a per-entity-kind basis, but even that would not be sufficient for our needs (and possible many others'), because not only the kind (but also e.g. the spec.type) of an entity is relevant for our current checks distinctions.

Is my understanding correct, or do I miss something here, @kurtaking?

[kurtaking]

@simondose1012, I am still doing my best to learn the new frontend system. I believe you're correct that static config doesn't fully solve this use case. I need more time and possibly input from others with more experience to offer the correct path forward.

I originally thought you would do something like the below, but that's not correct.

app:
  extensions:
    - entity-content:tech-insights/scorecard:
        disabled: false
        config:
          checksId: ['groupCheck1', 'groupCheck2']
          title: 'Group Scorecards'
        filter:
          kind: group
   
    - entity-content:tech-insights/scorecard:
        disabled: false
        config:
          checksId: ['serviceCheck1', 'serviceCheck2']  
          title: 'Service Scorecards'
          onlyFailed: true
        filter:
          kind: component
          spec.type: service
    
    - entity-content:tech-insights/scorecard:
        disabled: false
        config:
          checksId: ['libraryCheck1']
          dense: true
        filter:
          kind: component
          spec.type: library

[kurtaking]

Working backwards some here.. I think we need to build in a way that provides you the following functionality.

export default createFrontendModule({
  pluginId: 'tech-insights',
  extensions: [
    TechInsightsScorecardContentBlueprint.make({
      name: 'groups',
      params: {
        filter: { kind: 'group' },
        checksId: ['groupCheck1', 'groupCheck2'],
        title: 'Group Scorecards',
      },
    }),
    
    TechInsightsScorecardContentBlueprint.make({
      name: 'services',
      params: {
        filter: { kind: 'component', 'spec.type': 'service' },
        checksId: ['serviceCheck1', 'serviceCheck2'],
        onlyFailed: true,
      },
    }),
  ],
});

[kurtaking]

@simondose1012, I've confirmed we want to support this customization by providing a new TechInsightsScorecardContentBlueprint blueprint extension that will allow adopters to do similar to what I provided above.

Are you still interested or would you like me to pick this work up?

[simondose1012]

Moin, @kurtaking, thank you for looking further into this!

I like the approach with the custom blueprint - that would suit our needs perfectly!
I believe this should also be done for the EntityCard (not only the EntityContent) extension for consistency.

Unfortunately I won't be able to work on this until next week. So if you picked up this issue, that would be great!

[kurtaking]

Yes @simondose1012, you are correct. We will need blueprints for both. I'll have an update today/tomorrow.

[kurtaking]

@simondose1012 - close to having the following working for the new frontend system

import { TechInsightsScorecardBlueprint } from '@backstage-community/plugin-tech-insights-react/alpha';

const techInsightsModule = createFrontendModule({
  pluginId: 'tech-insights',
  extensions: [
    TechInsightsScorecardBlueprint.make({
      name: 'apis',
      params: {
        filter: { kind: 'api' },
        title: 'Custom API Scorecard Title',
        checkIds: ['apiDefinitionCheck'],
      },
    }),
    TechInsightsScorecardBlueprint.make({
      name: 'apis-two',
      params: {
        filter: { kind: 'api', 'spec.lifecycle': 'experimental' },
        title: 'Custom API Scorecard Title TWO - WONT SHOW',
        checkIds: ['groupOwnerCheck'],
      },
    }),
  ],
});

TechInsightsScorecardBlueprint.make({
  name: 'apis-two',
  params: {
-   filter: { kind: 'api', 'spec.lifecycle': 'experimental' },    
+   filter: { kind: 'api', 'spec.lifecycle': 'production' },
    title: 'Custom API Scorecard Title TWO - WONT SHOW',
    checkIds: ['groupOwnerCheck'],
  },
}),