Support for `LinkBlock` similar to `ImageBlock`?

[stern-shawn]

Hi! I see in the isHikeElement check (source) that paragraph and image nodes are supported and have types exported as well, but links/anchors are not.

In a PoC that I'm building with Code Hike I'm trying to let users declare a custom button, say a call to action that should be styled nicely based on the page template, so I'd want a template something like this:

<PageWrapper>
  Some content

  [!cta Do an action](/link-to-action)
</PageWrapper>

Right now this doesn't work and the wrapper component will just receive children as props. If I change the node to an image, it works, but that'd be a weird syntax to communicate to authors.

eg this is functional and usable, but not syntactically ideal for authors:

<PageWrapper>
  Some content

  ![!cta Do an action](/link-to-action)
</PageWrapper>

I have viable alternatives in terms of passing props directly to the component, etc, but this could be a nice addition if support wasn't omitted for functional reasons 😄

[stern-shawn]

Slight extension to this: there is a bit of incompatibility with the remark-unwrap-images package. The isImageAndParagraphs check only allows for images that exist within a paragraph, but we use this plugin to un-nest standalone images to avoid invalid DOM nesting that this default behavior introduces.

ex before:

{
  type: 'paragraph',
  children: [
    {
      type: 'image',
      title: null,
      url: '#some-anchor',
      alt: '!cta Marketing language',
    }
  ],
}

after remark-unwrap-image:

{
  type: 'image',
  title: null,
  url: '#some-anchor',
  alt: '!cta Marketing language',
}

Would it be reasonable to allow standalone image nodes and similar to be hikeable? This would be less of an issue if links were supported, as I wouldn't be using images in this context yet 😄

[pomber]

I've been thinking about adding links, but I still have to experiment more because I want to support use cases like this one, where the link is inline (instead of a block). So I don't want to rush this one until I know how I want it to work in the future.

incompatibility with the remark-unwrap-images package

Does it still happen if you put remarkCodeHike before remarkUnwrapImages?

[stern-shawn]

If we change the order so that remarkCodeHike comes first, it's fine in that sense, but then we get several more errors in our particular chain of remark plugins, as we have several custom components that hijack image syntax and need to be converted to MDAST before Code Hike passes through. Not necessarily something you need to worry about because that's a quirk of our docs and hopefully not the norm.

I would still love to be able to expect that a standalone or 'block' link and/or image node could be Code Hike'd successfully, as it opens up a few more options for formatting links differently (ex. converting a plan markdown link into a styled CTA button, which only needs text and a url to work). Hopefully that would no conflict with inline links?

I can get the same end result by introducing MDX components and instructing authors to use them instead for now 😄