WIP merge hardcoded bits content into content items #3775
Conversation
... todo - actually render them
|
I think that rather than hard coding the content into a rendering app, it should be put into a publishing app. The work in the rendering app could then be focused on rendering the extra fields from the content item as usual. This is similar to the approach we took for sign in pages. Though in that case, there wasn't an existing content item that needed to be extended. There are things to work out, such as what the publishing workflow will be for any content changes, but it means that we'd be adding far fewer hacks to the system for content item changes that are expected to be permanent. |
| <% @organisation.content_extensions&.each do |content_extension| %> | ||
| <%= render partial: "content_extension_#{content_extension["document_type"]}", locals: { content_extension: } %> | ||
| <% end %> | ||
|
|
There was a problem hiding this comment.
If there are multiple "hub" like pages that behave a bit like parts, it'd probably be better to render this new type of content in frontend, that already handles parts.
There was a problem hiding this comment.
I'm assuming we're adorning the existing organisation pages with some extra components here. Appreciate that might not be the approach we end up taking though.
I think there's advantages to each approach. The big advantage of having the content in the frontend app is that it can change at exactly the same cadence as the ERB templates that render it. So changing the structure of the content and the structure the template expects can be done in one commit. If we put the content anywhere in the publishing system, there's more coordination needed - changes to the structure of the content item need to consider backwards compatibility with the current version of the frontend, and even if we don't mind breaking Clearly we eventually need the content to be in the publishing system, but having it directly in the frontend on day 1 feels like it could be a big advantage while the design / structure might need to change rapidly.
Eventually, yes. Or we could use a generic bit of the schema where anything is allowed (which we'd have to add once, but then wouldn't need to keep updating).
That's true. The approach in this PR won't get the content into search, so I'd be chalking that up as a problem for later (basically when we eventually do move the content into a publishing tool, after its structure has crystallised). Search mostly just includes the body of pages (as I understand it), so actually the sorts of components I'm thinking about here (featured documents, video embeds, hero images) might not make it to search even then.
I wasn't involved in the sign in pages, so I'm not sure what the approach we took there looked like. I think most of the work here will still happen in the rendering app, looking at extra fields in the content item - it's just we'll also be hardcoding the content here.
I think we're just talking about two different places to put the same hack 😅 - it's hardcoded content, whether it's hardcoded in Whitehall or Collections. I don't having it in one place or the other results in fewer hacks. For me, it's a tradeoff between:
Given the need to deliver quickly, I'd vote for the hardcoding things in the frontend. |
|
Sorry about the unfinished sentences in my comment yesterday 😅 - Rory was barking in my face. I've added some screenshots which show that this approach "works" (although obviously it's not a particularly good implementation of a hero image component, even if the image itself is very good). |
|
To be honest, I think this is all a bit premature as we don't have any designs yet and it's likely that we're going to have to render multiple linked pages. Saying that, it's very easy to make things extremely flexible by hard-coding directly into the frontend, and then struggling later to apply that flexibility into the publishing app. We struggled with this on the COVID landing page, when we had to reduce flexibility of the sections to move it into collections publisher. I think timeline section was never moved for this reason. I do think we should be using the content schemas to restrict how the data is presented so that we don't have to "take away" flexibility later. |
|
Closing this as it's just us scratching ideas together. |
Work in progress mechanism for extending content items with hardcoded content in collections.
This approach is being considered for a project that's currently
[OFFICIAL], so I can't give full details of the use case. If you know, then you know. If you don't know, then don't worry. If you worry, you just suffer twice.Opening this early as a draft to facilitate discussion of the general approach. There's a bit of not-very-good explanation in the READMEs I've added.