QC Hub and Interview Documentation
- Iteration X made no modifications on the QC Hub and Interview portions of the package.
-
Data Factory Implementation - Iteration 6
Click Me!
ITERATION 6 Again, not sure why most aren't used. We found it like this
Note: SOMEONE ADD NOTES on creating data to test with Where is UpdateCohortEvent? Where is QCInterview Start? Where is QCInterviewQCDisplayWeek?
Lightning Web Components 
Updated Iteration 6
- d3ChartTest
- data.js
End-of-Project Ideas, Thoughts, and Notes on Future Development:
- Info & Display panels could be added to the interview process, displaying relevant information about the hero (Past scores? Exam scores?)
- Data and functionality related to squads could be expanded. QCCohortWrapper (main data structure class for Cohort data that's passed in from the server) already has a squadMap member variable that maps squad names to a list of heroes in that squad; this could either be changed to a Squad__c object (not sure whether or not that will work in JavaScript methods) or Squad Id, or left as is, to retrieve heroes that are in a particular squad. Conversely, depending on what's required, a map could be used to retrieve squad names for heroes. An <Id, Id> map could also simply be used between a list of all heroes in the cohort, and a list of squads in the cohort We did not get around to implementing any squad-related functionality, but based on our work thus far some form of map would probably be the best way to connect heroes with their respective squads. Further note: Previous versions of QCCohortWrapper used a sub-wrapper class called QCSquadWrapper to store a squad and list of heroes in that squad, but this might make it difficult to iterate over when it comes to lightning aura tables. Maps are probably the best option.
- sessionStorage is currently used to pass cohort data from QCHubHome to QCInterview when the interview is launched. This may or may not be reliable for large data sets, and it may prove better to pass an ID and retrieve cohort data via an additional server call. On the other hand, this increases server calls - somewhat unnecessarily
- Given enough experience with d3, some very fantastic, useful, and informative visual displays could be created on QCHubHome. The backend for retrieving, storing, and working with this data is (mostly) there - aura:if could be used to display/hide CohortStatistics, depending on whether or not a cohort has been selected, and display overall data instead. Since the selection made by CohortButtons determines which specific set of records is retrieved from the server (but the type of records is the same), d3 method(s) can be written that will display data from those records in charts
- QCInterviewCohortSelection could simply launch InterviewHeroEvent, causing handlers on QCInterviewStartView to fire UpdateStageEvent and SetWeekEvent, and then propagate to QCInterview to set the hero there instead of the current process (CohortSelection launches InterviewHeroEvent and UpdateStageEvent, then StartView launches SetWeekEvent and StartInterviewEvent, somewhat redundantly)
- It may be possible to implement score auto-calculation by using a record page - the pagereference in QCInterviewEnd already routes to a record page for the finished interview, which displays a score; this can be edited directly on the page, and validation rules can be used to enforce providing a reason for the override. The score could be auto-calculated in the Apex call when it is sent to the database, or in a JS method before that. However, this still leaves flag implementation and re-routing back to the hero selection screen: flags could be added as a related list on the lightning page, while rerouting may require overriding a button or using Lightning App Builder.