add property for disabling validation on visibility change #399
Conversation
|
Let me know if you would like me to add any tests around this. I didn't see any existing ones so I wasn't sure where to put them if I should add any. Assuming you are ok with the change. |
|
Changes Unknown when pulling 7c49088 on PoplarToppler:master into ** on ciena-frost:master**. |
|
@PoplarToppler it'd be nice to see some tests, even if it is just a few unit tests against the |
|
Sorry I have been super busy. I will get back to and finish this soon. |
|
I'm not sure where I should put these tests, @job13er can you give me a recommendation? Thanks! |
|
I've also pretty much stopped using bunsen now as well (no more data driven requirements) so I'm not sure I'm the best person to review this. Do we have someone who is going to step up as primary maintainer with Matt gone? |
|
We will, but we're not in a position to do it until later in June |
|
@agonza40 @sophypal do either of you have suggestions of where I could put a few tests for this new property? I'd ideally like to get this in soon. My best guess is I'd add a new file: tests/unit/components/frost-bunsen-form/on-visibility-change-test.js and go from there. Does that sound acceptable? |
|
@PoplarToppler Typically we model the test directory against the src directory. Since there is very little unit test (due to favoring integration in this project), you'd need to add |
| onChange () {}, | ||
| onError () {} | ||
| }) | ||
| component.init() |
There was a problem hiding this comment.
You shouldn't need to call init here as this.subject calls it indirectly through instantiation.
|
Changes Unknown when pulling 70fe0d0 on PoplarToppler:master into ** on ciena-frost:master**. |
|
👍 |
|
Changes Unknown when pulling 238d746 on PoplarToppler:master into ** on ciena-frost:master**. |
This project uses semver, please check the scope of this pr:
The motivation behind this is that when using the form for facets with validation, I am using onValidation to trigger the server request so that I am able to block invalid filters (e.g. invalid date range) while still allowing the query to succeed.
The problem is that if we want to freeze the current view (e.g. stop polling), then go to another tab (e.g. new details tab) then return to the original view, a new query is triggered due to the validation of the form being triggered on visibility change. This ends up changing the view that was supposed to be frozen.
CHANGELOG