RFC: Confusing Render Mode Name

[todd]

Currently, we use the name pre-rendered as the renderMode for retrieving a raw template and data from a registry. I think this name is confusing - I would generally assume that a "prerendered" template would be the same thing as what we're calling "rendered."

I propose that we change the pre-rendered mode name to something more like unrendered. This is a mostly cosmetic change that I think will aid in comprehension of what's actually being returned by that render mode. More than willing to submit a PR if people feel similarly.

This will constitute a breaking change, so we'll probably want to add a deprecation cycle for this behavior.

[Kimtaro]

I was also confused about this, so I'm +1.

[matteofigus]

I agree. We had different ideas, when we started, about the unrendered and pre-rendered. I think that given how things evolved, what we are calling today pre-rendered is what we want to rename as unrendered.

Let me speak with my team and we will try to prioritise this, we need to introduce the change gracefully, for instance:
1a) Upgrade the service in order to accept unrendered as well as Accept parameter to serve unrendered components.
1b) Upgrade the clients in order to start sending unrendered instead of pre-rendered when doing the request for unrendered components.
1c) Upgrade docs.
2) Cleanup the service in order to stop accepting pre-rendered Accept type.

In this way we can upgrade the services, then the clients, then a final upgrade to the service without any maintenance interruption.

Matteo

[todd]

Sounds good. I'm more than willing to pitch in if you want any help.

What's the deprecation policy for this project? Have you guys had to deal with that in the past? I'd imagine that adding code to handle unrendered components while adding deprecation notices for pre-rendered for a major release before ultimately removing it would be the best approach, but I'm not sure how much of a requirement a smooth deprecation process is for this project at this point.

[matteofigus]

Plan for releasing this:

• Make the api able to accept both headers (prerendered and unrendered) to get unrendered
• Update ruby clients to send unrendered instead of prerendered
• Updated node clients to send unrendered instead of prerendered
• Updated client-side library to send unrendered instead of prerendered
• Finally deprecate prerendered in the api and release new version (breaking change)

[matteofigus]

So now I would say we can wait a little while and then finally clean-up the api with the breaking change (return rendered in case of pre-rendered request).

[andyroyle]

will close this issue and create a new one to track the cleanup