Support for Yoast plugin REST API fields

🗣 Feature Discussions Released
,
14

@mburridge (or anyone else that wants to give their opinion) quick check: does state.yoast.onlyInSSR sounds right in English?

This is a setting for the @frontity/yoast package, that adds the head tags generated by Yoast only to the server side rendered HTML (but not to the client rendering). It’s for performance reasons, although it’s deactivated by default.

It could be other things like state.yoast.SRROnly, state.yoast.rendering: "server"… Or even mention the client if that makes more sense: state.yoast.clientRendering: false, state.yoast.skipClient: true, state.yoast.skipCSR and so on…

15

It sounds right to me but I would still suggest a slightly different naming! :slight_smile:

The name onlyInSSR describes how it works but not why you would want to use it. I would rather call it something like optimize.

Let’s say that I’m a user who is concerned about performance. I would then want to use that option, but how would I find it? The name onlyInSSR is not going to be very meaningful to me and I might even overlook it unless I read the whole description. On the other hand if we call it something like optimize the purpose should be clear.

Of course, we have to explain that the trade-off is that he tags won’t render client-side.

1 Like
16

How about useSSRoptimisation?

17

Hmm… not sure if it’d be confusing because we’re not adding any optimization to the SSR, we are just removing the CSR part to save some CPU cycles in the client hydration.

18

After a quick discussion on the standup today we decided to name it state.yoast.renderTags with the default value of "both" and a possible value of "server" to avoid rendering the tags on the client.

EDIT: I have updated the implementation proposal.

19

We also need to make the getEntity function public, to allow sites that don’t use the normalized structure of Frontity to override it. We’re going to move it to libraries.source.getEntity as this is something related to source and other packages use it as well.

@david can you take care of these two changes? :slightly_smiling_face:

20

Working on that.

By the way, I’m going to try using a derived property instead of a library, I think it could have a better API, something like state.source.entity(link). It could be overwritten as well.

21

Changes are done. @luisherranz, you can review them whenever you can.

22

It’s interesting to notice that this is the first non-theme package that also depends on @frontity/html2react.

And in state.source.api and state.frontity.url being correctly populated. We should start noting those things.

We should add that to the docs. And maybe we have to start thinking about our dependency system :smile:

23

Unforunately, this is a bad API for TypeScript. We have the same problem than when we do:

const data = state.source.get(state.router.link);

if (data.isPostType) {
  //...
}

So if we want to maintain this API, we are going to need to apply the same APIs than we are going to use for the other case:

import { isPostType } from "@frontity/source";

const data = state.source.get(state.router.link);

if (isPostType(data)) {
  //...
}

Maybe we can use the very same functions for both cases, to avoid two separate APIs:

import { isPostType } from "@frontity/source";

const entity = state.source.entity(state.router.link);

if (isPostType(entity)) {
  //...
}

But we need something. Manual casting is not good enough if our goal is to have good TypeScript support in Frontity.

I guess we can distinguish between post types, taxonomies, authors and so on just by looking at their props, can’t we?

I’m thinking about approving the PR now and solve this in this issue, which is also in the current sprint: TypeScript 3.9 breaks @frontity/source types.

@david we can tomorrow about this.

24

Oh, my mistake, we can’t use the same functions because we need the arg is Type syntax and the types are different.

function isTaxonomy(data: Data): data is TaxonomyData {
  return (data as TaxonomyData).isTaxonomy === true;
}

function isTaxonomy(entity: Entity): entity is TaxonomyEntity {
  return !!(entity as TaxonomyEntity).taxonomy;
}

Then maybe we need to distinguish between those with different entry points:

import { isPostType } from "@frontity/source/data";

const data = state.source.get(state.router.link);

if (isPostType(data)) {
  //...
}

import { isPostType } from "@frontity/source/entity";

const entity = state.source.entity(state.router.link);

if (isPostType(entity)) {
  //...
}

Or different namings:

import { isPostTypeData } from "@frontity/source";

const data = state.source.get(state.router.link);

if (isPostTypeData(data)) {
  //...
}

import { isPostTypeEntity } from "@frontity/source";

const entity = state.source.entity(state.router.link);

if (isPostTypeEntity(entity)) {
  //...
}
25

Right, I see your point.

I implemented state.source.entity() this way because for me it wasn’t clear how to know the type of an entity depending on the given link but I didn’t realize it is the same case as state.source.data!

Using type guards here it’s a good idea. :+1:

26

By the way, would it be a good idea to add a warning when the yoast_head tag is not found?

In case people have not installed Yoast or the version is lower than 14…

27

It makes sense to me. Maybe also do the opposite in the head-tags package? If yoast_head is found we could recommend to use this package instead.

28

The new implementation has been released :tada: : Read the full Release Announcement .

This means that if you are using Yoast ^14.0, you should use this new package . And, if you’re using a previous version where the REST API is not supported by the Yoast plugin, or you use other SEO plugin, you can use the @frontity/head-tags package.

A quick demo of it:

2 Likes
29

Revisiting this thread, I think I forgot something important to mention!

In order to embed the post types – which are the entities that contain the yoast_meta field for post type archives (i.e. the homepage or the archive of a custom post type) – in the REST API responses, you would need to include some code in your WordPress site similar to the following one:

add_action( 'rest_api_init', function () {
  foreach ( get_post_types( array( 'show_in_rest' => true ), 'objects' ) as $post_type ) {
    if ( 'post' === $post_type->name || $post_type->has_archive ) {
      add_filter( "rest_prepare_{$post_type->name}", function ( $response ) {
        $type      = $response->data['type'];
        $types_url = rest_url( "wp/v2/types/$type" );

        $response->add_links(
          array(
            'type' => array(
              'href'       => $types_url,
              'embeddable' => true,
            ),
          )
        );

        return $response;
      } );
    }
  }
} );

That code adds the type inside the _links field of post entities and makes it embeddable so type entities are included when Frontity makes calls to the WordPress REST API.

3 Likes
30

I’m trying to use the transformLinks.base property but it doesn’t seem to work, and when I tried to find in the code how that is working, I couldn’t find where that transformation is being done. Could you help me here?

32

Hi @orballo :wave:

The @frontity/yoast package transforms links inside the useYoastHead hook, defined in /src/hooks/index.ts:

The function transformAllLinks() is defined in /src/utils/index.ts and uses transformLink() – defined in the @frontity/head-tags package – under the hood.

The property state.yoast.transformLinks.base is not documented yet but it is explained in the TSDocs:

WordPress URL base that must be replaced by the Frontity URL base (specified in state.frontity.url). If this value is not set, it is computed from state.source.api.

What’s exactly the problem you have? Is there a way to reproduce it?

1 Like
34

Thanks! I don’t know exactly what I was doing, I think I forgot to add the base to the slim version of the site, and therefore it wasn’t working :sweat_smile:

But everything works fine now!

35

Glad to hear that. :smile: