Implement the recipient form for gift card product

1. As a hidden form field with a value of "if_present". This will be used by clients without javascript. The 'if_present' flag gives a hint to the backend to only validate email addresses if one is given, blank values are acceptable
2. As a checkbox. This is a progressive enhancement which replaces the hidden field in 1 when javascript is enabled. The value sent to the backend will be on when the checkbox is checked. No field at all will be sent when it is unchecked. The backend will treat blank email as an error if the value is 'on'

The control field is used by the backend to enable the send to recipient feature validation and processing. It must be present for the feature to do anything. We only need it to be present if the user has elected to fill out the form.

This was a good idea but unfortunately it doesn't work with liquid rendering flow, we need the passed in elements to render within the inner liquid context

The dummy form is generated because we want to use properties from the liquid product from drop. It doesn't serve any actual purpose in the html.

Normally product forms are wrapped in a <product-form> custom element which have some styling applied. We don't want to do that because the custom element also adds a bunch of js that we don't want. Instead we just use a div with the class.

When js is disabled the form displays with no checkbox
When js is enabled the form is hidden at page load and the checkbox is unhidden and enabled

This works well but is susceptible to content flashes as the form is first shown then quickly hidden. Probably unacceptable.

An obvious solution would be to check the checkbox by default which would mean there is no need to hide the form on load.

A more extreme solution is to use a noscript tag to completely sever the link between the two sets of markup. I don't like this solution as it bloats the source but it does neatly take care of the content flash

… at page load

… on wether the client has JS enabled

When we read errors out of the flash state we want them displayed nicely inline on the recipient form.

We can do this by ripping off the pattern frolm customer registration. There are a few styles which have been implemented as
specific .customer styles which should really be a generic class but not a huge issue to just use the customer class in our form as well

This is important as the field names we get from the backend are lower case and we use them to dynamically build selectors

We tried to simplify things by having the recipient form be part of the main product form but it didn't work. We can just use the html form attribute to reassign inputs from a different form to the main product form. Messy from a source view but nicer from a visual editor POV.

…ript

Liquid errors already render nicely next to the fields they belong to. We'd eventually like the same behaviour in JS. That will require tweaking the backend error payload a bit but is otherwise achievable.

We first have to disable the existing product form error handling as this appears next to the buy buttons

Instead we publish the error response on the pub/sub bus and display the error at the top of the recipient form.

We have liquid render the error container so it looks roughly the same regardless of whether the error is rendered by liquid or JS.

Next step will be to break the error message down into fields on the backend and unpack the messages on the FE.

Co-authored-by: Frederic Ma <frederic.ma@shopify.com>

There is no validation on these fields yet but there will be

Since this was introduced the markup has changed to introduce an extra form wrapper which takes care of what this was trying to achieve

Was throwing the alignment out

Co-authored-by: Ludo <ludo.segura@shopify.com>

This mirrors what liquid does to render errors.

Previously we were building error messages using the unlocaised field key

This is important as the error reporter has to deal with two different types of errors:

* Normal simple product form errors such as adding too many of a varient to cart. These display as a single sentence in the error header, replacing the original liquid rendered header.
* Gift card recipient errors which arrive as a map of field => error message. These are disgned to mimic the original liquid layout of the page and as such should use the original liquid header, even if it has been previusly replaced by a simple product error

This matches how we do it in liquid

I think the saved few characters are a false economy but it seems to be the style

…lock

* terse if/else, albeit with an extra assignment
* remove uneeded form assignment
* replace a span with a div

This is still not perfect, voiceover on mac will read out:

{aria-labelledby} {placeholder}, edit text {label}

e.g

Recipient's Email Email, edit text Email

I'm not sure it should use the placeholder like that. Ultimately the issue is that we use two labels for the field, perhaps we should scrap that approach and just use one label?

Co-authored-by: Ludo <ludo.segura@shopify.com>

this has been replaced by a snippet

We felt that extra labels might be redundant. MEant I also had to rejig the spacing of the form but I think it's come out ok. Also emilinated the massive gap under error list.

* Add elipses on field labels at short widths
* Move max chars message to bottom of textarea
* Add aria-label to textarea which contains the max chars description

This is because the label is now a bit wordy to use as an error key

Co-authored-by: Ludo <ludo.segura@shopify.com>

Co-authored-by: Ludo <ludo.segura@shopify.com>

Co-authored-by: Ludo <ludo.segura@shopify.com>

…t filters