expectation's description
set of optionals expectations provided as a mapping using a given name
set of required expectations provided as a mapping using a given name
Contract
Generic expectation creator, companion creation function of BaseExpectation.
expectation's description
normalizing function for fulfilled case
either a condition that returns true if the expectation is fulfilled or an expectation
BaseExpectation that resolve eventually to a type T
Companion creation function of AllOf.
The type of FulfilledExpectation.value, i.e. the type of the expectation return's value (normalized value) when the expectation is fulfilled
description of the expectation
normalizing function
array of children expectations
AllOf expectation
Companion creation function of AnyOf.
The type of FulfilledExpectation.value, i.e. the type of the expectation return's value (normalized value) when the expectation is fulfilled
description of the expectation
normalizing function
array of children expectations
AnyOf expectation
Companion creation function of ExpectAttribute.
The type of FulfilledExpectation.value, i.e. the type of the expectation return's value (normalized value) when the expectation is fulfilled
name of the attribute
expectation to test on the target attribute
ExpectAttribute expectation
The function expectCount aims at ensuring that exactly count elements in some inputData are fulfilled with respect to a given expectation.
The expectation get fulfilled if both:
In that case, the normalized data is an array containing the normalized data of the elements fulfilled. (of length count)
the expected count
the expectation
BaseExpectation that resolve eventually to a type T[] of length count
Companion creation function of [[NoExpectation]]
an expectation that expects nothing and to do not apply any data normalization
The function expectInstanceOf aims at ensuring that at least one element of target instance type exists in input data.
The expectation get fulfilled if any of the following get fulfilled:
In that case, the normalized data is the instance of Type retrieved.
the target type
candidate attribute names
display name of the type
BaseExpectation that resolve eventually to a type T
The function expectSingle aims at ensuring that exactly one element in some inputData is fulfilled with respect to a given expectation.
The expectation get fulfilled if either:
In that case, the normalized data identifies to the one of the when expectation.
the expectation
BaseExpectation that resolve eventually to a type T[] of length count
The function expectSome aims at ensuring that it exist at least one elements in some inputData that are fulfilled with respect to a given expectation.
The expectation get fulfilled if either:
In that case, the normalized data is an array containing the normalized data of the elements fulfilled.
the expectation
BaseExpectation that resolve eventually to a type T[]
Generated using TypeDoc
Introduction
Contract is an important concept of Flux, we provide here an introduction about the motivations and the benefits. Still, this may not be a must read for a first pass over the documentation (contract are optional anyway).
In Flux there is no limitation regarding the connection between modules: any module's output can be connected to any other module's input.
It follows that the data part of a Message reaching a module's input is literally unknown.
Contracts are introduced to both:
The latter point is important to keep in mind when designing modules as it allows to decrease friction on modules connectivity (meaning decreasing the need of adaptors).
Contract formalize two mechanisms:
More often than not, modules need similar validation/transformation schemes within variations. That's why the formalism provided to define contracts has been designed to be easily composable.
Illustrative example
Let's consider a module featuring one input triggering an addition between two numbers when some data comes in. A naive implementation would look like this:
The problem with this implementation is that it only works if the data reaching the module is an array with at least 2 elements, and with a first and second element matching a number. In other cases the process execution will most likely result in an error with not much context for the consumer of the module to understand.
Using a contract we can start formalizing the input's expectation:
This updated version already provides 3 benefits : pre-conditions check, data normalization, failures reporting.
We can still improve the case study by extending the definition of numberConcept: we would like to handle strings that are valid representation of numbers, and also permit objects with a value property compatible with a number (straight or as a string).
With this new implementation, the module now accepts quite a large range of input data (e.g.
['1',2], [{value:1}, {value:'2'}]
), and will fail 'gracefully' otherwise. Despite the number of possible combinations in terms of accepted inputs, the triggered function still get a nice and unique[number, number]
parameter 🤘.The library provide another layer above expectations to go a (last) step further.