Show HN: Tinasaurus – a Docusaurus starter project with TinaCMS(github.com)
github.com
Show HN: Tinasaurus – a Docusaurus starter project with TinaCMS
https://github.com/tinacms/tinasaurus
12 comments
Wow. I've managed docs sites with hundreds of pages on Docusaurus and I could see this being very useful. Is there a way to important what I've already got today? I feel like now that I'm in the mud, it is hard to climb out. Might be more work to use a CMS at this point than keep going here.
Yes,you can use it on existing sites too. Just run the following command to initialize Tina:
npx @tinacms/cli@latest init
npx @tinacms/cli@latest init
Tina is cool and this is cool!
But I wonder: Why is inline editing so unpopular?
You already have a visual editor, based on HTML. Why not put the content within its context to make the WYSIWYG experience complete?
It's definitely possible to blend in, as demonstrated by the Dokuwiki visual editor (https://github.com/fablab-luenen/dokuwiki-visual-editor). You just use normal HTML tags and they're styled by the surrounding CSS no differently than non-editable text.
I would much prefer actually editing the text on the page over what feels like editing the "source text" in a pane on the side. It just takes you so much closer to the content: My website is already well configured to be comfortable to read (and thus write to), but the sidebar editor is definitely not.
Yet I'm not aware of any (open source) project that does this, even though it seems to me like all the required technical components are there.
But I wonder: Why is inline editing so unpopular?
You already have a visual editor, based on HTML. Why not put the content within its context to make the WYSIWYG experience complete?
It's definitely possible to blend in, as demonstrated by the Dokuwiki visual editor (https://github.com/fablab-luenen/dokuwiki-visual-editor). You just use normal HTML tags and they're styled by the surrounding CSS no differently than non-editable text.
I would much prefer actually editing the text on the page over what feels like editing the "source text" in a pane on the side. It just takes you so much closer to the content: My website is already well configured to be comfortable to read (and thus write to), but the sidebar editor is definitely not.
Yet I'm not aware of any (open source) project that does this, even though it seems to me like all the required technical components are there.
I think generally it just muddies the waters from a technical perspective. While it's possible to do a simple version of this quite easily, it's more prone to failure than you would think and anything more complicated than plain text isn't so easy. I think given Tina experimented with this in the past it's likely they'll try to make this work at some point, maybe it's on their roadmap.
Exactly right. We tackled inline editing early on, but it had a lot of hidden complexity. Tina's fields are completely customizable, and if we support inline-editing it would be more challenging to make custom fields work while overlaying the site content. There were also challenges around the inline-editing implementation being very entwined in the user's codebase.
We do hope to circle back to inline editing in the future, we just want to make sure we land on a stable solution.
Thank you! I just found your last blog post on the topic highlighting a few of the issues (https://tina.io/blog/evolution-of-inline-editing/). The solution you came up with looks exactly like what I had in mind!
Are these all the issues you faced? It seems like you mostly solved them, so I'm guessing there were others.
I wouldn't mind having to use the sidebar for secondary fields, I mostly care about the main content field, where I'd spend most of the time. Since (from a cursory glance) you seem to already provide components for rendering Markdown, I don't see a big issue regarding the coupling, at least for my use case.
Are these all the issues you faced? It seems like you mostly solved them, so I'm guessing there were others.
I wouldn't mind having to use the sidebar for secondary fields, I mostly care about the main content field, where I'd spend most of the time. Since (from a cursory glance) you seem to already provide components for rendering Markdown, I don't see a big issue regarding the coupling, at least for my use case.
Yes thanks for the explanation i wanted to link to the experimental package I remember trying
Hi HN, we (tina.io) are big fans Docusaurus so we created a starter project to show how you can best use TinaCMS to edit a Docusaurus site.
Here's a link to the announcement article https://tina.io/tinasaurus
And here's a 5-min overview of the project: https://www.youtube.com/watch?v=2bHBwM54UB8
Happy writing!
Here's a link to the announcement article https://tina.io/tinasaurus
And here's a 5-min overview of the project: https://www.youtube.com/watch?v=2bHBwM54UB8
Happy writing!
Hey, that is a great addition!
Can I use Tina with custom static page generators as well?
Also markdown based but much more primitive than docusaurus.
Here's a guide (using Hugo): https://tina.io/guides/tinacms/non-react-based-ssg/guide/
Yes, you can just point TinaCMS to a directory of Markdown (or MDX, JSON, YML, etc).
Can't wait to give it a spin!