-
Notifications
You must be signed in to change notification settings - Fork 29
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
Caller id match #156
Caller id match #156
Conversation
|
@@ -3,10 +3,12 @@ import { errorType, callEndStatus } from "../../src/Constants"; | |||
// import CallingExtensions, { Constants } from "@hubspot/calling-extensions-sdk"; | |||
// const { errorType, callEndStatus } = Constants; | |||
|
|||
const state = { | |||
export const state = { |
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.
Expose state to the window object so that we can change any of the properties such as fromNumber
before sending an event in the Demo Widget. For our acceptance tests, we should create an engagement state and call state to display in the UI like how we are doing so in the Mock UI.
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 would export it with a more definitive name. state is too generic. Thoughts?
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.
Sure, do you have any suggestions for the name - maybe engagementState? This is only exported in the demo-minimal-js
iframe so we won't be seeing a conflict with any variables in the parent window
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.
We could also implement getters and setters here
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.
If the scope is minimal, i am fine. But, are we making updates to state properties? If yes, then it would be better if we have function to return initial state. So, we dont have accidental leaks.
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.
Yeah it's a minimal scope right now. Since we're not persisting the state across mounts, any changes to state properties would only affect the demo minimal js widget until we unmount the component.
src/CallingExtensions.js
Outdated
logDebugMessage(message) { | ||
this.iFrameManager.logDebugMessage(prefix, "Console Debug", message); | ||
} |
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.
Used Console Debug
to differentiate this message from HS and Third Party events as I couldn't think of another identifier. Feel free to throw suggestions
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.
Console Debug can be confusing. May be 'CallExt Debug'.
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.
Oops. I dint see the prefix defined already. Isnt prefix sufficient enough to differentiate?
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 prefix is used in other messages as well
this.logDebugMessage(prefix, "To HubSpot", type, message);
this.logDebugMessage(prefix, "From HubSpot", type, { data });
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.
Hmmm. May be, we can add provider name here. Like aircall, justcall. would that be of help?
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.
We're using logDebugMessage
in demo minimal js to log an incoming contact and leveraging the prefix to filter out Calling Extensions messages. However, since this isn't a message event to or from HubSpot, I'm thinking that something like Debug
would be useful for knowing the purpose of the logging.
This message wouldn't show up in any other apps unless they were to use logDebugMessage()
as well and in such cases, I'm not sure if the provider name would be helpful.
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'll defer to @hemang-thakkar for a code level review. All besides potentially dropping callId from the message body LGTM
cti.logDebugMessage({ | ||
message: `Incoming call from ${state.incomingContactName} ${state.fromNumber}`, | ||
type: `${callerIdMatches.length} Caller ID Matches`, | ||
}); | ||
return; | ||
} | ||
cti.logDebugMessage({ | ||
message: `Incoming call from ${state.fromNumber}`, | ||
type: "No Caller ID Matches", | ||
}); | ||
}, | ||
onCallerIdMatchFailed: (data, rawEvent) => { | ||
cti.logDebugMessage({ | ||
message: `Incoming call from ${state.fromNumber}`, | ||
type: "Caller ID Match Failed", | ||
}); |
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.
@hemang-thakkar Added an argument to log messages with a custom type
that would be more useful for debugging.
@hemang-thakkar FYI you can install the demo widget using the preview link to test within the Calling Popover |
* Create incoming call method to test inbound calling (#130) * Create incoming call started method to test inbound calling * Introduce inbound calling availability events (#138) * Refactor constants * Refactor version constant * 0.1.6-alpha.0 * Remove sdkVersion prop from initialized event * 0.1.6-alpha.1 * Introduce inbound calling availability events * Test new events * Configure prettier and format the demo-minimal-js html. Improve accessibility and SEO. * Use semantic html and style buttons * Refactor switch case into onclick methods and remove logic that waits for DOM content loaded since we are using defer to load the JS * Rename id * Specify encoding * Match SDK event name * sort props * Initialize as logged out * Add user availability events * Prevent window overflow * Allow user to change availability during a call. * disable availability buttons during a call. * 0.1.7-alpha.0 * Use new alpha version * Send incoming call event with data to create an engagement (#140) Create event handlers for create_engagement_succeeded and create_engagement_failed * Add to number for inbound calling * Initialize demo widget when ready event is received from HubSpot (#145) * Initialize SDK on ready event * Save userAvailable state in the demo widget * Allow user to start an incoming call asynchronously for testing (#146) * Revert "Initialize demo widget when ready event is received from HubSpot (#145)" (#147) This reverts commit 4aa4ff6. * Extensions inbound lifecycle (#148) * Initialize SDK on ready event * Save userAvailable state in the demo widget * Allow user to start an incoming call asynchronously for testing (#146) * Revert "Allow user to start an incoming call asynchronously for testing (#146)" This reverts commit 9800470. --------- Co-authored-by: Esme Ling <esmelingyr@gmail.com> Co-authored-by: Esme <23175119+esme@users.noreply.github.com> * 0.1.8-alpha.0 * Use next tag of SDK * 0.2.1-alpha.0 * Use latest sdk version * Caller id match (#156) * Add events for caller id matching * Add caller id match payload * Add debugMessageType argument to logging * Add incomingCall event handler to README * Log last sync event * 0.2.1-alpha.1 * Use next tag of SDK * 0.2.1-alpha.2 * Use next tag of SDK * Add support for inbound calling to react demo app (#157) * Add support for inbound calling to react demo app * Add unit tests for Incoming Screen * Unit tests * Fix useCti hook to store incomingNumber * Feedback fixes # 1 * Feedback fixes #2 * Feedback fixes * Add publish script for inbound branch (#162) * Send navigate_to_record event when we receive an existing call id (#158) * Send navigate_to_record event when we receive an existing call id * Fix console debug message const * Navigate to record page in the react demo app (#165) * Update README with instructions for redirect * 0.2.1-alpha.3 * Use next tag of SDK * Configure workflow to run on workflow_dispatch event * React Demo App: Set incoming number and contact name in localstorage (#166) * React Demo App: Set incoming number and contact info in localstorage on redirect * feedback fixes * 0.2.2-alpha.0 * 0.2.2-beta.0 * Support NAVIGATE_TO_RECORD_FAILED event (#171) * switch case lost its case to dictionary * Handle NAVIGATE_TO_RECORD_FAILED * Add event handler to demos * Remove unused message handler * Restore master version * 0.3.0-0 * 0.3.0-rc.0 * 0.3.0-alpha.0 * 0.3.0-beta.0 * Update dependents * Add error to message types (#173) * Restore alpha version before bumping * 0.3.0-alpha.1 * 0.3.0-alpha.2 * Update dependents * 0.3.0-beta.0 * 0.3.0-beta.1 * Bump sdk version to 0.3.0-beta.1 in demos * removing empty tag from preview.yml * Add beta badge to incoming call, availability toggles (#179) * Add beta badge to incoming call, availability toggles * code review feedback * fix unit tests * Simplify formatting * Simplify formatting * fix height for react demo app * Simplify README.md (#177) * Simplify README.md * Update link --------- Co-authored-by: Esme <23175119+esme@users.noreply.github.com> Co-authored-by: Esme Ling <esmelingyr@gmail.com> Co-authored-by: hemang-thakkar <59508898+hemang-thakkar@users.noreply.github.com> Co-authored-by: hthakkar <hthakkar@hubspot.com>
Description
Jira Ticket: CALL-3993
Merge Checklist
BRAVE Checklist