Refactor feature reports to make it easier to add new feature reports #1976
Conversation
This file contains hidden or 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
lfdebrux
force-pushed
the
ldeb-refactor-feature-reports--part-1
branch
from
0c74dc8 to
7e02085
Compare
Contributor
stephencdaly
left a comment
stephencdaly
left a comment
There was a problem hiding this comment.
Really nice improvements that are logically broken down.
I've compared the output of the reports and the CSV downloads with some local data and they look the same after these changes from what I can see.
Just the minor issue around the table formatting when an organisation isn't set for a form that we talked about on slack, but otherwise it's good to go.
Member
Author
Fixed now in Fix organisation name when form is not in group. |
lfdebrux
changed the title
lfdebrux
force-pushed
the
ldeb-refactor-feature-reports--part-1
branch
from
d9c0261 to
6e4152c
Compare
- Add form with routing to fixture - Add more request specs for report CSV downloads - Refactor view specs to remove explicit template - Make it clear what method is being described in Reports::FormDocumentsService specs
Pass head and rows to govuk_table [[1]] as arrays of strings, rather than constructing the table in each view template. This reduces repetition and makes reuse easier. [1]: https://govuk-components.netlify.app/components/table
Remove references to `live` from the report key names, so the code is more generic and reusable.
Rather than call FormDocumentsService inside FeatureReportService and couple those two classes together, change FeatureReportService to expect to be passed a list of form_documents. This also allows in future for the source of form documents (for instance, from live to draft) to be changed without needing to change FeatureReportService.
- Scope routes for feature reports - Make feature report CSV paths more similar to corresponding HTML page paths - Add routing specs Change the paths for routes related to feature reports to be more consistent and neatly scoped together. The purpose of this is to highlight similarities and eventually be more DRY.
Rather than call FormDocumentsService inside CsvReportsService and couple those two classes together, change CsvReportService to expect to be passed a list of form_documents. This allows us to reuse the filtering logic in FeatureReportService instead of reimplementing it in CsvReportsService, lets us change the source of documents in future, and also lets us increases the commonality in the controller actions for rendering a report in HTML and CSV so they might be combined.
Put code for generating CSV of questions into QuestionCsvReportService and code for generating CSV of forms into FormCsvReportService.
Rather than have QuestionCsvReportService extract and filter questions from forms itself, make it expect to be passed a list of question_page documents, so that we can reuse the code in FeatureReportService and reduce duplication.
Rather than having two different controller actions for the same data in two different formats, we can (now that we have made the code similar enough) combine the pairs into one each, differentiating by the format suffix in the request path [[1]]. The main advantage of this is that when adding a new feature report in future there is less to do. [1]: https://guides.rubyonrails.org/routing.html#format-segments
Change the template for each feature report to get the translation keys using a local, rather than the conventional Rails shorthand. The advantage of this is that the templates all start to look the same...
Now that the templates all look the same for routes for feature reports, we can use the same one template for all routes. This means a lot less work needed for adding new feature reports in future.
lfdebrux
force-pushed
the
ldeb-refactor-feature-reports--part-1
branch
from
6e4152c to
fdbd38e
Compare
|
|
🎉 A review copy of this PR has been deployed! You can reach it at: https://pr-1976.admin.review.forms.service.gov.uk/ It may take 5 minutes or so for the application to be fully deployed and working. If it still isn't ready For the sign in details and more information, see the review apps wiki page. |
stephencdaly
approved these changes
May 23, 2025
lfdebrux
added a commit
that referenced
this pull request
May 29, 2025
Rather than going to the reports#live_csv_questions action for the CSV of questions with answer type, we should use the same pattern as for the other feature reports and use the same URL but with a `.csv` appended for the CSV download link on the questions with answer type report page. This commit updates the #questions_with_answer_type action to accept format `csv` as well as `html`, same as the other feature report actions, and uses that in the view template. We can then also simplify the live_questions_csv action. This probably should have been done in PR #1976, but it was missed.
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 problem does this pull request solve?
I wanted to add a new feature report, but I found the feature report code was very repetitive and I had to add a lot of files to do that, and I felt like this situation could be improved. So in this PR, I try to make the feature report code more DRY.
A big part of this is making the responsibilities for each class involved in making a feature report more clearly deliniated and less overlapping, with the controller creating the pipeline to get the final result. It is now expected that FormDocumentsService will be called first, and that passed to FeatureReportService with is responsible just for filtering form documents and optionally converting it into a list of questions. There are helpers that turn this array of form documents or question page documents into a GOV.UK styles table; if a CSV is wanted for the end result,
FormsCsvReportServicegenerates the CSV for an array of form documents andQuestionsCsvReportServicegenerates the CSV for an array of question page documents.This could be taken further still, to the point where adding a new report requires only adding a new method to
FeatureReportService; this PR was split out from #1970.Things to consider when reviewing