The way React component actions and backend Page endpoints are glued together is described in the documentation.
Using the [PageCommand]
attribute you associate a command name with a public method on a Page
class
[PageCommand(CommandName = "EXPORT_LIST")]
public async Task<ICommandResponse> PageCommandHandler(CancellationToken cancellationToken = default)
{
// command behavior ...
}
From RecipientListOverviewExtender.cs
You call the command in your React code using the usePageCommand
hook.
// Define how the hook operates
const { execute: dataExport } = usePageCommand<SubscriberExportResult>(
'EXPORT_LIST', // Matches PageCommand attribute CommandName property
{
// configure the client-side behavior
});
Then you call that hook to call the back-end command handler.
useEffect(() => {
setState((s) => ({ ...s, status: 'EXPORTING' }));
dataExport() // Calling my C# PageCommandHandler method
.then(() => setState((s) => ({ ...s, status: 'COMPLETE' })))
.catch((err) => {
console.error(err);
setState((s) => ({ ...s, status: 'FAILURE' }));
});
From DataExportComponent.tsx
It might feel like there's less gluing these front and back-end components together than there should be, but what it enables is you can make a more generic React component and load it on any page in the administration.
As long as the back-end Page
class has a command handler to handle the React component's commands and return a response in the shape the React component expects, you can mix and match Pages and React components.