UVE: Request page using Graphql

[rjvelazco]

Caution

GitHub issue Blocked by #31134 & #31210

Parent Issue

#30943

Background

Currently, the UVE uses the Page API to fetch page data. However, as clients increasingly require more complex responses, we are shifting our approach to utilizing GraphQL.

The client will now have a method called client.getPage that uses GraphQL. This method must be used within the UVE to fetch the same page data that the client expects.

Tasks

Preview Give feedback

1. The UVE successfully processes GraphQL query parameters sent by the client.
2. UVE documentation is updated with clear examples and guidelines.
3. Alpha Version should still work with the UVE
4. _map fields are correctly parsed and handled.

Proposed Objective

Technical User Experience

Proposed Priority

Priority 2 - Important

Acceptance Criteria

• Update the UVE to accept incoming GraphQL query parameters.
• Parse received query parameters (e.g., query, variables).
• Handle _map Fields: Parse _map fields in the response and remove them while retaining their values.
• Return a consistent GraphQL response structure to the client.
• Legacy Support.
• Documentation Updates.

Let's make sure the Legacy EditorConfig still works

core/core-web/libs/sdk/client/src/lib/editor/models/editor.model.ts

Lines 25 to 53 in 6a4e03c

	export interface DotCMSPageEditorConfig {
	/**
	* The pathname of the page being edited. Optional.
	* @type {string}
	*/
	pathname: string;
	/**
	*
	* @type {DotCMSFetchConfig}
	* @memberof DotCMSPageEditorConfig
	* @description The configuration custom params for data fetching on Edit Mode.
	* @example <caption>Example with Custom GraphQL query</caption>
	* const config: DotCMSPageEditorConfig = {
	* editor: { query: 'query { ... }' }
	* };
	*
	* @example <caption>Example usage with Custom Page API parameters</caption>
	* const config: DotCMSPageEditorConfig = {
	* editor: { params: { depth: '2' } }
	* };
	*/
	editor?: EditorConfig;
	/**
	* The reload function to call when the page is reloaded.
	* @deprecated In future implementation we will be listening for the changes from the editor to update the page state so reload will not be needed.
	* @type {Function}
	*/
	onReload?: () => void;
	}

Challenges and Considerations

1. Handling Invalid Queries:

   • If the UVE receives an invalid query in the response, it should not display the page. Instead, it should show an error message and provide an option to view the GraphQL error details.

2. Initial Editor Load:

   • To load the editor, we will request the basic page information but will not emit these changes to the hook/service through client.editor.on("changes").
   • We will not emit the initial fetch because, at that point, we have not yet received the client's custom query.
   • We will start emitting changes through the SDK once we receive their custom query

Assumptions

• The UVE has access to the same GraphQL endpoint and schema as the client.
• Query security (e.g., depth limits) is enforced at the GraphQL server level but will also be validated in the UVE.

Quality Assurance Notes

• Test end-to-end functionality for GraphQL query execution via UVE.
• Validate UVE's handling of missing or malformed parameters.
• Ensure proper security validations for query complexity and size limits.
• Benchmark performance and ensure efficiency under load.

[fmontes]

How this will affect angular and react sdk? how the query will be sent?