Return to Answer

Here are my thoughts:

• Good use of arrow functions where appropriate. If you really wanted to, you could shorten some of those small functions- e.g.:

   function ensureNumber(input) {
   if (Number.isInteger(input.value)) {
   return '';
   }
   return 'field must be number';
   }
  

Could be shortened to a single line:

 ensureNumber = (input) => Number.isInteger(input.value)?'':'field must be number';

• I also like the use of the spread operator when getting the errors back from the mapped validation for a field.
• Depending on how the validationResult is used, a POJO could be used instead of a Map to utilize less memory, though that might not be a concern. A POJO doesn't have .forEach like Map would (though one could iterate over the keys of a POJO). Apparently when using an ES-2015 compliant engine, the key order is maintained.
• Bearing in mind that it might not be preferable/possible to update the DOM, one could apply class names to the inputs/textareas/selects/etc. and then use Document.getElementsByClassName() instead of querySelectorAll() but that might only lead to a slight performance gain.

Here are my thoughts:

• Good use of arrow functions where appropriate. If you really wanted to, you could shorten some of those small functions- e.g.:

   function ensureNumber(input) {
   if (Number.isInteger(input.value)) {
   return '';
   }
   return 'field must be number';
   }
  

Could be shortened to a single line:

 const ensureNumber = (input) => Number.isInteger(input.value)?'':'field must be number';

• I also like the use of the spread operator when getting the errors back from the mapped validation for a field.
• Depending on how the validationResult is used, a POJO could be used instead of a Map to utilize less memory, though that might not be a concern. A POJO doesn't have .forEach like Map would (though one could iterate over the keys of a POJO). Apparently when using an ES-2015 compliant engine, the key order is maintained.
• Bearing in mind that it might not be preferable/possible to update the DOM, one could apply class names to the inputs/textareas/selects/etc. and then use Document.getElementsByClassName() instead of querySelectorAll() but that might only lead to a slight performance gain.

Here are my thoughts:

• Good use of arrow functions where appropriate. If you really wanted, you could shorten some of those small functions- e.g.:

   ensureNumber = (input) => Number.isInteger(input.value)?'':'field must be number';
  

• I also like the use of the spread operator when getting the errors back from the mapped validation for a field.

• Depending on how the validationResult is used, a POJO could be used instead of a Map to utilize less memory, though that might not be a concern. A POJO doesn't have .forEach like Map would (though one could iterate over the keys of a POJO). Apparently when using an ES-2015 compliant engine, the key order is maintained.

• Bearing in mind that it might not be preferable/possible to update the DOM, one could apply class names to the inputs/textareas/selects/etc. and then use Document.getElementsByClassName() instead of querySelectorAll() but that might only lead to a slight performance gain.

Here are my thoughts:

• Good use of arrow functions where appropriate. If you really wanted to, you could shorten some of those small functions- e.g.:

   function ensureNumber(input) {
    if (Number.isInteger(input.value)) {
   return '';
   }
   return 'field must be number';
   }
  

Could be shortened to a single line:

 ensureNumber = (input) => Number.isInteger(input.value)?'':'field must be number';

• I also like the use of the spread operator when getting the errors back from the mapped validation for a field.
• Depending on how the validationResult is used, a POJO could be used instead of a Map to utilize less memory, though that might not be a concern. A POJO doesn't have .forEach like Map would (though one could iterate over the keys of a POJO). Apparently when using an ES-2015 compliant engine, the key order is maintained.
• Bearing in mind that it might not be preferable/possible to update the DOM, one could apply class names to the inputs/textareas/selects/etc. and then use Document.getElementsByClassName() instead of querySelectorAll() but that might only lead to a slight performance gain.