feat: support preferred vocabulary name

[paulrobertlloyd]

This PR adds support for querying for supported vocabularies and using any preferred names for relevant post types in Sparkles’ interface.

For example, querying my test endpoint, I get the following response (truncated, only relevant objects shown):

"post-types": [
  {
    "type": "like",
    "name": "Favourite"
  },
  {
    "type": "watch",
    "name": "Film"
  },
]

This results in the interface adapting such that ‘Favourite’ is shown instead of ‘Like’ and ‘Film’ is shown instead of ‘Movie’:

[netlify]

✅ Deploy Preview for sprkls ready!

Name	Link
🔨 Latest commit	67013e0
🔍 Latest deploy log	https://app.netlify.com/sites/sprkls/deploys/655922ae1481720008f0ebb0
😎 Deploy Preview	https://deploy-preview-17--sprkls.netlify.app/
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[paulrobertlloyd]

I noticed that LikeTile, ReplyTile, RSVPTile and BookmarkTile appear in SharePage.js, but not sure where these tiles appear. Should these also accept the new name option?

[benjifs]

I might be misunderstanding something but wouldn't the results from the query like in your example mean that the server only supports like and watch posts? Therefore, the labels would match on the name ("Favourite" and "Film") but only those two options should show as post options.

As for the SharePage, that's specifically triggered when sparkles is installed as a PWA and you use it as a share target. A way to preview it would be to go to the route directly: https://sparkles.sploot.com/share?url=https://benji.dog

[paulrobertlloyd]

I might be misunderstanding something but wouldn't the results from the query like in your example mean that the server only supports like and watch posts?

Correct. Ideally, if a sever returns a post-types object, Sparkles should only show options to create the supported types. Happy to include that in this PR if you think that’s a good idea? (If the server doesn’t return a post-types value, we can show all post options as is the case currently).

[paulrobertlloyd]

I’ve added some code to prevent showing a tile on the home page if there’s a post-types object but the named post type isn’t listed by it. However, it seems like I need to refresh the page for this to be reflected (else only the ImageTile is shown).

And looking at the SharePage.js, unsure how best to abstract this functionality so that it is available to both pages. Maybe it should be provided via each tile from Editors/Tiles.js?

[benjifs]

Thanks! Took your ideas and ran with it. I've now moved the rendering of the Tiles to a single component that will use the post-types to optionally render those in the home and share pages.

I also made sure that the titles of each editor uses the name from post-types like you set up for the tiles.

I'll wait to hear back on your thoughts before merging just in case something is missing.

[paulrobertlloyd]

Oh, nice. Yeah, updating the titles is a good idea too. Just tested this and spotted 2 issues:

• I still need to refresh the homepage to display the correct tiles after logging in (I tried this in a private window to ensure session storage wasn’t affecting the behaviour and saw the same issue)
• Accessing /share nothing appears. In the console I get the following error: ReferenceError: Can't find variable: Store. Might be missing an import somewhere?

[benjifs]

Good catch. I have the tiles redrawing after the config is loaded now so that should display the tiles correctly.

[paulrobertlloyd]

Excellent. 🚢!