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
[WIP] HelpScout enhancements #830
Conversation
script.innerHTML = BEACON_EMBED | ||
document.body.appendChild(script) | ||
} | ||
window.Beacon('init', HELPSCOUT_ID) |
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.
Super how this works!
I think this 2 actions (init
and setBeaconInit
) should be triggered in the onload
method from script no?
Maybe attach the script to the head instead to the body?
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.
On another note, by removing the beaconReady
prop the loader is no longer shown while the script is loading, you can test this by throttling the network
speed in chrome, let's figure a way to show the LoadingRing
to avoid the modal from disappearing and reappearing.
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 think this 2 actions (init and setBeaconInit) should be triggered in the onload method from script no?
Beacon.init()
gets queued and it’s probably a good idea to keep it first, as the script will probably refuse to execute the other methods if they are called before.
beaconInit
is used to know that the script is being initialized, so that we don’t inject the script twice.
</Helmet> | ||
const beacon = useCallback( | ||
(...params) => { | ||
if (window.Beacon && optedIn && beaconInit) { |
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.
What happens when this function is called but window.Beacon
does not exist is the calls gets lost, should we be queueing them? or at least sending them to the future via a setTimeout
?
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 need to check again, but IIRC this window.Beacon
in the condition is only here as a safety measure because we don’t control what the HelpScout
script does with the object.
The window.Beacon
object should exist as soon as optedIn
changes to be true
, and BEACON_EMBED
is doing exactly this:
- Creating the
window.Beacon
function. - Queuing calls to
window.Beacon
. - Injecting the script (that uses the queue).
As a note, the reason why it there is a wrapping function here (instead of exposing window.Beacon
directly) is because HelpScout replaces it in a totally unpredictable way.
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 window.Beacon object should exist as soon as optedIn
This is not in synch right? So, maybe there is some delay before the window.Beacon
object exists.
Fixes #782.