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?

2 Answers 2


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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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