Pre-parsed toView representation, which still knows the toData section a given rule originated from. This allows to handle toView mappings from the same toData element (from default and custom config) in a different way, then those, which exist in parallel, i.e., those, which were created by different toData nodes.

The suggested approach is to merge mappings originating from the same toData elements hierarchically, while those from different toData nodes will be merged sequentially. Or, from the perspective of the rules: For hierarchical rules, a rule can block the other (parent), while in sequential execution they all exist with the same priority in parallel.

The mapping is as follows:

  • toView key (i.e., data element to transform)

    • toData key (i.e., original toData section)

      A special key " " (single whitespace) is used for those toView mappings, where no corresponding toData mapping exists.

interface PreParsedToView {
    elements?: PreParsedElementSection;
    text?: TextFilterRule;
}

Properties

Properties