-
Notifications
You must be signed in to change notification settings - Fork 198
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
Added appId parameter to getContext #2337
base: main
Are you sure you want to change the base?
Conversation
@vikramtha this is failing to build, so it won't get any PR reviews until the build is passing |
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.
Updating
sh: line 1: :q: command not found
…s not passing the appId and name change from internalAppId to appId
* | ||
* App id that is used by Hosts to distinguish between different apps sideloaded or in store | ||
*/ | ||
appId: string; |
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.
Since this is a new feature, can I know why we need to add this parameter to a deprecated interface and as a deprecated element?
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 believe the Context deprecated interface is still used in the legacyContext transformation so I kept it
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 one should probably also be optional
change/@microsoft-teams-js-07a56fbc-6d3e-474d-b3d9-6c6fe3a3be50.json
Outdated
Show resolved
Hide resolved
change/@microsoft-teams-js-07a56fbc-6d3e-474d-b3d9-6c6fe3a3be50.json
Outdated
Show resolved
Hide resolved
6a26ec4
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 haven't looked into much deeper but first question I have is: doesn't it need changes in hub sdks to populate back appId since it looks it is defined as required?
Are all hub sdk test passing?
/** | ||
* App id that is used by Hosts to distinguish between different apps sideloaded or in store | ||
*/ | ||
appId: string; |
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.
@maglims brought up a good question that I forgot: since not all hosts will be setting this value, shouldn't it be optional (like appLaunchId)?
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 always be populated as long as there is an app def sent back; I rewrote the code in host SDK so that hosts no longer need to pass the value and instead it is taken from app definition
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 about hosts that aren't yet using the updated host-sdk? I believe in that case this would not be set, right? That's generally why we mark things like this optional, to handle backwards compatibility
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.
There are some questions about appId being optional, and I think it should be. If you have questions just send me a message and we'll talk about it.
/** | ||
* App id that is used by Hosts to distinguish between different apps sideloaded or in store | ||
*/ | ||
appId: string; |
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.
Description
This is adding the
appId
parameter togetContext
. This is what hubs use to differentiate the app internally as well as what ends up being used in deeplinkingHere is the PM Spec for this: https://microsoft.sharepoint-df.com/:w:/t/MetaOS/ESh4ef-uxiBPohWO0I6DszoBzu6VGd_06r-Xg3TIy9tT8w?e=RKfWzE
Main changes in the PR:
appId
togetContext()
and theAppInfo
interfaceappId
through the context bridgeValidation
Validation performed:
Unit Tests added:
Yes added some dummy values in the test files. No E2E tests added
End-to-end tests added:
No
Additional Requirements
Change file added:
Yes