Test/Refactor: split out adobe line splitting logic, added unit tests #174
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
adobe line splitting
in general for text entry, when you have too many words on a single line, the text editor has to decide how and where to break up overflowing words to transition them to the next line. For most words, the editor will just take the last word that doesn't fit and move it over to the next line. However, what should be done in weird cases like
hello/world
orhello?world
? Should it treat the whole phrase as a single word, or break on the character in between? That is going to depend on the editor, and I found that the browser's text input field and the adobe forms text input fields made different decisions on when to split words to fit into lines better. In order to make sure this is correct, I split out the line break logic into its own function and put in several unit tests against it.tokenize unit tests
tokenize
just takes a bullet and splits it into an array based on whitespace. I wasn't sure if the\s
regex character class also handled unicode half-space and other special whitespace characters, so I added unit tests to ensure that it did work.