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?


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? 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. 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). 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. 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. 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. 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. Sep 7 '17 at 5:53
  • @waldek, Agree..this would be a dirty soln, not reliable. Sep 7 '17 at 6:24
  • @WaldekMastykarz-MVP - agreed. It'll be temporary. I promise... 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. :) Sep 12 '17 at 7:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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