Suggested View contact details changes #1011
Merged
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
https://eaflood.atlassian.net/browse/WATER-4433 This relates to [Add View Licence contact details page](#993). What started as experimenting with an alternate fetch implementation has grown into a detailed comparison of the original changes and our current patterns and conventions. In this we have tried to highlight how we think the changes would be implemented if they followed our current norms. These are suggested and can be challenged. But we felt in this case "show don't tell" would be more appropriate to support the conversation!
Cruikshanks
force-pushed
the
alans-view-licence-contact-details-page-2
branch
from
92cc368 to
0854af3
Compare
jonathangoulding
approved these changes
May 13, 2024
Cruikshanks
merged commit a82c048
into
view-licence-contact-details-page
3 of 4 checks passed
jonathangoulding
added a commit
that referenced
this pull request
May 13, 2024
* Add View Licence contact details page https://eaflood.atlassian.net/browse/WATER-4433 https://eaflood.atlassian.net/browse/WATER-4434 The existing service handling view licence is slow because it loads all the data for the tabs in one render. Work has been done previously to refactor the summary page to load only the summary information. This change will introduce a contact details controller, service and presenter to handle the view licence contact details page. This will share the same view as the summary page and load the same 'common data' established in [previous work](#957). PR made to optimise the fetch service for the licence contact details Suggested View contact details changes (#1011) In this commit, we have tried to highlight how we think the changes would be implemented if they followed our current norms. - corrections - adding line breaks, extensions to module imports, parens and block body for arrow functions - fetch logic - switching from Objection to Knex directly. Where we are fetching data from various tables to provide a summarised view, and not intending to interact with the instances other than that, dropping to Knex can make things easier and remove the need for additional logic in presenters services - single responsibility - switching the basis for the modules to be single-responsibility. The ViewService will be responsible for fetching and presenting the data for the whole tab. But assume fetching and presenter licence contacts versus customer contacts will be different hence rename/update the fetch and presenter to be licence contact-specific --------- Co-authored-by: Alan Cruikshanks <[email protected]>
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.
https://eaflood.atlassian.net/browse/WATER-4433
This relates to Add View Licence contact details page. What started as experimenting with an alternate fetch implementation has grown into a detailed comparison of the original changes and our current patterns and conventions.
In this we have tried to highlight how we think the changes would be implemented if they followed our current norms.
These are suggested and can be challenged. But we felt in this case "show don't tell" would be more appropriate to support the conversation!