Switch to use Web API in Slidedown and Tagging Container #681
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rgomezp
force-pushed
the
slidedown-web-api-switch
branch
3 times, most recently
from
f2301f0 to
342adb7
Compare
New CSS class constants: - 'slide-up' - 'slide-down' - close-slidedown' Refactoring - Switched to all caps constant typescript convention
After shifting from hard-coded HTML approach to Web API approach, the function returns a web Element so we are renaming it here to be more clear.
rgomezp
force-pushed
the
slidedown-web-api-switch
branch
from
342adb7 to
1485574
Compare
jkasten2
requested changes
Aug 11, 2020
jkasten2
reviewed
Aug 12, 2020
There was a problem hiding this comment.
You noted you tested on this on your machine, can you explain in more detail what was tested to confirm we covered everything that could be effected?
Some things I recommend testing:
- Visually normal slidedown.
- Visually category slidedown.
- Saving categories saves correct values
- Visually category slidedown when updating.
TestEnvironment: - Need to mock the Dom environment for tests to pass now that we are using the WebApi to create elements TaggingContainer: - switched to use `value` instead of `defaultValue` which is actually what we want
Previously, the span and indicator holder elements would not display the pointer as the cursor which was inconsistent with the parent Button element.
It's bad practice to set `innerHTML` as this has a high performance cost. Instead of using `innerHTML` we switch to use `textContent` when the only thing being replaced is the text. When we insert multiple children nodes to the element (button), we now use the helper functions `getIndicatorHolder` and `getTextSpan` to separately generate the HTML Elements needed to insert as a child element to the button by using `insertAdjacentElement`.
rgomezp
force-pushed
the
slidedown-web-api-switch
branch
from
1485574 to
468243d
Compare
jkasten2
reviewed
Aug 12, 2020
jkasten2
requested changes
Aug 13, 2020
There was a problem hiding this comment.
Changes all look good now, however please confirm what was tested before mering in
#681 (review)
|
jkasten2
approved these changes
Aug 17, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
This change includes a transition from using hard-coded HTML strings to using the W3C Web API to create DOM elements programmatically. The main reason for this is for security purposes since this approach is an easy way to avoid injection vulnerabilities.
This PR also includes other tweaks like the addition of CSS and Element ID constants, 1 file rename, and other minor nits.
Systems Affected
WebSDK only
Validation
Tests
Test coverage for these changes are not needed since the only change was a switch to how DOM elements are created.
Screenshots
Nothing has visually changed in this PR.
This change is