feat: Pretty Preview OG Tag Data with Social Cards

[dthyresson]

fixes #13

This PR implements a general preview of what a card "should" look like when rendered and unfurled on various site like: Twitter, Facebook, Slack, Discord, LinkedIn.

Note: Draft. Currently just a Twitter card is simulated. Also, dummy data is used, buy the props use the result data:

type Props = {
  ogPreviewData: OGTagPreview['result']
}

Basic layout:

The goal is to replicate this preview from https://www.opengraph.xyz/url/https%3A%2F%2Fredwoodjs.com

[dthyresson]

When SSR disabled:

When enabled:

And can preview:

[dthyresson]

Ok, I have reached a good stopping point.

• Url is defaulted to the user project web host and port
• Searchable list of custom user agents

• first pass at all previewers and audits
  
• can say what provider might be used by the agent
• Data tab

• zod based preview provider audit validation.

• • so let's say some twitter data is missing
    
    then
    

• all audits done on server and based on results, the previewers will render

Some refinements to be sure:

• some style tweaks for previewers
• could enforce more audit rules if needed
• the components in the go preview page could be extracted into own files for clarity
• passing the useState set to components seems clunky. Got to be a better way?

[Tobbe]

How come you're not using a Cell for this?

[dthyresson]

Because I just wanted to set a flag to show the disabled message section or render the page as per usual. There is no concept or empty state of need for a spinner loading state. I'd then have to wrap everything in a cell and that didn't seem worth it.

[Tobbe]

So how do you handle loading state now?

[Tobbe]

To me this looked like a typical example of the "CellPage" people have been asking about for a few years now from time to time. I.e. the page would be empty pretty much, just render a Cell that has all the actual page content inside

[dthyresson]

I don't have a loading state - the success and error are done in the OnCompleted and onError handers. Apps don't need to use Cells - we know of very large production apps that do not use that pattern. I would use query and not a cell if I was fetching the nav emu (and did in a preview implementation) as I didn't want to show a loading indication when making menus.

[dthyresson]

Also, unless I used the onCompleted and onError handlers, when I set/modifed the variable like showDisplayScrion etc and that was used in a useEffect, React would complain about multiple renders because the data and loading return values from the useQuery somehow caused multiple renders of the page. This was the cleanest implementation to simply "get the user config" and present the page according to its info.

[Tobbe]

I would use query and not a cell if I was fetching the nav emu (and did in a preview implementation) as I didn't want to show a loading indication when making menus.

Interesting!

I use a cell for loading the menu on https://acm.se. It actually does take long enough to load it so you can see the loading state, even on pretty fast broadband. In a mobile connection it takes even longer. So to me a nav menu that needs to do a gql request is a perfect use case for a cell 🙂

Not saying one way or the other is right or wrong. As always, "it depends" 😄

[dthyresson]

Hmm now that I think on it given the refactoring I did to make the previewed component it probably could be a cell where …. Well the main query to fetch the config would still be a success … y’know I’ll re think this a bit. A good reason to make in a cell later is if we make some preview images and that’s an RSC component and then a cell fetch pattern would be good to test. As you said — always options.

[Tobbe]

Could/should this also be a Cell?

[dthyresson]

I don't think it has to be.

[Tobbe]

Maybe because of the way you pass in setError etc it's different 🤔

[Tobbe]

BTW, wanted to say that this looks great! Well done!

[dthyresson]

BTW, wanted to say that this looks great! Well done!

Thanks! I like the audit idea and having all the options determined by the api/service so the reviewers are merely there to style a few bits of information. And should be easy to add new reviewers.

I’ll demo for town hall and in test app pick some better / different images 🙂