Local content item support #4366
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
KludgeKML
force-pushed
the
local-content-item-support
branch
from
f68df37
to
8c2506a
Compare
leenagupte
reviewed
Nov 7, 2024
Comment on lines
+27
to
+33
| def local_json_filename(base_path) | ||
| Rails.root.join("#{LOCAL_ITEMS_PATH}#{base_path}.json") | ||
| end | ||
|
|
||
| def local_yaml_filename(base_path) | ||
| Rails.root.join("#{LOCAL_ITEMS_PATH}#{base_path}.yml") | ||
| end |
There was a problem hiding this comment.
I think these need to do the same switching of _ and - that the landing page model does.
|
|
||
| To support this, set: | ||
|
|
||
| `ALLOW_LOCAL_CONTENT_ITEM_OVERRIDE=true` |
There was a problem hiding this comment.
It'd be good if there was an accompanying change in govuk-docker that sets this.
| # SCAFFOLDING: can be removed when basic content items are available | ||
| # from content-store | ||
| def old_scaffolding_content_item | ||
| ContentItemLoaderGdsApi.content_store.content_item(request.path).to_h |
There was a problem hiding this comment.
This doesn't look right. There isn't actually a class called ContentItemLoaderGdsApi is there?
The tests are passing, so either this is fine somehow, or this bit of code is not being tested.
- ContentItemLoader replaces direct calls to GdsApi.content_store.content_item, (of which there are only 4 in the rest of the codebase), and provides two functions. - First, it centralises caching of calls, so that that can be removed from the FormatRoutingConstraint classes and using request.env to save those values can be simplified. - Second, if the ALLOW_LOCAL_CONTENT_ITEM_OVERRIDE env var is set true, it allows loading content items from a file in /config/local-content-items, which gives developers an extra option for local development or preview apps when working with content types that have not crystalised yet or where publishing support is not yet present. It should not be used in production. - The load method is slightly odd in that it will either return an API response or an exception (note: return the exception, not raise it!). This allows us to cache errors in a similar way to the way the routing constraints used to. It might be there are better ways to handle this, but for the moment this is a minimal change to maintain the current behaviour.
- Because the cache is at class level, it's very aggressive and would otherwise interfere with what people would normally expect about tests (ie that in two unrelated tests you could use the same slug to point to different things). So we default here to just clearing the cache before each test.
- Now that ContentItemLoader is handling the caching, we can remove that layer of code / responsibility from the constraints. - ContentItemLoader either returns the adapter response or the error that it caught, so querying for those classes gives us a "was it or wasn't it an error" check. - We also simplify the spec tests slightly to use more idiomatic RSpec.
- Now that ContentItemLoader handles caching we can use that rather than the stuff that the format constraints were putting into the request env. - LandingPageController's scaffolding is still needed for the moment, but we can remove it soon (since part of this project is about replacing that scaffolding with a more generally useful one).
KludgeKML
force-pushed
the
local-content-item-support
branch
from
8c2506a
to
b1cffa4
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What
Adds more structured support for loading content items from the local machine. By setting an environment variable and putting a content item in a particular directory, it will be loaded from that file instead of from a call to the content store.
Why
There's currently a restricted version of this code working for Landing Pages (it only loads the blocks from the fixture, but includes fake values for the rest of the content item). This scaffolding has proved useful during Landing Pages development, but it's limited in scope and only works for Landing Pages. By replacing it with a more robust option, we can improve developer experience in the absence of a local version of content store, and make it easier to demo experimental content items on Heroku.
How
We add a new singleton class (ContentItemLoader) that is responsible for calls to GdsApi.content_store.get_content - this allows us to have a cache of items (simplifying the current Format Constraint code, which caches responses in the request env field), and to have a single point where those calls can be intercepted and swapped out for local code if the required environment variable is set. Setting ALLOW_LOCAL_CONTENT_ITEM_OVERRIDE to true will cause the loader to look in /config/local-content-items/path/to/the/item for any call to the content store (falling back to an actual call if the file isn't present).