What's Next

The What's Next is a - let's call it - a pattern, intended for moving control over data collection from client apps, to backend. This allows clients to focus on presentation of independent sections of such forms without knowing what is the order of sections, what are the branches, validation rules etc.

DataChunk

All the aforementioned sections are represented as data chunks. For example an address form can be a data chunk, a drop-down would be another, a single checkbox for terms and conditions agreement is also one. Some sections can be only providing block of text, e.g. additional information or explanation, would be a read-only data chunk. Such sections can be linked with other sections, for example - when in parent section specific value is selected, a new subsections will appear.

Each of data chunks, is composed of two elements: specification and interaction interface.

The specification, informs client application what are the requirements of that data chunk, is it required, optional or completed, and no interaction from user is needed. It can contain list of fields (and their requirements) for which data is collected, a list of options to choose from and so on.

The interaction interface tells what can be done with chunk, and it can be defined as two types: immutable and mutable. The immutable data chunk, presents just data to the client application, for example a cost breakdown based on already provided data. The mutable data chunk provides additionally methods to validate, submit or clear/remove data.

Both interfaces use few types in their definitions, in order of appearance those are:

• ID - type of the flow identifier, that chunk is referencing to, eg. Int, UUID, or OrderId that refers order user is placing
• T - is the type of chunk
• S - is the specification class used for that chunk
• R - set of properties describing requester, the user doing the request
• E - type used for validation errors, present only in mutable data chunk interface
• F - type used for failures, eg. Exception

The data chunk definition is here, and some sample implementations:

• FieldsChunk - a form with 3 fields,
• OptionsChunk - a dropdown with list of possible choices,
• ReadOnlyChunk - a read-only chunk, for presenting additional info

All the data chunks, should be implemented as completely independent elements. it will increase their reusability (ie. same data chunk for sender and recipient) and allows for easier composition.

WhatIsNext

The WhatIsNext interface is the place where data collection flow, all the connections between chunks are defined and presented to client applications. It contains two methods:

• whatIsNext - that will provide specifications of all chunks that can be interacted with at that stage of the data collection flow,
• isCompleted - will tell if the data collection is completed or there's something to do.

Default implementation comes with ChunkAggregateWhatIsNext, that brings its own small language of methods for building flows.

• chunk.on(predicate) - chunk visibility depends on predicate
• chunk.then(other) - allows making chunk or chunks appear when parent or parents are completed:
  • single parent with single child
  • single parent with multiple children
  • multiple parents with single child
  • multiple parents with multiple children
• chunk.thenOnValue() - allows for branching depending on the value from chunk, since the value access is passed via function, it can easily handle dropdowns/options, forms and read-only chunks.