Moveable / Draggable embedded MDX components

[jayalfredprufrock]

As of now, there isn't really a way of moving an embedded MDX component once it has been brought into the markdown. You must either delete the component and add it back to the new desired location, or you must modify the MDX code directly. Neither solution is great for non-dev authors, which for me is the major appeal of Tina in the first place. Just having the ability to swap positions of two embedded components (i.e. move up/down where it simply ignores non-components) or even better some kind of draggable interface would add a major usability boost IMO and make things much more manageable for non-devs.

Block-based editing using templates would be the solution if it weren't for the fact that all the configuration is stuffed into front-matter, essentially making it impossible for developers to not use Tina. That wouldn't be a deal breaker if it were possible to design a block type (perhaps using references to a different MDX collection item) and have that MDX render directly instead of just the path to the file. Then developers would always have an escape hatch if they needed to inject some custom components in between blocks without having to fully build out that custom component for proper consumption in Tina.

Hopefully all this makes sense. Either solution above would be great, but the end goal is the same: allow developers to stay within the IDE and build out custom stuff without forcing them to fully wire every last thing within Tina, while still exposing a subset of things that are easily editable by non-devs. Tina seems soooo close to fulfilling that dream but still falls a little short IMO. I would consider bringing forward a PR if the team has a specific solution in mind but no bandwidth to tackle in the near future.

[scottgallant]

Thanks for the write up, @jayalfredprufrock. I'm really following this part. Can you elaborate on that?

... That wouldn't be a deal breaker if it were possible to design a block type (perhaps using references to a different MDX collection item) and have that MDX render directly instead of just the path to the file. Then developers would always have an escape hatch if they needed to inject some custom components in between blocks without having to fully build out that custom component for proper consumption in Tina.

[jayalfredprufrock]

Happy to elaborate!

What we've got now is a simple block-based page builder. Our pages are stored as a collection of MDX files and we've got fields for things like meta tags, page url, what layout to use, etc. We also have two special fields, "Top blocks" and "Bottom blocks", which present a list of templates that map configurable props to some of our most commonly used components (i.e. Hero, Panel, Carousel, etc.). We then leverage the body of the MDX file for any custom areas of the page.

This actually works pretty well. Developers can clone our starter repo that includes all this setup, and immediately make style and markup changes to the various components, and unless they are changing/adding props, they don't really have to spend much time mucking with Tina configuration and can stay within the IDE besides stringing together the various blocks that compose each page within Tina admin panel. But when it's necessary to insert custom components in between two other blocks, there are really only two choices right now:

1. Create a new block template, add it to the collection configuration, and add the rendering logic to map any template fields to the custom component. For one-off additions that don't really need to be editable within Tina, it's a fair amount of extra work.
2. Introduce a special block type that just contains a single MDX field. The only problem with this approach is that it makes managing that custom content very awkward within an IDE since it lives within frontmatter so you lose things like syntax highlighting (and potentially in the future, intellisense) . Because of the serialization limitations of MDX though, it's also not always enough control.

My comment above about using references to an MDX-based collection was to address the awkwardness of storing the MDX content in frontmatter. I had this idea of creating a special "components" collection that would just be a folder of MDX files where developers could put this custom code, then use a "reference" field type to bring that MDX into a specific part of a page. I quickly learned that this wasn't possible because the "reference" field resolves to the MDX file path instead of the rendered content.

As I'm typing all of this out, I'm realizing that the serialization limitations of MDX are likely to get in the way more often then not, so I really should be focusing on making #1 above as easy as possible, perhaps using some kind of CLI generator tool, and just accept the fact that all components need to ultimately map somewhere into a Tina block template. If Tina introduced some kind of official tooling or VSCode extension that helped facilitate this "block-based" workflow for developers, I think my prayers would be answered.

My original comment about making it easer to move MDX components around still stands though! Otherwise, I think I need to spend a little more time tinkering around to really see where things break down for my team. I'm already quite impressed how much I've been able to build on top of Tina in such a short time so kudos to the team for putting together some really powerful building blocks!

[jeffsee55]

@jayalfredprufrock it sounds like you're looking for something a bit more robust but in the meantime you can copy/paste MDX components. Perhaps we should make it a little easier to select them without going into edit mode on them