-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: Fix checking if scope
is a jquery element
#4176
Closed
+61
−27
Closed
Changes from 2 commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
db123a1
fix: Fix checking if `scope` is a jquery element
gadenbuie 20b2669
`yarn build` (GitHub Actions)
gadenbuie 33d6686
refactor: Don't check binding validity if `scope` isn't an element
gadenbuie 6c281f3
chore: yarn build
gadenbuie 4a01dde
fix: Only call `renderContentAsync` on element nodes
gadenbuie 42b6b8b
chore: yarn build
gadenbuie File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
Large diffs are not rendered by default.
Oops, something went wrong.
Large diffs are not rendered by default.
Oops, something went wrong.
Large diffs are not rendered by default.
Oops, something went wrong.
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
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will require some downstream changes, but it feels like, if
checkValidity()
is gonna support aText
type, then so should.bindAll()
, etc.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's super weird that text is being passed in at all. It bothers me not knowing where that's coming from.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The
el.innerHTML || el.textContent
in this code seems like a likely sourceshiny/srcts/src/shiny/shinyapp.ts
Lines 1165 to 1175 in 20b2669
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just above it that section I found this comment
shiny/srcts/src/shiny/shinyapp.ts
Lines 1145 to 1147 in 20b2669
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anyway, I refactored this to avoid adding a new type, and we just exit validity checking if it's passed something other than an
HTMLElement
or a jQuery instance. 33d6686A few take-aways:
renderContentAsync()
and which nav insertion calls many times in onenav_insert()
. Thus feat: De-duplicate client console messages #4177 will be helpful.checkValidity()
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that's right. It's the type of
el
(i.e., the first argument torenderContentAsync()
) that's the problem. The type checker incorrectly thinksel
is alwaysHTMLElement
, when apparently it can also beText
. This can be confirmed by addingconsole.log(el)
just before therenderContentAsync(el, el.innerHTML || el.textContent)
call using the reprex you provided. And in this case, theText
nodes are just new lines. Apparently jQuery does this for HTML strings that look like this:$("<div></div>\n<div></div>")
. Given that, it's really unfortunate that$divTag
's type isJQuery<HTMLElement>
because it really should be something more likeJQuery<HTMLElement | Text>
?All that said, ideally we'd get to the bottom of the jQuery typing issues, but if that seems like a lot of work/impossible, I think I'd be OK with just adding the
if
check around thatrenderContentAsync()
call (along with a comment about howel
's type isn't quite right). I can't think of a scenario whereel
isText
that you actually want to render?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jcheng5 and I looked through this and came to the same conclusion as you. So I added the check to only call that
renderContentAsync()
for element nodes in 4a01dde.That said, I remembered while looking at this that about a year ago I ran into issues with a web component in an inserted nav panel being initialized twice and as a result having different behavior when finally added to the DOM because the component changes some attributes on load.
What we'd really like to do is to avoid doing both
$(message.divTag.html)
and then later callingrenderContentAsync()
. If you have any advice or context around why we currently do both or how we can get out of the situation, it'd be appreciated!