Updated guidance (SharePoint#839)

* Updated tutorial on sharing data between web parts

* Updated guidance on sharing data between web parts

* Updated guidance on migrating jQuery DataTables solutions

* Updated guidance on migrating jQuery FullCalendar solutions

Author: waldekmastykarz

docs/spfx/web-parts/guidance/migrate-jquery-datatables-script-to-spfx.md

@@ -189,7 +189,7 @@ export default class ItRequestsWebPart extends BaseClientSideWebPart<IItRequests
   public render(): void {
     this.domElement.innerHTML = `
       <link rel="stylesheet" type="text/css" href="https://cdn.datatables.net/1.10.15/css/jquery.dataTables.min.css" />
-      <table id="requests" class="display ${styles.helloWorld}" cellspacing="0" width="100%">
+      <table id="requests" class="display ${styles.itRequests}" cellspacing="0" width="100%">
         <thead>
             <tr>
                 <th>ID</th>
@@ -505,7 +505,7 @@ To function properly, TypeScript requires type definitions for the different lib
 Start by installing type definitions for jQuery and DataTables by executing in the command line:
 
 ```sh
-npm install --save-dev @types/jquery @types/jquery.datatables
+npm install --save-dev @types/jquery@1 @types/datatables.net
 ```
 
 Type definitions for Moment.js are distributed together with the Moment.js package. Even though, you're loading Moment.js from a URL, in order to use its typings, you still need to install the Moment.js package in the project.
@@ -530,7 +530,7 @@ Having defined **$** as jQuery you can now remove the local definition of **$**
 var $: any = (window as any).$;
 ```
 
-Because DataTables is a jQuery plugin that attaches itself to jQuery you cannot load its type definition directly. Instead, you have to add it to the list of types loaded globally. In the code editor, open the **./tsconfig.json** file and to the **types** array add **jquery.datatables**:
+Because DataTables is a jQuery plugin that attaches itself to jQuery you cannot load its type definition directly. Instead, you have to add it to the list of types loaded globally. In the code editor, open the **./tsconfig.json** file and to the **types** array add **datatables.net**:
 
 ```json
 {
@@ -544,7 +544,7 @@ Because DataTables is a jQuery plugin that attaches itself to jQuery you cannot
     "types": [
       "es6-promise",
       "es6-collections",
-      "jquery.datatables",
+      "datatables.net",
       "webpack-env"
     ]
   }
@@ -607,7 +607,7 @@ export default class ItRequestsWebPart extends BaseClientSideWebPart<IItRequests
       },
       columnDefs: [{
         targets: 4,
-        render: $.fn.dataTable.render.moment('YYYY/MM/DD')
+        render: ($.fn as any).dataTable.render.moment('YYYY/MM/DD')
       }]
     });
   }
@@ -629,7 +629,7 @@ import * as $ from 'jquery';
 import * as moment from 'moment';
 
 /* tslint:disable:no-function-expression */
-$.fn.dataTable.render.moment = function (from: string, to: string, locale: string): (d: any, type: string, row: any) => string {
+($.fn as any).dataTable.render.moment = function (from: string, to: string, locale: string): (d: any, type: string, row: any) => string {
 /* tslint:enable */
     // Argument shifting
     if (arguments.length === 1) {

docs/spfx/web-parts/guidance/migrate-jquery-fullcalendar-script-to-spfx.md

@@ -185,7 +185,7 @@ When prompted, define values as follows:
 - **WebPart** as the client-side component to create
 - **Tasks calendar** as your web part name
 - **Shows tasks in the calendar view** as your web part description
-- **No javaScript web framework** as the starting point to build the web part
+- **No JavaScript web framework** as the starting point to build the web part
 
 ![SharePoint Framework Yeoman generator with the default choices](../../../../images/fullcalendar-yeoman.png)
 
@@ -365,7 +365,7 @@ function updateTask(id, startDate, dueDate) {
 }
 ```
 
-This code is almost identical with the original code of the Script Editor Web Part customization. The only difference is that where the original code retrieved the URL of the current web from the global **\_spPageContextInfo** variable set by SharePoint (lines 8, 45, 96 and 104), the code in the SharePoint Framework uses a custom variable that you will have to set in the web part. SharePoint Framework client-side web parts can be used both on classic and modern pages. While the **_spPageContextInfo** variable is present on classic pages, it's not available on modern pages which is why you can't rely on it and need a custom property that you can control yourself instead.
+This code is almost identical with the original code of the Script Editor Web Part customization. The only difference is that where the original code retrieved the URL of the current web from the global **\_spPageContextInfo** variable set by SharePoint (lines 8, 45, 96 and 104), the code in the SharePoint Framework uses a custom variable that you will have to set in the web part. SharePoint Framework client-side web parts can be used both on classic and modern pages. While the **\_spPageContextInfo** variable is present on classic pages, it's not available on modern pages which is why you can't rely on it and need a custom property that you can control yourself instead.
 
 In order to reference this file in the web part, in the code editor, open the **./src/webparts/tasksCalendar/TasksCalendarWebPart.ts** file and change the **render** method to:
 

docs/spfx/web-parts/guidance/share-data-between-web-parts.md

@@ -1,7 +1,5 @@
 # Share Data Between Client-Side Web Parts
 
-> Note. This article has not yet been verified with the SPFx GA version, so you might have challenges making this work as described using the latest release.
-
 When building client-side web parts, loading data once and reusing it across different web parts will help you improve the performance of your pages and decrease the load on your network. This article describes a number of approaches that you can use to share data across multiple web parts.
 
 ## Why Share Data Between Web Parts
@@ -327,12 +325,14 @@ SharePoint Framework services can be built using the same project build system a
 
 ```json
 {
-  "$schema": "../../../node_modules/@microsoft/sp-module-interfaces/lib/manifestSchemas/jsonSchemas/clientSideComponentManifestSchema.json",
+  "$schema": "https://dev.office.com/json-schemas/spfx/client-side-library-manifest.schema.json",
 
   "id": "69b1aacd-68f2-4147-8433-8efb08eae331",
   "alias": "DocumentsService",
   "componentType": "Library",
-  "version": "0.0.1",
+
+  // The "*" signifies that the version should be taken from the package.json
+  "version": "*",
   "manifestVersion": 2
 }
 ```

docs/spfx/web-parts/guidance/tutorial-share-data-between-web-parts-global-variable.md

@@ -62,14 +62,21 @@ Remove the standard `description` property from the web part manifest. Open the
 
 ```json
 {
-  "$schema": "../../../node_modules/@microsoft/sp-module-interfaces/lib/manifestSchemas/jsonSchemas/clientSideComponentManifestSchema.json",
+  "$schema": "https://dev.office.com/json-schemas/spfx/client-side-web-part-manifest.schema.json",
 
   "id": "7a7e3aa9-5d8a-4155-936b-0b0e06e9ca11",
   "alias": "RecentDocumentsWebPart",
   "componentType": "WebPart",
-  "version": "0.0.1",
+
+  // The "*" signifies that the version should be taken from the package.json
+  "version": "*",
   "manifestVersion": 2,
 
+  // If true, the component can only be installed on sites where Custom Script is allowed.
+  // Components that allow authors to embed arbitrary script code should set this to true.
+  // https://support.office.com/en-us/article/Turn-scripting-capabilities-on-or-off-1f2c515f-5d7e-448a-9fd7-835da935584f
+  "requiresCustomScript": false,
+
   "preconfiguredEntries": [{
     "groupId": "7a7e3aa9-5d8a-4155-936b-0b0e06e9ca11",
     "group": { "default": "Under Development" },
@@ -372,14 +379,21 @@ Remove the standard `description` property from the web part manifest. Open the
 
 ```json
 {
-  "$schema": "../../../node_modules/@microsoft/sp-module-interfaces/lib/manifestSchemas/jsonSchemas/clientSideComponentManifestSchema.json",
+  "$schema": "https://dev.office.com/json-schemas/spfx/client-side-web-part-manifest.schema.json",
 
   "id": "71a6f643-1ac1-47ee-a9f1-502ef52f26d4",
   "alias": "RecentDocumentWebPart",
   "componentType": "WebPart",
-  "version": "0.0.1",
+
+  // The "*" signifies that the version should be taken from the package.json
+  "version": "*",
   "manifestVersion": 2,
 
+  // If true, the component can only be installed on sites where Custom Script is allowed.
+  // Components that allow authors to embed arbitrary script code should set this to true.
+  // https://support.office.com/en-us/article/Turn-scripting-capabilities-on-or-off-1f2c515f-5d7e-448a-9fd7-835da935584f
+  "requiresCustomScript": false,
+
   "preconfiguredEntries": [{
     "groupId": "71a6f643-1ac1-47ee-a9f1-502ef52f26d4",
     "group": { "default": "Under Development" },
@@ -490,19 +504,19 @@ import {
   DocumentCard,
   DocumentCardPreview,
   DocumentCardTitle,
-  DocumentCardActivity,
-  ImageFit
-} from 'office-ui-fabric-react';
+  DocumentCardActivity
+} from 'office-ui-fabric-react/lib/DocumentCard';
+import { ImageFit } from 'office-ui-fabric-react/lib/Image';
 import { IDocument } from '../../IDocument';
 import styles from './RecentDocument.module.scss';
 import { IRecentDocumentProps } from './IRecentDocumentProps';
 
-export default class RecentDocument extends React.Component<IRecentDocumentProps, void> {
+export default class RecentDocument extends React.Component<IRecentDocumentProps, {}> {
   public render(): React.ReactElement<IRecentDocumentProps> {
     const document: IDocument = this.props.document;
 
     return (
-      <div className={styles.helloWorld}>
+      <div className={styles.recentDocument}>
         <DocumentCard onClickHref={document.url}>
           <DocumentCardPreview previewImages={[{
             name: document.title,
@@ -719,7 +733,7 @@ import { IDocument } from '../services/documentsService';
 instead of:
 
 ```ts
-import { IDocument } from '../services/documentsService/IDocument.ts';
+import { IDocument } from '../services/documentsService/IDocument';
 ```
 
 If at some point you decided that it's better to move the **IDocument.ts** file to a subfolder or merge a few files together, the only thing that you would change is the path in the barrel definition (**./src/services/documentsService/index.ts**). All elements in the project could still use the exact same relative path to the **documentsService** folder to reference the `IDocument` interface.