DSFAAP-510: create task list page and add model for tasks

[joseluisgraa]

No description provided.

[hughfdjackson]

@joseluisgraa - I think there's something off with the structure here.

The models (e.g. Address) represent datatypes that could appear in multiple sections. For instance, we collect an Address in both the "Movement Origin" section & the "Receiving the Licence" section.

We want the user experience (in terms of validation, error messages, etc) to be consistent across those sections - which the Address model allows for, if it's reused.

A better layout would be (IMO):

~/src/server/common/answer/ (containing the existing models)

and

~/src/server/common/section/ (containing the new section models)

Then the origin & licensed sections can make reference to the Address answer model.

[joseluisgraa]

You are right, I created the one for the task and then started moving the existing ones into origin without realising they would be reused by different sections. I'll follow your proposed structure.

[hughfdjackson]

I find a this bit hard to read because we've got positional booleans, at the call site it's not clear what they mean.

normally I go for a 'options object' pattern here, so:

function buildGdsTaskItem({ title, initialLink, summaryLink, isValid, isEnabled }) {...}

Then the callsite looks like:

    const destinationGdsTask = buildGdsTaskItem({
      title: 'Movement destination',
      initialLink: '#',
      summaryLink: '#',
      isValid: destination.validate().isValid,
      isEnabled: isOriginValid
    })

[hughfdjackson]

schemas don't get mutated by being validated (may even be immutable?), so you can do:

const validationSchema = Joi.object({
  addressLine1: Joi.string().required(),
  postcode: Joi.string().required()
})

and drop the beforeEach block