feat: load favicon from WordPress server

[SH4LIN]

What

• This PR will load the favicon icon, apple touch icon and msapplication-tileImage from the WordPress server

Related Issue(s):

• Part of: https://github.com/rtCamp/headless/issues/405

How

• This PR will use the app router metadata API and using that metadata API and the icon data fetched from server it will add the necessary tags into the head

Checklist

• I have read the Contribution Guidelines.
• My code is tested to the best of my abilities.
• My code passes all lints (ESLint, tsc, prettier etc.).
• My code has detailed inline documentation.
• I have added unit tests to verify the code works as intended.
• I have updated the project documentation as needed.
• I have added a changeset for this PR using npm run changeset.

[changeset-bot]

🦋 Changeset detected

Latest commit: 7fea521

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
@snapwp/query	Patch
@snapwp/next	Patch
snapwp	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[ayushnirwal]

LGTM

[justlevine]

Functionally working 🚀

Feedback on composability/code quality patterns below:

[justlevine]

Functionally, things are passing, but I would like @ayushnirwal 's feedback on the composability (generally, and per the open conversations on this diff).

Once that's done (since the package diff might change) npm run changeset and we should be able to merge this.

[ayushnirwal]

Although the patterns around queries, documents, client management are not ideal in the current state. I'm willing to merge this PR (after the last few feedbacks are addressed) for the following reasons.

• It works.
• This adds parsers, some of the types around favicon and meta data management. When we implement the metadata management and data fetching management interfaces these will be used.

[justlevine]

Although the patterns around queries, documents, client management are not ideal in the current state. I'm willing to merge this PR

@ayushnirwal can you flag some parts of the diff that deserve a // @todo and/or generally list what the next steps should theoretically be for improving things?

I don't want to merge this PR without making sure we have a (vague) plan to follow it up.

[ayushnirwal]

import type { DocumentNode, TypedQueryDocumentNode } from 'graphql';

export type Variables = Record< string, unknown >;

export type FetchQuery< T = unknown, V extends Variables = Variables > = (
	queryKey: string[],
	document: DocumentNode | TypedQueryDocumentNode< T, V >
) => Promise< T >;

export type getServerClient = (
	url: string,
	options: Record< string, unknown >
) => ServerClient;

export type getBrowserClient = (
	url: string,
	options: Record< string, unknown >
) => BrowserClient;

export interface ServerClient {
	fetchQuery: FetchQuery;
}

export interface BrowserClient {}

These types/interfaces are the general broad strokes for the composability in our data-fetching mechanisms. This allows users to

• Implement their own ServerClient with the custom getServerClient and fetchQuery
• Compose their own ServerClient with the getServerClient and fetchQuery with implementations exported from @snapwp/query
• Use a pre-implemented ServerClient exported from @snapwp/query
• Any implementation of ServerClient will have the fetchQuery function to which a doc can be passed for querying.
• Wrappers will be built around FetchQuery to get functions like FetchGlobalStyles. These will be exported for internal or external use.

[justlevine]

@ayushnirwal anything specific to favicons / site metadata (see the remaining open conversations on this PR) or just the underlying Query API?

[ayushnirwal]

Wrappers will be built around FetchQuery to get functions like FetchGlobalStyles. These will be exported for internal or external use.

• Similar to this we will create a wrapper FetchFaviconDetails
• getIcons (without the fetch call) and its internal utilities become data parsing utilities. Which allows us to move it to @snapwp/core along with the related types.
• FetchFaviconDetails and renamed getIcons will be then composed to make getMetaData in @snapwp/next.
• The same pattern will be followed for the SEO-related meta data too.

[justlevine]

@SH4LIN what's with the failing tests?

Also can you add a changeset ?

(Once those are resolved this should be good to merge)

[SH4LIN]

@justlevine Checks are passing now

[justlevine]

Reminder, changesets is "dumb" and major|minor|patch is mapped blindly to x.y.z, not real semver