Sp-dev-docs: `environment` missing on `WebPartContext` for O365 hosted SPFx/workbench

Created on 2 Dec 2016 · 15Comments · Source: SharePoint/sp-dev-docs

Expected or Desired Behavior

The environment property on the WebPartPageContext should exist on the O365 hosted SPFx implementation.

Observed Behavior

This property (and many others) is/are missing from SPFx in O365, yet in drop6 they exist in the local copy (& in local workbench).

Steps to Reproduce

When trying to do something such as this:

if (this.context.environment.type === EnvironmentType.Local)

The environment property is undefined when running on O365, but it is defined in the local drop6.

When debugging, here's what you get in O365:

But here's what you see in drop6 locally:

tooling

Source

andrewconnell

Most helpful comment

So, we are refactoring APIs for the next drop and the lack of API documentation has lead to this confusion. Apologies for that.

We moved the environment check up a level to the framework and hence it is no longer part of the web part context, but part of the core framework base.

Here is how you will use it now.

Import Environment and EnvironmentType from sp-client-base:

import {
  Environment,
  EnvironmentType
} from '@microsoft/sp-client-base'

Then in your code, you can use the following to check if local or SharePoint, which is the same as earlier except that it is no longer part of the context:

if(Environment.type == EnvironmentType.Local) {
    alert('local');
} else if(Environment.type == EnvironmentType.SharePoint) {
  alert('SharePoint');
}

I have tested this and it works. Please let us know if this works for you.

We are prepping up the API docs, changelogs etc., so it should be easier to track these sort of changes moving forward.

Thanks!

chakkaradeep on 7 Dec 2016

👍3

All 15 comments

Not sure if I'm seeing it correctly but it seems that drop 6 uses a newer build version than workbench available on O365. Versions of all packages included with drop 6 end with x.x.1 whereas on-line they are x.x.0. Could it be that the version mismatch causes issues @andrewconnell is seeing?
If so, going forward it would be helpful if developers could see the version of the workbench they are using. Thinking about future releases would it be possible to have different versions of the workbench aligned with the different releases?

waldekmastykarz on 2 Dec 2016

👍1

_I get we're still in dev-preview, but it does raise a possible issue that could happen in prod post GA..._

That's what I was observing too... and let's take that a bit further. SPFx prefers React... but what if I'm using a more current version of React? Or what if O365 wants to use a newer version of React that introduced a breaking change.

While your suggestion @waldekmastykarz "_going forward it would be helpful if developers could see the version of the workbench they are using_" is nice, but a dev shouldn't be blocked waiting for something to roll out esp when rollouts don't happen immediately, rather they are flighted through tenants. The local / hosted workbench (and production pages for that matter) should ensure they load the current file.

andrewconnell on 2 Dec 2016

So currently there is no way to resolve this?

DanielOlofsson77 on 5 Dec 2016

@DanielOlofsson77 I wouldn't say that... MSFT hasn't even jumped in on this thread... so I'd wait to hear from them. From my POV, they've got a file that they need to update in prod. Remember we're still in dev preview.

You can gate the call (what I did for now):

if (this.context.environment && this.context.environment.type === EnvironmentType.Local)

andrewconnell on 5 Dec 2016

👍1

@andrewconnell are you using the workbench from _layouts folder? That should be the latest. Let me test this as well.

chakkaradeep on 5 Dec 2016

👍1

@chakkaradeep yup... using https://[tenant].sharepoint.com/_layouts/workbench.aspx

andrewconnell on 6 Dec 2016

@andrewconnell SPFx made it into first release. @chakkaradeep this is a huge issue though as checking the enviornment.type is my primary method for determining if I should use SharePoint or mock data. Is there another recommended path to switch between mock and live data calls? I have been pointing devs to the following howto when learning to connect to SP data: https://dev.office.com/sharepoint/docs/spfx/web-parts/get-started/connect-to-sharepoint, but with environment.type broken in SP, that is a no go. I do understand we are still not in production, but I am still surprised this type of bug slipped into the drop.

eoverfield on 7 Dec 2016

@eoverfield there's a pretty easy way to gate this, just test if this.context.environment exists. I got around the bug with the following, but it's just a workaround for now.

if (this.context.environment && this.context.environment.type === EnvironmentType.Local)

andrewconnell on 7 Dec 2016

👍1

So, we are refactoring APIs for the next drop and the lack of API documentation has lead to this confusion. Apologies for that.

We moved the environment check up a level to the framework and hence it is no longer part of the web part context, but part of the core framework base.

Here is how you will use it now.

Import Environment and EnvironmentType from sp-client-base:

import {
  Environment,
  EnvironmentType
} from '@microsoft/sp-client-base'

Then in your code, you can use the following to check if local or SharePoint, which is the same as earlier except that it is no longer part of the context:

if(Environment.type == EnvironmentType.Local) {
    alert('local');
} else if(Environment.type == EnvironmentType.SharePoint) {
  alert('SharePoint');
}

I have tested this and it works. Please let us know if this works for you.

We are prepping up the API docs, changelogs etc., so it should be easier to track these sort of changes moving forward.

Thanks!

chakkaradeep on 7 Dec 2016

👍3

Reading the release notes for Drop 6, this was mentioned there as well. I updated to include the sample code to check the environment as well.

chakkaradeep on 7 Dec 2016

👍1

@andrewconnell Thanks for the temp workaround, simple, elegant and worked well.
@chakkaradeep I had issues updating my code to drop 6 following the update instructions, npm i failed, but I blame me for that. After starting with a new project straight with drop 6, I was able to use the following code successfully.

var dataService = (Environment.type === EnvironmentType.Test || Environment.type === EnvironmentType.Local) ?
new ListService.MockListsService() :
new ListService.ListsService(this.context);

eoverfield on 7 Dec 2016

@chakkaradeep The Connect to SharePoint page in the Dev Center needs updating to account for the changes, section "Method to render lists information"

bruzie on 9 Dec 2016

@bruzie Yep. @VesaJuvonen and I are working on a bunch of updates to the tutorials. Stay tuned!

chakkaradeep on 9 Dec 2016

Since all the labs have been updated accordingly for the drop 6 level, we'll close up this issue. We will do another round of updates immediately as part of the following drops / releases to avoid similar kind of issues.

VesaJuvonen on 22 Dec 2016

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues