-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add View Licence contact details page #993
Conversation
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).
duplicate logic from old system: - work out the customer id for the page link to customer page - no licence holders message restrict data from fetch contact details service
use single query connect graph fetched using the table name as the base
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Putting this in just to record I'm still looking at this PR rather than this is all I found!
I'm digging into the Fetch as behind the scenes I can see it's running some big queries but I need a sec to get a handle on what it is currently doing before I feel I can pass any judgement.
Co-authored-by: Alan Cruikshanks <[email protected]>
…details-page # Conflicts: # app/controllers/licences.controller.js # test/controllers/licences.controller.test.js
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!
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!
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!
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!
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!
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
https://eaflood.atlassian.net/browse/WATER-4433
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.