Have StringCalculatorPage use host document #51
Merged
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
StringCalculatorPage no longer creates its own DocumentFragment with a new top level app element (<div id="app">). The constructor now takes the top level app element as its first argument, and an optional Document as its second argument. This enables it to continue wrapping documents created via the PageLoader from test/helpers.js, as used in main.test.js. The new static factory, StringCalculatorPage.new(), creates a new <div> with the specified ID, appends it document.body, and returns a new StaticCalculatorPage wrapping that app element. This tries to ensure that the <div>s created by tests don't collide with existing <div>s in the document (short of randomly generating its own IDs). StringCalculatorPage.new() also keeps track of instances it creates, and clients should call StringCalculatorPage.cleanup() in their afterEach() handlers. This ensures the host document returns to its original state after each test. --- As mentioned in the previous couple of commits, a <form> element attached to a DocumentFragment would exhibit inconsistent behavior across jsdom, Chrome, and Firefox. This new implementation solves that problem (as will be seen in the upcoming Calculator component tests). It would've been nice to use a DocumentFragment for all our tests instead of modifying the global document in any way. However, this way we can be more confident that our components will exhibit consistent behavior regardless of the test environment.
mbland
added a commit
that referenced
this pull request
Dec 17, 2023
Now all parameters that initApp() may pass through to each individual component's init() function are bundled into a single object. Other small but significant changes: - Removes window and document from the parameter list for now, as there's no components that need to inject them. - Sets up a list of components in initApp() so that it can call each component's init() via forEach(). This eliminates the need to add a new line for each init() call for each added component. - Sets initApp() to run only once on DOMContentLoaded. - Removes the now unused fragment() test helper (should've been part of commit 5f2a917 from #51). --- While adding the Calculator component, it became apparent that adding more params to main.js and initApp() to pass through to init() was becoming unwieldy. This solution makes future extension easier and the code cleaner while decoupling component initializer signatures from one another.
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.
StringCalculatorPage no longer creates its own DocumentFragment with a new top level app element (<div id="app">).
The constructor now takes the top level app element as its first argument, and an optional Document as its second argument. This enables it to continue wrapping documents created via the PageLoader from test/helpers.js, as used in main.test.js.
The new static factory, StringCalculatorPage.new(), creates a new <div> with the specified ID, appends it document.body, and returns a new StaticCalculatorPage wrapping that app element. This tries to ensure that the <div>s created by tests don't collide with existing <div>s in the document (short of randomly generating its own IDs).
StringCalculatorPage.new() also keeps track of instances it creates, and clients should call StringCalculatorPage.cleanup() in their afterEach() handlers. This ensures the host document returns to its original state after each test.
As mentioned in the previous couple of commits, a <form> element attached to a DocumentFragment would exhibit inconsistent behavior across jsdom, Chrome, and Firefox. This new implementation solves that problem (as will be seen in the upcoming Calculator component tests).
It would've been nice to use a DocumentFragment for all our tests instead of modifying the global document in any way. However, this way we can be more confident that our components will exhibit consistent behavior regardless of the test environment.