You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/spfx/debug-modern-pages.md
+39-36Lines changed: 39 additions & 36 deletions
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,7 @@
1
1
---
2
2
title: Debug SharePoint Framework solutions on modern SharePoint pages
3
3
description: Guidance on how to debug SharePoint Framework solutions on modern SharePoint pages
4
-
ms.date: 04/21/2020
4
+
ms.date: 05/09/2020
5
5
ms.prod: sharepoint
6
6
localization_priority: Priority
7
7
---
@@ -59,13 +59,13 @@ When you add a new SharePoint Framework extension to your project, the SharePoin
59
59
60
60
Next to the default configuration, the SharePoint Framework Yeoman generator will create an entry for each extension that you add to your project. Each entry contains a URL of the modern page that should be used to test the particular extension, the list of extensions that should be loaded and for each extension, the list of properties that should be set on them. To use the particular serve configuration, execute in the command line:
61
61
62
-
```sh
62
+
```shell
63
63
gulp serve --config=<name>
64
64
```
65
65
66
66
for example:
67
67
68
-
```sh
68
+
```shell
69
69
gulp serve --config=helloWorld
70
70
```
71
71
@@ -75,11 +75,15 @@ After running this command, gulp will start your web browser with the modern pag
75
75
76
76
Once you confirm, the page will load with the extensions you specified in your serve configuration.
77
77
78
+
### Disabling debug scripts
79
+
80
+
By default, when debug scripts are enabled and allowed once on a page, they will be allowed throughout the browser session. To disable the debug scripts from loading without ending your browser session or manually deleting the session data, include the URL parameter `reset=true` in the request.
81
+
78
82
### Debug extensions by manually building the debug URL
79
83
80
84
If you're working with a version of the SharePoint Framework older than 1.3.0, and you want to debug an extension on a modern page, you have to manually construct the URL with the required parameters. First, start the local gulp server, by in the command line changing the working directory to your project folder and then executing:
81
85
82
-
```sh
86
+
```shell
83
87
gulp serve --nobrowser
84
88
```
85
89
@@ -91,14 +95,14 @@ To debug an Application Customizer, to the URL of your modern page, add `?loadSP
91
95
92
96
Following are the query string parameters that you need to add:
93
97
94
-
Parameter|Description
95
-
---------|-----------
96
-
`loadSPFX=true`|Ensures that the SharePoint Framework is loaded on the page. For performance reasons, the framework does not load unless at least one extension is registered. Because no components are registered, you must explicitly load the framework.
97
-
`debugManifestsFile`|Specifies that you want to load SPFx components that are locally served. The loader only looks for components in the app catalog (for your deployed solution) and the SharePoint manifest server (for the system libraries).
98
-
`customActions`|Simulates a custom action. When you deploy and register this component in a site, you'll create this **CustomAction** object and describe all the different properties you can set on it.
99
-
`key`|Use the GUID of the extension as the key to associate with the custom action. This has to match the ID value of your extension, which is available in the extension manifest.json file.
100
-
`___location`|The type of custom action. Use `ClientSideExtension.ApplicationCustomizer` for the Application Customizer extension.
101
-
`properties`|An optional JSON object that contains properties that are available via the this.properties member
|`loadSPFX=true`|Ensures that the SharePoint Framework is loaded on the page. For performance reasons, the framework does not load unless at least one extension is registered. Because no components are registered, you must explicitly load the framework.|
101
+
|`debugManifestsFile`|Specifies that you want to load SPFx components that are locally served. The loader only looks for components in the app catalog (for your deployed solution) and the SharePoint manifest server (for the system libraries).|
102
+
|`customActions`|Simulates a custom action. When you deploy and register this component in a site, you'll create this **CustomAction** object and describe all the different properties you can set on it.|
103
+
|`key`|Use the GUID of the extension as the key to associate with the custom action. This has to match the ID value of your extension, which is available in the extension manifest.json file.|
104
+
|`___location`|The type of custom action. Use `ClientSideExtension.ApplicationCustomizer` for the Application Customizer extension.|
105
+
|`properties`|An optional JSON object that contains properties that are available via the this.properties member|
102
106
103
107
With the parameters added to the URL, reload the page in the web browser. The page will show a popup asking you to confirm that you now will be loading debug scripts.
104
108
@@ -112,14 +116,14 @@ To debug a field customizer, to the URL of your list view page, add `?loadSPFX=t
112
116
113
117
Following are the query string parameters that you need to add:
114
118
115
-
Parameter|Description
116
-
---------|-----------
117
-
`loadSPFX=true`|Ensures that the SharePoint Framework is loaded on the page. For performance reasons, the framework does not load unless at least one extension is registered. Because no components are registered, you must explicitly load the framework.
118
-
`debugManifestsFile`|Specifies that you want to load SPFx components that are locally served. The loader only looks for components in the app catalog (for your deployed solution) and the SharePoint manifest server (for the system libraries).
119
-
`fieldCustomizers`|indicates which fields in your list should have their rendering controlled by the Field Customizer. The ID parameter specifies the GUID of the extension that should be used to control the rendering of the field. The properties parameter is an optional text string containing a JSON object that is deserialized into `this.properties` for your extension.
120
-
`key`|Use the internal name of the field as the key.
121
-
`id`|The GUID of the Field Customizer extension associated with this field.
122
-
`properties`|The property values defined in the extension. In this example, `sampleText` is a property defined by the extension.
119
+
|Parameter|Description|
120
+
|---------|-----------|
121
+
|`loadSPFX=true`|Ensures that the SharePoint Framework is loaded on the page. For performance reasons, the framework does not load unless at least one extension is registered. Because no components are registered, you must explicitly load the framework.|
122
+
|`debugManifestsFile`|Specifies that you want to load SPFx components that are locally served. The loader only looks for components in the app catalog (for your deployed solution) and the SharePoint manifest server (for the system libraries).|
123
+
|`fieldCustomizers`|indicates which fields in your list should have their rendering controlled by the Field Customizer. The ID parameter specifies the GUID of the extension that should be used to control the rendering of the field. The properties parameter is an optional text string containing a JSON object that is deserialized into `this.properties` for your extension.|
124
+
|`key`|Use the internal name of the field as the key.|
125
+
|`id`|The GUID of the Field Customizer extension associated with this field.|
126
+
|`properties`|The property values defined in the extension. In this example, `sampleText` is a property defined by the extension.|
123
127
124
128
With the parameters added to the URL, reload the page in the web browser. The page will show a popup asking you to confirm that you now will be loading debug scripts.
125
129
@@ -133,14 +137,14 @@ To debug a list view command set, to the URL of your list view page, add `?loadS
133
137
134
138
Following are the query string parameters that you need to add:
135
139
136
-
Parameter|Description
137
-
---------|-----------
138
-
`loadSPFX=true`|Ensures that the SharePoint Framework is loaded on the page. For performance reasons, the framework does not load unless at least one extension is registered. Because no components are registered, you must explicitly load the framework.
139
-
`debugManifestsFile`|Specifies that you want to load SPFx components that are locally served. The loader only looks for components in the app catalog (for your deployed solution) and the SharePoint manifest server (for the system libraries).
140
-
`customActions`|simulates a custom action. You can set many properties on this CustomAction object that affect the look, feel, and ___location of your button; we’ll cover them all later.
141
-
`key`|GUID of the extension.
142
-
`Location`|Where the commands are displayed. The possible values are: `ClientSideExtension.ListViewCommandSet.ContextMenu`: The context menu of the item(s), `ClientSideExtension.ListViewCommandSet.CommandBar`: The top command set menu in a list or library. `ClientSideExtension.ListViewCommandSet`: Both the context menu and the command bar (corresponds to `SPUserCustomAction.Location="CommandUI.Ribbon"`).
143
-
`properties`|An optional JSON object containing properties that are available via the this.properties member.
|`loadSPFX=true`|Ensures that the SharePoint Framework is loaded on the page. For performance reasons, the framework does not load unless at least one extension is registered. Because no components are registered, you must explicitly load the framework.|
143
+
|`debugManifestsFile`|Specifies that you want to load SPFx components that are locally served. The loader only looks for components in the app catalog (for your deployed solution) and the SharePoint manifest server (for the system libraries).|
144
+
|`customActions`|simulates a custom action. You can set many properties on this CustomAction object that affect the look, feel, and ___location of your button; we’ll cover them all later.|
145
+
|`key`|GUID of the extension.|
146
+
|`Location`|Where the commands are displayed. The possible values are: `ClientSideExtension.ListViewCommandSet.ContextMenu`: The context menu of the item(s), `ClientSideExtension.ListViewCommandSet.CommandBar`: The top command set menu in a list or library. `ClientSideExtension.ListViewCommandSet`: Both the context menu and the command bar (corresponds to `SPUserCustomAction.Location="CommandUI.Ribbon"`).|
147
+
|`properties`|An optional JSON object containing properties that are available via the this.properties member.|
144
148
145
149
With the parameters added to the URL, reload the page in the web browser. The page will show a popup asking you to confirm that you now will be loading debug scripts.
146
150
@@ -152,7 +156,7 @@ Once you confirm, the page will load with the extensions you specified in your s
152
156
153
157
To test the local versions of your SharePoint Framework client-side web parts on modern SharePoint pages in your tenant, first, start the local gulp server, by changing the working directory to your project folder and executing in the command line:
154
158
155
-
```sh
159
+
```shell
156
160
gulp serve --nobrowser
157
161
```
158
162
@@ -180,26 +184,25 @@ Using the SharePoint workbench, you can only test web parts from your solution.
180
184
181
185
## Debug SharePoint Framework web parts -- an alternative approach
182
186
183
-
If you build your spfx webpart solution without the --ship parameter as following
187
+
If you build your SPFx webpart solution without the --ship parameter as following
184
188
185
-
```sh
189
+
```shell
186
190
gulp bundle
187
191
gulp package-solution
188
192
```
189
193
190
-
the packages generated will reference the code from your local computer (https://localhost:4321). You can deploy the solution to the app catalog as you normally would.
194
+
the packages generated will reference the code from your local computer (https://localhost:4321). You can deploy the solution to the app catalog as you normally would.
191
195
192
-
You can then start your local server by running
196
+
You can then start your local server by running
193
197
194
-
```sh
198
+
```shell
195
199
gulp serve --nobrowser
196
200
```
197
201
198
-
Now you can go back to a SharePoint site where the solution has been deployed and add the webparts to any page -- modern or classic-- and the webpart code will be loaded from your local development environment. You can debug your webparts just as you would if you ran 'gulp serve' and added your webpart to the workbench.
202
+
Now you can go back to a SharePoint site where the solution has been deployed and add the webparts to any page, modern or classic, and the webpart code will be loaded from your local development environment. You can debug your webparts just as you would if you ran 'gulp serve' and added your webpart to the workbench.
199
203
200
204
This approach should only be used when you are in development mode. If you deploy an app to the app catalog that points to your local host, it will fail to run if your development environment is not running.
201
205
202
-
203
206
## See also
204
207
205
208
-[Debug SharePoint Framework solutions in Visual Studio Code](debug-in-vscode.md)
0 commit comments