Extract Cleave.js-dependant JavaScript from application pack#5435
Extract Cleave.js-dependant JavaScript from application pack#5435
Conversation
**Why**: Reduce minified bundle size of hot-path application.js by ~25%, and further establish convention of partial/component-specific JavaScript packs.
| @@ -0,0 +1,23 @@ | |||
| import Cleave from 'cleave.js'; | |||
|
|
|||
| const SELECTOR_CONFIGS = { | |||
There was a problem hiding this comment.
Note this excludes .dob from form-field-format.js, which no longer exists as of #4852.
| Object.entries(SELECTOR_CONFIGS) | ||
| .map(([selector, config]) => [document.querySelector(selector), config]) | ||
| .filter(([element]) => element) | ||
| .forEach(([element, config]) => new Cleave(element, config)); |
There was a problem hiding this comment.
To confirm: The Cleave constructor can only handle one element, even though a class selector could match multiple elements. This is true regardless if we pass the selector (previous) or element (current) to the constructor.
See: https://github.com/nosir/cleave.js/blob/e3fa6f3/src/Cleave.js#L29-L36
If we ever need to support multiple instances of elements on the page, we could consider constructing each:
| Object.entries(SELECTOR_CONFIGS) | |
| .map(([selector, config]) => [document.querySelector(selector), config]) | |
| .filter(([element]) => element) | |
| .forEach(([element, config]) => new Cleave(element, config)); | |
| Object.entries(SELECTOR_CONFIGS) | |
| .map(([selector, config]) => [document.querySelectorAll(selector), config]) | |
| .filter(([elements]) => elements.length) | |
| .forEach(([elements, config]) => elements.forEach((element) => new Cleave(element, config))); |
| </div> | ||
| <% end %> | ||
| <%= render 'idv/doc_auth/start_over_or_cancel', step: 'ssn' %> | ||
| <%= javascript_packs_tag_once('ssn-field') %> |
There was a problem hiding this comment.
the ssn field markup is basically identical (same form field name, same translation) to the one in ssn_update, if we're going to have a separate JS include for this file would it make sense to extract a partial for that field and put the JS pack tags in there?
There was a problem hiding this comment.
the ssn field markup is basically identical (same form field name, same translation) to the one in
ssn_update, if we're going to have a separate JS include for this file would it make sense to extract a partial for that field and put the JS pack tags in there?
Yeah, I think we might be able to consolidate to one partial between creating and updating SSN. Even then, it could still make sense to extract a partial just for the input field as well, so that the markup and JavaScript are packaged as a self-contained unit.
There was a problem hiding this comment.
I extracted the SSN field in b9ca762. I started consolidating the SSN views as well, but it's a bit more work than I'd like to take on here, so probably worth a follow-up.
3 participants
Why: Reduce minified+gzipped bundle size of hot-path application.js by ~25%, and further establish convention of partial/component-specific JavaScript packs.
Cleave.js is not small: https://bundlephobia.com/package/cleave.js@1.6.0
(Generated by disabling chunk splitting and running
NODE_ENV=production RAILS_ENV=production ./bin/webpack)