A UI field for building block-based pages with MDX

[scottgallant]

Dealing with YAML in .md files for block-based pages (like the approach we describe here) often feels overly complex. When you have page with a lot of blocks, you easily can get 100s of lines of YAML. For a front-end developer, it's often much simpler/quicker to use MDX components for block-based pages.

Having a UI field that allows editors to use MDX but without the rich-text chrome would be ideal for these types of pages. We would get the DX of using MDX components for block-based layouts and the UX of our existing block solution, like so:

If the user wanted to insert a markdown text between blocks, you could do that with an MDX component that includes a rich text field

[jeffsee55]

As mentioned in office hours, there's one thing to consider for this feature, which is that mdx as it stands today is that there's no way to control what data you get from those blocks, so for the example above the payload might look like this:

[
  {
    _template: "Hero",
    title: "Hello, World!",
  },
  {
    _template: "Features",
    items: [//etc]
  },
  {
    _template: "Content",
    body: "..."
  }
]

That would work fine, but if you had a "FeatureBlog" section, we'd want to resolve some data across to each blog post:

{
  _template: "FeaturedBlogs",
  posts: [
    {
      title: "Hello, World!",
    }
  ]
}

But since the query would look like this:

{
  getPageDocument(relativePath: $relativePath) {
    data {
      blocks
    }
  }
}

We don't have anywhere to tell GraphQL that it needs to resolve blog lists. What we probably want instead is something like this:

{
  getPageDocument(relativePath: $relativePath) {
    data {
      blocks {
        embeddedObjects {
          ...on Hero {
            title
          }
          ...on Features {
            items { ... }
          }
          ...on Content {
            body
          }
          # Doing it this way allows us to resolve across nodes
          ...on FeaturedBlogs {
            data {
              title
            }
          }
        }
        ast # this would be the actual data
      }
    }
  }
}

This is discussed a bit more in the MDX pitch under the "Bonus" section https://github.com/tinacms/product-archive/discussions/26

[jeffsee55]

One additional note - I know this is much more cumbersome to write, but I think it's something that the SDK could simplify to where it'd be valuable.

[llibdude]

I am very much looking forward to this feature. Any chance there is an estimate on when this feature would be released?

[scottgallant]

@llibdude We do not have a timeline on this. Do you use block-style layouts for pages now (using the pattern suggested here)? If you help us understand why you would prefer to achieve this with MDX instead, that could help us prioritize this work.

[llibdude]

I do use the block-style currently with my page builder and it is a great approach. Thinking about longer term projects, something like a blog I wonder if this feature would improve the overall experience in the case where a blog could have a good amount of mdx components. I likely have some people that would love to write entirely in md(x) and push to a github repo, if there is no yaml to worry about that is also an added bonus.

I can totally do a blog with tina the way it is, and this feature is definitely a nice to have. One of my concerns then down the line is if this gets released and I want to use it on an existing project the migration effort would be large. However if there is no immediate plan that is fine, i will pay the migration tax when the time comes :)

[jeffsee55]

I think this is the biggest blocker here. For us to really lean in on this we need to allow fields like reference to possibly resolve, right now if you use a reference in an MDX element you'll just get the raw path to the reference file. @llibdude do you have any thoughts about that problem (and proposed solution)?

[llibdude]

I do not off the top of my head unfortunately. I might not be smart enough either, but i'll let you know if I think of something.