This blog post continues (maybe a bit repetitiously) the rant that I started at https://deliverystack.net/2020/07/21/contentful-net-sample-entry-model/. In that post I mentioned some of the implications of Contentful’s representation of the value of Rich Text Fields in a proprietary JSON format rather than XHTML, and some of the technical implications of that implementation. I understand the intention, but it is unnecessary. This blog post lists some additional reasons why I object to the approach taken by this vendor for this feature.
As a (.NET Core) (web) Content Management Systems implementor, in my primary and possibly only use case for retrieving a value from a Rich Text Field, there is not a single condition under which I would prefer to retrieve JSON in a custom format rather than markup in a standard format. If I want to embed custom data in the markup, I can use custom XML elements and attributes, XML comments, JSON embedded in <script /> elements or otherwise, or other features supported by markup. If I want to transform data in the markup, for example to open all links to external sites in new browser tabs or ensure that images have proper attributes, I can use HtmlAgilityPack (https://html-agility-pack.net/).
So it looks like I have to use vendor-specific types or expose vendor-specific formats and consume additional computing resources. Then after I get the data, I may need to pass it to HtmlAgilityPack and back to HTML, which is going to cost me even more. All for the most common, basic, and trivial functionality. And what if I were to actually use that JSON format, and then switch vendors? What would I do with this JSON from another technology, such as JavaScript, and why? The custom JSON format smells of vendor lock-in as exposed by vendor-specific classes in the CMS SDK used to model and process its value. I have at least the following concerns:
- Even if the JSON format is efficient, this must increase the RESTful API payload size to retrieve an item, as well as memory consumption (especially if I want to cache this data before and after converting it to HTML) and CPU time for transformation. I wonder if this format could be efficient in the vendor’s native storage system or for specific search/indexing or other scenarios.
- I do not want to expose or even use the vendor’s proprietary JSON format or SDK in my Entry Models.
- I want to use the same Entry Model classes regardless of the CMS.
- I would prefer to avoid adding additional layers of complexity.
- Maybe I can implement a JsonConverter that transforms the JSON while populating the Entry Model, but I do not want to convert the JSON representation of the markup to…markup unless something needs to use that markup, so not until rendering. Maybe I can use a closure to defer rendering and still avoid direct access to the Contentful SDK.
- What if I want to import existing HTML? Should I convert it to this JSON format, store it to a plain text field, or what?
- What additional vendor-specific issues might I face working with this product now or in the future?
At the very least, Contentful could provide an option to perform the transformation on their end, before returning the Entry.
Actually, I have one other use case for retrieving a Rich Text Field, which is when that Field contains markdown rather than markup. Markdown is a standard format and is very worthwhile for the CMS users that prefer it. In this case, something needs to transform the markdown to markup. Markdown does not require vendor-specific code, use vendor-specific data formats, or require vendor-specific implementation knowledge.
- https://www.contentful.com/developers/docs/tutorials/general/getting-started-with-rich-text-field-type/
- https://www.contentful.com/blog/2020/06/26/behind-the-scenes-of-the-contentful-rich-text-field/
- https://www.contentful.com/developers/docs/javascript/tutorials/rendering-contentful-rich-text-with-javascript/
Deliverystack.net 
One thought on “Some [More?] of the Reasons Why I Do Not Like How Contentful Represents Rich Text Fields”