Handlers for non-URL data

👨‍💻 Framework Development » Framework Design
,
21

I see. Well, one problem is fetching the comments (handled by wp-source via actions.source.fetch("@comments/1232") but another is creating new comments. I don’t think themes should have to implement the logic of creating a new comment…

The @frontity/wp-comments could expose:

  • Comments: a component that shows both the comments and the form to create a new one.
  • CommentForm a component to create a new comment.
  • actions.comments.create(...): an action for those themes that want to create the form themselves, but don’t want to implement the logic.

Apart from that, we need to investigate a way to pass down styles to an external component:

I think this works, but I’m not 100% sure:

const commentsStyles = css`
  margin: 0;

  .commentItem {
    color: red;
  }
`;

const Post = ({ ... }) => {
  return (
    <>
      ...
      <Comments className={commentsStyles} />
    </>
  );
}
22

Okay, I like the approach you suggest. I’ve opened a new topic in order to keep talking about this. Let’s keep this one for the handlers for non-URL data.

23

Hi there! Just wanted to say (in case you are not aware of it) that currently when I use a @something pattern, the data object still gets populated with link and query and those things. I think this doesn’t make much sense. Is this something you already thought about?

24

Hey @orballo :wave: Yes, I’m working on updating the wp-comments package to use the REST API in https://github.com/frontity/frontity/pull/542/ and I’ve just realized the same problem.

I think that we’ll have to update the source.libraries.populate(), the CommentData source type and the comments handler to account for that (and possibly something else).

My bad, it’s actually unrelated

However, I think it’s quite harmless to populate those. Since we populate every link with entity with link, route, query & page here

I’m guessing that we just could add a simple check to not add a query & link or route if the link starts with @:

// This is state.source.get

get: ({ state }) => (link) => {
	// ...
	if (normalizedLink.startsWith("@")) {
	  return { page, isFetching: false, isReady: false }
	} else { 
	    return {
	      link: normalize(normalizedLink),
	      route,
	      query,
	      page,
	      isFetching: false,
	      isReady: false,
	    };
	}
}

Any reasons against it?

25

@orballo Update: This will be updated according to how I mentioned previously. The query, route and link will be removed from non-URL entities in the data object like:

if (normalizedLink.startsWith("@")) {
  return { page, isFetching: false, isReady: false }
} else { 
   return {
      link: normalize(normalizedLink),
      route,
      query,
      page,
      isFetching: false,
      isReady: false,
   };
}
1 Like
26

Have these plugins been released yet?

Im currently using a plugin called WP REST API Sidebars, https://en-gb.wordpress.org/plugins/wp-rest-api-sidebars/, to expose and get my sidebars. However, all of the links point back to the original WordPress site. For example when I click on a post in the Recent Posts widget im directed back to the original WordPress site.

Do you have any suggestions on how best to fix this?

Any help would be appreciated.

27

Hi @leogardner12!

Right now we only have the REST API - Head Tags plugin and we are working on a plugin for the embedded mode.

Regarding this, I would recommend you a couple of things:

  • Redirect your WordPress urls to Frontity urls, excludings the ones for the admiin, the REST API…
  • Use our link processor to handle the routing, and use html2react for the widgets you mention. You can see more information at this other Feature Discussion that has already been released.
28

Putting this down for people searching for the reason why their translations/multisites aren’t working properly, and how this topic is the solution.
Additionally I hope that the solutions implemented won’t break any workaround, like the one described below.

While working on a multilingual website in Frontity I noticed that custom handlers break on subdirectories (eg. https://example.com/nl/) because the handler route was being “redirected”.

For example retrieving the menu on the main website worked without a problem, but didn’t even reach the menuHandler (like menu-handler.js).

After a lot of debugging I fixed it by simply adding an @ in front of the route of the handler(s), so they wouldn’t be redirected and therefor return nothing.

2 Likes