Classifications often yield scalar results. Since those results are
used directly in the diff, we have the situation where the expected
diff format (an array) is not provided. Consistent with the rest of
the system, we should consider a scalar to affect every index.
* src/validate/ValidStateMonitor.js (_checkCauseFix): Consider scalar
diffs to affect every index when checking for fixes.
* test/validate/ValidStateMonitorTest.js: Add test.
Previously, the system relied on the preStagingUpdate StagingBucket
event to do this implicitly, but that is no longer kicked off when
the diff doesn't produce any bucket changes.
* src/client/Client.js (_createProgram) [dapi]: Clear validation
failures on dapi fieldLoaded.
The intent of this is to allow for clearing errors after fields
load (e.g. a "field loading" message if the user attempts to continue
past the step when a field hasn't yet finished loading).
* src/dapi/DataApiManager.js (getApiData): Emit fieldLoaded after
request completes.
* test/dapi/DataApiManagerTest.js: Add test case.
DEV-2299
This was not properly chain the promises---it was always chaining on
the original _pending (so, the first request) and never clearing
_pending after that point.
* src/validate/DataValidator.js (_onceReady): Properly chain.
* test/validate/DataValidatorTest.js: Updated test. Don't ask.
This does two things:
- Ensures previous validation requests are complete before
processing another, preventing internal state from being screwed
up; and
- Prevents empty diffs from triggering staging bucket events, which
is both a performance benefit and stops ValidStateMonitor from
getting confused and immediately marking failures as fixed in
certain circumstances.
This fixes accidental global variables and enables strict mode to
prevent it in the future.
* src/bucket/StagingBucket.js: Enable strict mode. Use const/let where
appropriate instead of var.
Since changes trigger any event observers---which can be
expensive---it is ideal to ignore sets that do not result in any
changes to the bucket.
This also resolves issues with systems that are confused by empty
diffs.
* src/bucket/StagingBucket.js
(_hasChanged): Add method.
(setValues): Use it.
* test/bucket/StagingBucketTest.js: Add test case.
DEV-2299
Since we maintain state (as a kluge for the time being to integrate
with the rest of the system), we need to be careful to protect against
concurrent requests that might mess with it before the original
request is complete.
* src/validate/DataValidator.js
(validate, updateFailures): Hold concurrent requests.
(_onceReady): Add method.
* test/validate/DataValidatorTest.js: Add tests.
This allows for testing assertions. It's fairly primitive, but will
work for the time being.
* src/test/README: Add file.
* src/test/program/DummyClassifier.js: Add module.
* src/test/program/Program.js: Add class.
* src/test/program/util.js: Add module.
In practice, not clearing the store and allowing it to use previous
state has the effect of instantly "fixing" failures if there happens
to be more than one validation call.
This was a log of debugging for a one-line change.
* src/validate/DataValidator.js (_populateStore): Always clear store.
* test/validate/DataValidatorTest.js: Add test.
DEV-2299
I updated DataValidator but never updated the caller. Damnit. It's
an unfortunate side-effect of dynamic, loosely typed languages and
mitigating it requires what should be boilerplate functional tests (in
this case---functional tests are useful for many other integration
aspects).
* src/event/FieldVisibilityEventHandler.js
(handle): Use updated DataValidator#clearFailures API, which has
a different descriptor format.
* test/event/FieldVisibilityEventHandlerTest.js: Update test.
Previous work was done to have field errors clear when any
classification in the assertion stack changes. The last remaining
piece was to have field errors clear when the field itself is no
longer applicable.†
- Handling in `Client` was replaced with
`FieldVisibilityEventHandler`. The event system already existed.
- `DataValidator` and `ValidStateMonitor` just needed the ability to
clear specific fields (`#clearFields`).
† Technically the "hide" in liza means "not applicable"; I've been
using that new terminology, but this event can't be renamed right now
because it's so heavily used.
This is a separate program of sorts that sits alongside and hooks the
Client.
* src/client/debug/AssertionClientDebugTab.js: Add class.
* src/client/debug/BucketClientDebugTab.js: Add class.
* src/client/debug/CalcClientDebugTab.js: Add class.
* src/client/debug/ClassifyClientDebugTab.js: Add class.
* src/client/debug/ClientDebug.js: Add class.
* src/client/debug/ClientDebugDialog.js: Add class.
* src/client/debug/ClientDebugTab.js: Add interface.
This thing is an ugly monstrosity that has witheld some pretty rough
development times. As code is touched, it is being removed.
This depends on many things not yet in the liza repo; they'll be added
in time.
These classes were changed slightly to work within liza (e.g. paths).
* src/client/Client.js: Extract from rating-fw
as of 5d4019f1973f9271f4b1bd24ce1f55b56ccda09e.
* src/client/ClientDependencyFactory.js: Extract from rating-fw
as of 5d4019f1973f9271f4b1bd24ce1f55b56ccda09e.
LoVullo dropped support for IE<9, so getters can now be used to
lazy-load modules.
This also means that, during the transition from LoVullo's internal
rating-fw repo to liza, and broken require paths (program/, mainly)
will not cause problems unless the module containing those requires is
explicitly requested.
* tools/gen-index.js: Generate getters.
The individual commits contain more useful detail, but since there's a
lot of _new_ code, you might be okay with looking at the full diff.
This adds support to Liza for considering classification changes when
detecting field fixes. It can be boiled down to: abstract the bucket
diff array into a `Store`, which can also handle classification diffs,
and have `ValidStateMonitor` check that instead of the original
array. The diff data format is unchanged.
- The diff portion of it comes together in `system/client.js` where it
constructs the Store.
- `ValidStateMonitor` is what performs the validations, and existed
previously; it was modified to support Promises and be
async. `DataValidator` extracts some logic (much less than I had
hoped to) from `Client` in the `rating-fw` repository and glues it
together. If it doesn't look coherent, that's because the process
is a bit of a mess; the overall architecture _did not_ change with
this.
A lot of the project design changed or was abandoned upfront before
code was written: I committed my design notes in the new `liza-notes`
repo. It notes a lot of my thoughts and design decisions, and shows a
lot of what was abandoned or simplified.
* src/validate/DataValidator.js
(validate): New `classes' parameter. API BC break from previous
commits.
(populateStore, updateFailures): Generalize methods.
* test/validate/DataValidatorTest.js:
Add associated test.
Refactor existing tests to adhere to new API/expectations.
DEV-2206
See the description in the test case. This is a bug fix.
* src/validate/ValidStateMonitor.js
(_checkCauseFix): Do not consider an empty diff on a past failure to
be a fix.
* test/validate/ValidStateMonitorTest.js: Add test.
DEV-2296
Mike Gerwitz