In Excel Online, OfficeJS API is not passing the host_Info_ parameter anymore to Excel Add-In
Asked Answered
I

3

3

I don't know when this started happening or if things have changed but the _host_Info param is not being passed by the framework to my Excel Add-In in Excel Online.

It passes an empty "et=" parameter which is OK in this case since I'm in dev mode. The Excel desktop client is still passing it.

This is required by my add-ins to switch functionality between Excel Online and Excel for Windows.

I've checked the docs and can't find that anything has changed.

Isomerize answered 19/11, 2016 at 0:50 Comment(0)
C
4

To append to Sudhi's answer: with the official API coming as per the link in Sudhi's answer, we've gone ahead and also added a "shim" for the API in the OfficeJsHelpers library.

The shim still uses the workaround code that Sudhi mentions -- window.sessionStorage['hostInfoValue'] -- but it wraps it in an API very similar to what is coming in the official Office.js. Once the official API is available, we'll switch the shim code to make use of that instead. The beauty of this approach is that if you use OfficeJsHelpers via an NPM package, all you have to do is update your package dependency, and you'll suddenly go from an unofficial and potentially-fragile workaround to an API that relies on 100% officially-exposed properties -- all without changing your own code! Likewise, if at that time you decide to switch back to using the official Office.js version, the similarity of the APIs (essentially just namespace differences) should make it trivial to switch over the implementations.

The helper APIs are OfficeHelpers.Utilities.host (which will return WORD, EXCEL, etc.) and OfficeHelpers.Utilities.platform (which will return IOS, PC, OFFICE_ONLINE, or MAC). The constants are defined in OfficeHelpers.HostType and OfficeHelpers.PlatformType.

You can find the NPM package at https://www.npmjs.com/package/@microsoft/office-js-helpers, and either install it via NPM, or use a CDN like Unpkg to quickly try it out: https://unpkg.com/@microsoft/[email protected]/dist/office.helpers.min.js

console.log(OfficeHelpers.Utilities.host);
console.log(OfficeHelpers.Utilities.platform);

if (OfficeHelpers.Utilities.platform === OfficeHelpers.PlatformType.OFFICE_ONLINE) {
    console.log("Yep, I'm on the web client");
}

I hope you find the above helpful as an interim measure, and we'll be sure to update this StackOverflow thread (and the OfficeJsHelpers code) once the official API is released.

Chaucerian answered 4/12, 2016 at 20:52 Comment(2)
For anyone reading this now, OfficeJsHelpers is now deprecated. OfficeHelpers.Utilities.host is now: Office.context.host, and OfficeHelpers.Utilities.platform is now: Office.context.platformJoplin
Thank you extremeandy, Office.context.platform Documentation: learn.microsoft.com/en-us/javascript/api/office/…Marylinmarylinda
C
1

UPDATE:

Please see my answer above, instead (https://mcmap.net/q/1173539/-in-excel-online-officejs-api-is-not-passing-the-host_info_-parameter-anymore-to-excel-add-in), as the scenario is now possible.


[Old response:]

Jim, could you describe your scenario more? Why is it that you need to distinguish between Online and Desktop?

For the disappearance of host_info_: you won't find it in the docs, because host_info_ was never in the docs. Anything not documented is an internal API, which might change as needed by the internal workings of Office.js. We take back-compat very seriously, but only for actual official documented APIs.

Without an API, there's not much you can do to tell the two apart (or rather, not without relying on other bits of internal workings which might also change over time). We've discussed this internally before, but found it surprisingly difficult to point to a particular scenario where the platform information was necessary and legitimate ("legitimate" in the sense that if you're using platform information to check whether an API is available, for example, that's precisely what we don't want you to do; we want you to use Office.context.requirements.isSetSupported instead).

If you can share your scenario details, I might be able to advise an alternate way of determining whatever you need, or have a solid scenario to bring back to the team.

Chaucerian answered 19/11, 2016 at 1:27 Comment(22)
Michael, thanks for the reply. I actually thought this was documented at the time I did it, especially since some of the APIs have more limitations in Excel Online vs Client. For me it is, 1) cellFormat param of .document.setSelectedDataAsync() can only have 100 in Excel Online and 20000 in client. I have code that "pages" the format calls in Excel online only, 2) my app limits what it can do based on Online vs. Client -- can select less cells to act on -- because of resource constraints, 3) you can't "hyperlink out of the task pane in Excel online" so i handle that...Isomerize
...and I have (beta) feature that only works in Excel online (which I may or may not keep).Isomerize
Anyway, for me it's important since it breaks my app right now with a bad error because I am trying to format more than 100 cells since I don't know I should be paging. Any chance you could add the host information to the context object? Generally, I think it's important since an add-in can and should be able do more in the Excel client than it can in Excel online. I can't remember how you monitor an add-ins resource usage but I think it's different between Excel client and Online.Isomerize
@JimBarrett, thanks for the detailed info. Let me bring this up to the team, and get back to you about it. For #1, I didn't realize we had this limitation... but it sounds like we should either expose an API to expose the count, or lift the limitation. This is actually precisely the thing we want to avoid with exposing the host -- we don't want people to rely on current assumptions on limits that we might increase later, and yet the application (and developer) wouldn't know about it.Chaucerian
For #2 & resource constraints: I think the limits are quite loose. If you have a particular scenario that you find works on Desktop but not Online, please let us know.Chaucerian
Finally, for #3: that is the one scenario -- distinguishing between iframe vs. web-browser embedding -- where I can imagine some platform differences beyond our control, that the developer should handle. Could you provide an example of the code you mean? You can't do a target="_blank"?Chaucerian
Michael, thanks for the reply. I'll wait for you to check on the reason for the 100 vs. 20000 but my guess would be something to do with resources. In addition to that, for one of my add-ins, ranges are selected and then run through a fairly intensive computation routine. I found after some testing that I had to limit the range that can be selected in Excel online to about 10000 cells or else it just took too long and I would get browser "long running script" errors. I know how to yield processor to the browser, and I am already doing that, but I didn't want to split up this routine...Isomerize
...and didn't want to move it to the server. Even if I did do it, the user (and I) would not be happy with the user experience. So I think it is reasonable to tell the user for ranges greater than 10000 you need to use the Excel client, which is what I do.Isomerize
If you don't mind, allow me to turn the question around. Why is it that you need to take the parameter away and not allow add-ins to use the information? There will never be full feature parity between the Excel client and Excel online (at least not in my lifetime :) so why would you expect that of Add-ins?Isomerize
@JimBarrett, the argument for not exposing this information -- and I'm not saying I necessarily agree with that argument -- is that developers might make assumptions that are true at a given moment, but prevent the add-in from benefiting from improvements / bug fixes. For example, the Dialog API is not (or at least was not) available on Office Online a couple months ago -- but it is something that we are adding (or added) now. We wouldn't have wanted developers to use the am-I-in-Online logic for this, but rather use official means: in this case, Office.context.requirement.isSetSupportedChaucerian
For the parameter in particular: I assume that some internal changes made this parameter unnecessary, and so it's no longer passed in. If we were to bring it back, I think the right thing wouldn't be through the URL, but rather an actual API.Chaucerian
Michael, thanks for response. I could actually make a case for the opposite. If I have chosen to implement a feature using a requirement set (Dialog API or Excel API), knowing that it is not available in Excel online yet, it means that I have already disabled OR provided an alternate way to implement the feature in Excel online. More importantly I have tested it in Excel online and in the client(s) as part of a planned development cycle.Isomerize
…If I just use requirement.isSetSupported and then suddenly one day the feature lights up in Excel online (because my add-in’s dev cycle doesn’t align with the requirement set release), it may or may not function or display correctly. If I have the host information I can keep running the existing implementation in Excel online while I have time to plan, implement, and test the feature using the new APIs. The problem is that just using isSetSupported I can’t tell if the API is not supported because it is Excel Online or if it is because of an older client.Isomerize
More important than requirement sets, I think I have made a good case for needing to know the host to allow for add-in specific functionality, such as acting on a smaller range. Even if setSelectedDataAsync() is changed to allow more than 20,000 cells to be written in Excel online (which seem like a bigger change than putting the _host_Info param back), I probably would still not use it for user experience reasons.Isomerize
It really boils down to this…without knowing the host, we are left with developing to the lowest common denominator and not using the full power of the Excel client, something I think we can agree is not good for anybody (and devalues the add-in). Related to this, dev.office.com/docs/add-ins/develop/… indicates "You can also optimize the performance of your add-ins on desktop and mobile devices by optimizing the use of resources in your add-in design and implementation." How can I do that if I don’t know that I am on the desktop?Isomerize
Finally, a good reason for keeping host information as a URL param is that it provides an add-in the opportunity to implement custom telemetry/diagnostics on the server. Sorry for the long text but I think this is a very important and impactful decision at hand.Isomerize
Jim, apologies for the delay. I have passed the information on to the right folks, and will have a discussion with them.Chaucerian
Thanks Michael. If you need more details please feel free to contact me.Isomerize
@jimBarrett, _host_Info is really important for us too. We are relying on it for platform dependent code. Give you two cases: 1. Right now there seems to be a bug on Mac Excel that LocalStorage is not working. So we have to use cookie on Mac 2. It seems Excel online doesn't support inline dialog. So we need to tweak different user experience for Excel online. And there will be more cases like this. If you are releasing an API for checking the platform running, we are happy to use that. But before that, can you not taking away _host_Info?Subsistent
Well, I meant for target question to @michael-zlatkovskySubsistent
@CloudXu, thanks for the additional info. I have passed it on to the team.Chaucerian
@CloudXu, I am happy to report that an official API is in fact coming, and that we also have an interim solution for you. Please see my other answer, above: https://mcmap.net/q/1173539/-in-excel-online-officejs-api-is-not-passing-the-host_info_-parameter-anymore-to-excel-add-inChaucerian
L
1

Jim and others who may be affected by this change: it is unfortunate that an unrelated change meant to improve the add-in experience caused the query string parameter in online platform to be removed. Note that URL query parameters and session storage settings are used to launch and setup the add-in environment and are not meant for developer consumption. However, we understand the importance of this to the developers as described in this thread.

Hence, we are adding formal APIs to make this information available. Please see the specs that describes upcoming APIs: https://github.com/OfficeDev/office-js-docs/tree/ContextAdditions_OpenSpec

Until the APIs become available (should be very soon), you could use the following temporary workaround. The same query host_info_ parameter value is available in the following variable: window.sessionStorage.hostInfoValue. Please note that this should be considered a temporary measure and you should switch to using the formal API as soon as they are made available. I'll update the this thread when the API is released, which should be available for all supported Office versions.

If you have any comments, please leave your comments on the specs directly in Github specification branch using the links provided.

Lodovico answered 3/12, 2016 at 2:15 Comment(1)
Sudhi, awesome news! Thanks a lot to the team for this and for listening to feedback. It will be a great addition to the API. I will use the workaround until the API is released.Isomerize

© 2022 - 2024 — McMap. All rights reserved.