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 a4a intersection observer #19838
Conversation
* @param {!RefreshConfig} config | ||
* @return {!RefreshConfig} | ||
* @param {!JsonObject} config | ||
* @return {!JsonObject} |
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.
@erwinmombay I have one question, instead of returning a JsonObject
, can we keep the RefreshConfig
defination, but have the convertAndSanitizeConfiguration_
returns an object like
{
continousTimeMin: config['continuousTimeMin']*1000,
...
}
I don't feel that the namespace continousTimeMin
and visiblePercentageMin
is useful after the read. WDYT?
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.
im ok with that for the most part.
just a thought though, using refreshconfig here, somebody is going to get tripped up again i think at some point. having a typedef
does not mean closure will preserve the key values, and "configurations" almost always crosses these boundaries (xhr, html, postmessage, iframe) and the other side is going to get garbled obfuscated keys.
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.
somebody is going to get tripped up again i think at some point
I completely agree. I think this is a tradeoff between code size and style. Given this purely lives within extension code, I believe you're right to go with style.
i think at some point. having a typedef does not mean closure will preserve the key values
Thought typedef
is more about type checking. If we move to JsonObject
, is there a way to enforce type 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.
Thought typedef is more about type checking. If we move to JsonObject, is there a way to enforce type later?
This is why JsonObject
should be used at the boundaries and types/typedefs everywhere else. unfortunately, its a little hard for me to interpret this much code so its easier for me to just JsonObject
everything so that I don't make a mistake.
I completely agree. I think this is a tradeoff between code size and style. Given this purely lives within extension code, I believe you're right to go with style.
did you mean you are OK with what I did, or do you prefer that i try to keep the typedef
's ?
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.
Talked offline. We agreed it's safest to use JsonObject
for extern config at this point. I'll need to figure something out in the future. A read/write method that handle externs, that could be difficult to enforce.
Anyhow this is something that needs further discussion. To fix the current issue, the PR looks good to me.
7753af7
to
9be66bd
Compare
* fix a4a intersection observer * fix lint issues
* fix a4a intersection observer * fix lint issues
fixes #19623