Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mdx support #29

Open
tefkah opened this issue Apr 25, 2022 · 7 comments
Open

Mdx support #29

tefkah opened this issue Apr 25, 2022 · 7 comments

Comments

@tefkah
Copy link

tefkah commented Apr 25, 2022

Hi!

Amazing plugin, thank you so much for developing it!

Are you by any chance interested in adding/developing full on MDX support in Obsidian? I feel like this would make the code much more portable as MDX is supported in many places.

Not sure whether this will be possible at all, as some things that work in MD (e.g. html) will break MDX, so you can't really wrap it as a layer around it naively, but would be very cool!

@elias-sundqvist
Copy link
Owner

elias-sundqvist commented Apr 25, 2022

MDX support would be cool, but as you said, I'm not sure whether it's possible to do in a good way.

I've been experimenting with something fairly similar though - webcomponents.

A webcomponent is basically a custom html tag. By using the react component as a web component you should in theory just be able to use the built-in html rendering functionality in obsidian.

I have technically added support for webcomponents already, but obsidian uses a whitelist to filter out unknown html tags, and I haven't found a way to add things to the whitelist in the api.

@elias-sundqvist
Copy link
Owner

This issue inspired me to investigate the problem a bit further.

Turns out that it's possible to patch the html sanitizer and make it do whatever you want. This actually allows me to replace the regular html rendering with jsx rendering.

I should be able to release a new version with this feature this weekend :)

@tefkah
Copy link
Author

tefkah commented May 4, 2022

Ooo that's extremely exciting, this would reallly improve my workflow! Very cool, I'll be looking forward to it!

@elias-sundqvist
Copy link
Owner

I was a bit optimistic with my time. There are some performance issues I want to fix before the next release, but I won't be able to finish that today. Hopefully next week. 🤞

@tefkah
Copy link
Author

tefkah commented May 12, 2022

Amazing! I've been playing around with it a bit and it's so cool to be able to live add React components to my prose!

Screen.Recording.2022-05-12.at.13.07.33.mov

Do you think "full" MDX will eventually be possible? e.g.
image

I'm definitely not complaining given how well it already works! But if you are able to achieve full interop it will open up so many possible integrations with e.g. existing MDX supporting publishing tools without the need to have make a special conversion layer, which would be so sickk.

If there's anything I can do to help let me know! I'm pretty experienced with making Markdown/whatever conversion engines using unified and React, but not at all with Obsidian's API & Codemirror. I had a crack at creating a textlint integration but could not really get it to work, but I can try at least lmao. Let me know if you're up for a chat or something, I'd be down!

If full MDX is not possible I had one tiiiiny suggestion left: would be cool if it could autodetect .mdx files and treat them as if defines-react-components: true had been applied in the header, saves having to maintain the header.

@elias-sundqvist
Copy link
Owner

I see the appeal of full mdx support. This could be done in two ways.

  1. Use mdxjs on the entire document.
  2. Manually implement each feature of mdx

The former option is problematic because you would lose all normal obsidian functionality, like wikilinks and live preview.

I could do the latter thing, but it would be an iterative process where I add one feature at a time. I also can't guarantee that every feature would be possible to implement without breaking some existing obsidian functionality.

Regarding defines-react-components: true - I can add an option for disabling this requirement.
Without this requirement, the plugin will have to read the content of every file in your vault on startup, so you may get a performance hit if your vault is large.

@tefkah
Copy link
Author

tefkah commented May 12, 2022

  1. Use mdxjs on the entire document.

  2. Manually implement each feature of mdx

That makes sense, I've been thinking about making my own (partial) MDX editor using Slate but unifying (heh) the incremental editing of a file with parsing said file in its entirety is kind of hard, notwithstanding MDX parsing just failing if you e.g. leave out a closing bracket.
The incremental approach makes more sense yeah, let me know if you want any help/testing with that!

RE: the requirement, that makes sense, would there maybe be an option for it to only scan .mdx files components, and only scan .md files when they have the yaml tag? Now that I think about it this usecase seems a bit too niche to be included, the all-or-nothing approach is probably fine!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants