3 ms·

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-ed

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.

tough 4y ago
Yes thanks for the explanation i wanted to link to the experimental package I remember trying
solarkraft 4y ago
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/ 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.