Split ComponentDoc into ComponentDoc and ComponentDocResolver #34
Conversation
Split logic for retrieving component documentation from the component documentation itself
* Allows path to be easily changed * Allows this path to be monkey patched by govuk_component_guide * DRYs up templates
There was a problem hiding this comment.
I'm not so sure about the monkey-patching pattern here. It's fragile and requires intimate knowledge of the internals of the class. If we think this is going to happen quite a lot, wouldn't it be nicer to configure the engine with a custom subclass of an abstract ComponentDocResolver? (Obviously with a sensible default concrete class)
| Dir[doc_files].sort.map { |file| parse_documentation(file) } | ||
| end | ||
|
|
||
| def fetch_component_doc(id) |
There was a problem hiding this comment.
So every time we try to access documentation we have to perform multiple file operations? Feels a little bit icky; could potentially memoise this stuff at a static level? Although given that this is all just internal code used by developers, maybe we don't have to worry about it too much.
There was a problem hiding this comment.
I want to make it faster, and memoising makes sense. As this is predominantly a tool for developing components we need to balance that with the problem of too much caching hiding local changes.
There was a problem hiding this comment.
Makes sense to me. Not sure we'd notice much of a performance change, anyway.
| component[:body], | ||
| component[:accessibility_criteria], | ||
| fixtures) | ||
| class ComponentDoc |
There was a problem hiding this comment.
Why have we moved away from a Struct? It looks like we've just wound up with more boilerplate code. To make it immutable? We could use something like immutable-struct?
I see it happening once, for static components that are different. But I like your idea of a subclass component resolver within the gem. I've been monkey patching as a proof of concept. We're also considering retiring |
If that's the case, then do it however you think is best - if it's just for one special case, a whole inheritance system may be overkill. |
|
Thank you for the review @alecgibson ⭐️ |
A small refactor to switch from structs to classes.
Specifically:
Addresses some of @alecgibson’s original review comments in #1 (comment)