We see some differences in our SPFx web part behavior depending on which page type it is placed on (modern vs. classic). Classic pages behave somewhat differently.

I'd like to detect which page type the web part runs on. Is there an "official, modern" way to do this, ideally baked into the framework? If not, what would you suggest?

up vote 13 down vote accepted

You can make use of the EnvironmentType enum that is available via the sp-core-library.

The code for that would be as below:

Add the below import statement.

import { Environment, EnvironmentType } from '@microsoft/sp-core-library';

In your method, you can detect it as below:

if(Environment.type == EnvironmentType.ClassicSharePoint){
    //do some stuff on classic page
}else if(Environment.type === EnvironmentType.SharePoint){
    //do some stuff on modern page
}else if(Environment.type === EnvironmentType.Local){
    //do some stuff on SharePoint workbench page
}

Reference - Environment Type enum

  • Sounds perfect. But doing a quick test in SPO with a client side webpart Environment.type is undefined :-/ Any ideas why this could be? – Heinrich Ulbricht Sep 6 '17 at 8:33
  • hmm, can you try it as this.context.environment.type==EnvironmentType.ClassicSharePoint and check ? Try it in the render method. – Gautam Sheth Sep 6 '17 at 8:35
  • There is no environment on this.context. I'm running on an old framework version (sp-core-library: 1.0.0). Maybe it was added later? import Environment, { EnvironmentType } from "@microsoft/sp-core-library/lib/Environment"; is fine though (this line was added by VSC Intellisense autocomplete and differs from yours). – Heinrich Ulbricht Sep 6 '17 at 8:40
  • 1
    It could be, I think it was added during the GA. However, i am using the code mentioned above only, but I am running the latest version (1.2), which has app customizer at RC, so in your case, it could be different. – Gautam Sheth Sep 6 '17 at 9:05
  • 1
    I updated to 1.2.0 - now your code works. So it was introduced after GA. One note: this import I wrote above does NOT work: import Environment, { EnvironmentType } from "@microsoft/sp-core-library/lib/Environment" - will give webpack module resolution errors. – Heinrich Ulbricht Sep 15 '17 at 13:28

You can possibly play around and look for "CanvasControl" on the page (may be through jquery) to identify if it is a modern page or a classic page.

Another lengthier approach would be to look for the contents of managed property for canvascontent1 field. Here is the reference for it

Data for all web parts is stored in one page field in the content type, and that translates to one managed property in search – here are the details: Field name = “CanvasContent1” Managed property = “CanvasContent1OWSHTML”

  • Not as easy as it seems getting hold of the Canvas-elements in a way that seems reliable. I'll go for checking the existence of $(".CanvasZone") - as a temporary solution as long as the approach by Gautam doesn't work for me. A div with class CanvasZone exists in the modern experience, both read and edit mode. Not present in classic. – Heinrich Ulbricht Sep 6 '17 at 9:01
  • 1
    I would strongly discourage relying on divs or any other DOM elements on the page. If the UI changes, it will break your solution. You should use the public API instead. – Waldek Mastykarz - MVP Sep 7 '17 at 5:53
  • @waldek, Agree..this would be a dirty soln, not reliable. – Vipul Kelkar Sep 7 '17 at 6:24
  • @WaldekMastykarz-MVP - agreed. It'll be temporary. I promise... – Heinrich Ulbricht Sep 10 '17 at 11:49
  • 1
    Lol, no need to promise anything. Just something you need to keep in mind that reliability of your solution depends on it. :) – Waldek Mastykarz - MVP Sep 12 '17 at 7:06

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.