Conversation
Adds and use models for HazardStep form controls: - OrgRiskRelativeOption - OrgRiskDirectionalOption
fungjj92
left a comment
There was a problem hiding this comment.
Overall lookin good! Thanks for providing ample explanation in your PR post and in code comments. See my comments!
| @@ -29,8 +29,12 @@ export class RiskWizardComponent implements AfterViewInit, OnDestroy, OnInit { | |||
|
|
|||
| ngOnInit() { | |||
| // TODO: Set initial risk from API | |||
There was a problem hiding this comment.
Is there an issue you can attach here? Perhaps #324
| <button type="button" previousStep>Back</button> | ||
| <div class="step-header"> | ||
| <h3>Hazard</h3> | ||
| <h5>{{ risk.hazard }}</h5> |
There was a problem hiding this comment.
This is blank because the controller doesn't have a this.risk. I was having trouble myself accessing data from other wizard steps. It is available via this.session._data.KEY but exposing a protected object is not ideal. I have yet to play with a getKeyData() on wizard-session.service but I am skeptical that it would work.
There was a problem hiding this comment.
Issue here was actually a miss from changes in #322 that tweaked the Risk model. This binding should be risk.weatherEvent?.name. I'll update.
Not sure what you mean by trouble accessing the risk data, perhaps we could pair on that briefly to better identify the problem you're having, as that seems separate from this PR.
There was a problem hiding this comment.
Oh i guess i missed that too hah.
|
|
||
| public directionalOptions = OrgRiskDirectionalOptions; | ||
| public relativeOptions = OrgRiskRelativeOptions; | ||
| // Can't *ngFor a map type or iterable, so instead we realize the iterable and use that in *ngFors |
There was a problem hiding this comment.
stanks but useful comment
| import { WizardStepComponent } from '../wizard-step.component'; | ||
| import { WizardSessionService } from '../wizard-session.service'; | ||
|
|
||
| interface HazardStepFormModel { |
There was a problem hiding this comment.
put in it's own file? the identify step form model is in it's own file. It's exceptionally unlikely that this model will be used anywhere else independently so fundamentally I'm not opposed to this being here, but we should be consistent either way.
There was a problem hiding this comment.
Good catch and good point. Given that this is for now a private interface on both components, I'll probably move the one in identify back to the component and remove the exports on these.
| <h3>Identify risk</h3> | ||
| </div> | ||
| <div class="step-content"> | ||
| <p>Match a hazard to a subset of people, strucutres or assets (sometimes referred to as a "community system") that the selected hazard may impact</p> |
| </form> | ||
| </div> | ||
| <div class="step-footer"> | ||
| <button type="button" [disabled]="!form.valid" nextStep (finalize)="save()">Continue</button> |
There was a problem hiding this comment.
i think the buttons are generally considered part of the <form>
There was a problem hiding this comment.
Generally yes, if they directly interact with form events, like a form submit button. That's not the case here though, these buttons are a part of wizard navigation not the form itself.
| </div> | ||
| <div class="step-form-control"> | ||
| <h5>Intensity <span class="icon icon-question-circle-o" tooltip="{{ tooltipText.intensity }}"></span></h5> | ||
| <div class="btn-group"> |
There was a problem hiding this comment.
Whoa. Weird. The actual issue is that you can't select a button to the left of one you've already selected. That's new. Will fix.
I don't think the implementation of button vs button group really matters aside from button group is more semantically correct (since it enforces only one selected at a time) and we can separate the buttons with CSS. I'll play with it either way.
There was a problem hiding this comment.
Well look what I found: valor-software/ngx-bootstrap#2581
Guess I'll switch to a standard button implementation real quick.
There was a problem hiding this comment.
Didn't address button spacing. That's fairly straightforward and can be addressed later in a styling pass.
|
@fungjj92 ready for another look. |
The ngx-bootstrap button group btnRadio directive is busted for reactive forms, so we just implement directly with events for now instead: valor-software/ngx-bootstrap#2581
In shared module
If form is untouched
75f13a1 to
70cf0a8
Compare

Overview
Adds functioning step two of the Risk Wizard in the Vulnerability Assessment.
Demo
Blank form for new risk (continue disabled)
OptionDropdown open to select probability
After selecting other items (continue enabled once one form control changed)
Continue to next step (selections printed to console.log on navigation)
Back to previous step (form selections saved)
Notes
I added models for the Directional and Relative options sent by the API. The enum/maps for each of those felt like the most straightforward, if a bit verbose way to get proper typecasting. It's not possible to use a string enum (effectively a typed Object) as a standard JS Object key until typescript 2.6. As a result, maps are a bit more verbose than objects, but effectively the same.
I added the OptionDropdownComponent in the SharedModule. Should be ready for use by any other app components that need it.
I renamed the to/from abstract handler methods in WizardSessionService to use "model" instead of "data" for a bit more clarity about which method is which. I also removed all remaining references to Risk in the WizardSessionService and WizardStepComponent.
In an effort to be continually refactoring, I moved scss files for components that are declared in the SharedModule to a new folder
sharedinside the sass components directory.I added some generic classes for each wizard step to use, see identify and hazard step HTML for examples, each wizard step now has a
step-header,step-contentandstep-footerclass. Added some basic padding to make the step HTML elements not so scrunched, these can be updated, tweaked, whatevered by @alexelash later.I updated the archwizard to color the navigation step circles in the wizard nav sidebar to match what (I think) made sense for our application. Again, these can be updated by @alexelash later.
Assigned @fungjj92 because she'll be here next week, but probably worth it for @maurizi and @flibbertigibbet to at least take a look as well. The models added here for the API choices should unblock fixing the adaptive need boxes as part of #322.
Testing Instructions
Closes #236