Making scaffolder template's title customizable

[acierto]

Hey, I just made a Pull Request!

As an engineer of software templates I would like to be able to customise the title of a template.
Therefore we can add actionable items on the title panel.
We see a value of having a feedback panel for certain group of templates, so that user reach a proper docs and channel of support.

The solution is implemented for both versions of software templates.
The code example how to achieve the result is added to a documentation, as it might be useful for others as well.

✔️ Checklist

• A changeset describing the change and affected packages. (more info)
• Added or updated documentation
• Tests for new functionality and regression tests for bug fixes
• Screenshots attached (for UI changes)
• All your commits have a Signed-off-by line in the message. (more info)

[backstage-goalie]

Changed Packages

Package Name	Package Path	Changeset Bump	Current Version
@backstage/plugin-scaffolder-react	plugins/scaffolder-react	minor	v1.1.1-next.0
@backstage/plugin-scaffolder	plugins/scaffolder	minor	v1.11.1-next.0

[github-actions]

Uffizzi Ephemeral Environment deployment-17728

☁️ https://app.uffizzi.com/github.com/backstage/backstage/pull/16633

📄 View Application Logs etc.

What is Uffizzi? Learn more!

[github-actions]

This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!

[freben]

Hi! Sorry for the slow response here.

I think we want to avoid making this change. It's always tricky to inject this type of customizability all over the place with "ad hoc" interfaces that hopefully fit each use case. Makes things hard to maintain and evolve.

Going forward, our goal is to instead break out this entire page as a composable thing. We want you to be able to put your own wrapper and header as regular JSX with the entire "body" of the page just placed inside - and a host of other possible customizations. We're not quite there yet but moving toward that model. This is for example what the catalog page offers.

So for now, I suggest backtracking on this because we'll need to revert/redesign it some time fairly soon down the line anyway. Ping @benjdlambert here too.

[benjdlambert]

@acierto yep, I think overall we've realised that the need for customization in plugins has kind of outgrown the prop approach as it's just so much API surface to manage. We're looking at spinning up and issue to work out how we can solve these issues in a cleaner way with a dedicated API for replacing components in plugins so you can bring your own. Will try and get around to drafting up this issue today and keep you in the loop. I wonder if for now it makes sense to convert this PR into a TemplateWizardPage prop where you can provide you own page instead, similar to how we've done the OngoingTaskPage and have people copy the implementation for now. Feels a little nuclear, but it's at least going to save us adding props for everything in the short term.

[acierto]

@acierto yep, I think overall we've realised that the need for customization in plugins has kind of outgrown the prop approach as it's just so much API surface to manage. We're looking at spinning up and issue to work out how we can solve these issues in a cleaner way with a dedicated API for replacing components in plugins so you can bring your own. Will try and get around to drafting up this issue today and keep you in the loop. I wonder if for now it makes sense to convert this PR into a TemplateWizardPage prop where you can provide you own page instead, similar to how we've done the OngoingTaskPage and have people copy the implementation for now. Feels a little nuclear, but it's at least going to save us adding props for everything in the short term.

@benjdlambert It could be a solution, but TemplateWizardPage has a reference to routes, but by some reasons (which i don't understand now) they are never exported out of plugins

[benjdlambert]

Yeah they should be exported on the scaffolderPlugin.routes object. We probably have a little bit of work to remove the routeRef duplication and we should be able to export them from there.

[github-actions]

This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution!

[benjdlambert]

@acierto I went ahead and did the routeRefs work too #16942

[benjdlambert]

Actually I guess now we can close this ticket in favour of @minkimcello's work right #16915?

[acierto]

Actually I guess now we can close this ticket in favour of @minkimcello's work right #16915?

@benjdlambert Only if routers will be exposed, as basically it means that i have to copy paste full TemplateWizardPage

[benjdlambert]

@acierto not sure i'm following, what you do you mean Routers?

[acierto]

@acierto not sure i'm following, what you do you mean Routers?

@benjdlambert Oh I'm sorry.

const rootRef = useRouteRef(nextRouteRef);
const taskRoute = useRouteRef(nextScaffolderTaskRouteRef);
const scaffolderApi = useApi(scaffolderApiRef);

They are all in file routers.ts but this file is visible only inside the plugin.

[benjdlambert]

Ah but since #16942 they don't exist as next* anymore. They're using the same routeRefs as the other plugin. So that you can only run one and once, and they're available on the plugin export.

scaffolderPlugin.routes.x should have all the routeRefs for you.

[acierto]

Ah but since #16942 they don't exist as next* anymore. They're using the same routeRefs as the other plugin. So that you can only run one and once, and they're available on the plugin export.

scaffolderPlugin.routes.x should have all the routeRefs for you.

Cool, then yeah, we can close in favour of another PR.