Office 365 dev - tips for building a custom SPFx form

One project I worked on recently involved building a custom form as an SPFx web part – and in general I think this is a great option for “high-end” forms which need to have quite specific behaviour and/or look and feel. Also, the ability to designate the page as an SPFx application page means some of the unnecessary page furniture is removed, which is helpful. When thinking about forms in Office 365, I see a spectrum of options which looks something like (in order of increasing complexity/effort):

1. Out-of-the-box SharePoint list form 
2. PowerApps customised SharePoint list form 
3. Canvas PowerApp, embedded in a SharePoint page with the PowerApps web part 
4. Custom-developed form with SPFx and React 

So, we’re talking about the last option here.

The good news is that for an adequately-skilled SPFx developer, building one of these forms can be pretty quick - there are some very powerful building blocks to help. I see the overall recipe as something like:

• SPFx web part, most likely in a page converted to an SPFx application page
• React components – perhaps including some 3rd party form controls
• Use of Office UI Fabric React controls
• Use of the PnP React controls
• PnPJS to read/write data to a SharePoint list

By combining use of these ingredients with some extra steps to help users get to your form (see later sections on this), you can get to a rich solution with less effort than you might think.

Form controls used with SPFx, and dealing with data

Thinking about the list of ingredients above, you'll find you can go a long way by bringing in those controls and integrating them with your data. I think the following arrangement might be common:

Requirement	Source
Standard textboxes, buttons etc.	Office UI Fabric React
Dropdowns, including advanced formatting/behaviour	Office UI Fabric React
Taxonomy picker	PnP React taxonomy picker
People picker	PnP React people picker
File upload control (stored as list item attachments)	PnP React file upload control
File upload control (stored in another way)	Other 3rd party control (you handle the upload to SharePoint)

Most likely you'll need to allow existing items to be edited with your form, as well as new items to be created. PnPJS is perfect for simplifying the operations to fetch an existing item (typically from an item ID passed to the page), and also saving back to SharePoint. In your SPFx web part, you'll use React state as the go-between in the middle of your controls on the front-end, and your service code for the data layer.

In the end, my form looked something like this (shown here zoomed-out). You might notice a series of buttons at the top - these surface functionality such as "Save as draft", and although I think use of something like Office UI Fabric's CommandBar or ContextualMenu would be nice, the client preferred straight-forward buttons in this case. Otherwise it's just use of the controls described above:

Providing the edit item experience

Assuming your custom form stores items in a SharePoint list, you'll probably want to take some steps to integrate the default list experience with your form. A good example is ensuring that when a user edits an item, they are taken to your form rather than the out-of-the-box SharePoint list edit form. This can be accomplished by adding a column to your list with some JSON formatting defined to provide the link. Simply take the URL for your page (i.e. a page that you created and added your web part to), and use it in the JSON for the link. You should end up with something like this:

I used JSON like this:

Notice that I'm passing the current list item ID to my form. Within my SPFx web part, I have code which is looking for a value being passed in the 'itemId' URL parameter - if one is found, as described above I use PnPJS to:

• Fetch data for this item
• Set React state with these values, so that my form controls get set to these values

So that takes care of the edit experience.

Providing the 'new item' experience or customising new/edit/disp forms in modern lists

In my case, the new item experience can be provided simply by a big visual representation on the home page. Regular end-users do not use the list, and won't be pressing the 'new' button. In this case, things are simple. Chatting to colleagues (thanks Leo!), it *is* possible to override the new/edit/disp forms of a modern list, but currently there are issues if a modern page is the target and you want to pass any parameters in the URL (e.g. the item ID for the edit experience) - apparently something breaks completely and your form is unlikely to load. One approach which can work is to create a classic page, set the new/edit/disp form URLs of your list accordingly, and add JavaScript on the classic page to redirect on to the modern page hosting your SPFx form. You may need to hash/further encode any ID you're passing, and consider adding CSS to hide some page elements in case the user briefly sees them during the redirect process. That's about as good as it gets in summer 2019 apparently, and there's a UserVoice entry Allow us to develop custom modern forms with custom edit experience to request better integration - the good news is the status of this has recently changed to "Thinking about it". So, hopefully this story will be improved soon for those needing tight integration between your custom form and the out-of-the-box list UI.

Setting the page to be an SPFx app page

Once you've developed your web part, you'll want to make sure it works well on the page - and typically you'll want to remove some of the "page furniture", so that your form is the focus and there are fewer distractions. On a modern page, you can do certain things like set the title area to the "Plain" layout - this will reduce the header area, but if your form has some kind of header/title you'll still get duplication between this and the page title.

And what about the problem that a page author could accidentally edit the page and remove the web part?

Both of these problems can be solved by converting the page to be an SPFx app page. On one of these, only a single web part can be used, it's properties cannot be edited and the title area is removed. The two images below compare my form before being converted to an app page (left) and afterwards (right):

As you can see, the title area is removed. Also, if I flick the page into edit mode, the web part cannot be removed and the only options I see relate to the page title:

So, less chance of an authoring 'accident' happening to your form now. If the page wasn't originally created as an app page, converting can be done by PowerShell or even by some quick JavaScript in the browser console as a one-off. See here for more details - https://docs.microsoft.com/en-us/sharepoint/dev/spfx/web-parts/single-part-app-pages. Of course, you could also remove the left navigation if you like too.

Using the PnP Taxonomy Picker control in such a form

One area I wanted to talk about here was a quirk in the PnP Taxonomy Picker control (a common control for these forms). Like many others in this toolkit, the control itself is excellent and would be a significant task on it’s own if you had to write it. Let’s all buy Elio a(nother) beer next time we see him 😉

The taxonomy picker is easy to add to your web part, and it takes care of populating itself with terms from a term set that you provide (by name or ID). A typical declaration looks something like this:

<TaxonomyPicker allowMultipleSelections={false} termsetNameOrID="b2a79b4b-9d64-46d9-8a94-38f8809f8d12"
  panelTitle="Select Region"
  label=""
  initialValues={this.state.selectedRegion}
  context={this.props.context}
  onChange={this._onRegionTaxPickerChange}
  isTermSetSelectable={false} />

That would give something on your page like this:

A couple of other notes would be:

• initialValues – use this property to set the value of the control. So if your form is being used to edit an existing list item, fetch the value from data and set this property – since I’m using React, this simply comes from a value in my web part state
• onChange – what should happen when a term is selected. In React, you’d usually store the value in state at this point, ready for later insert/update to SharePoint

So far, so straightforward. However, something to be aware of is that the onChange() method provides the item in the form of an IPickerTerm object – something provided by the PnP code. However, such an object cannot be passed to SharePoint using PnPJS or REST, since the REST API expects a different format. IPickerTerm has the following properties:

• name
• path
• key
• termSet
• termSetName

However, PnPJS or the SharePoint REST API expect an object with the following properties (this is for a single-value taxonomy field):

• TermGuid
• Label
• WssId

Sidenote - things are a bit more complex if your field stores multiple values. Alex Terentiev has an article on this that may help you out.

So, you’ll need to some mapping between the two object types if you’re reading/writing data to SharePoint from the PnP taxonomy control (including setting the selected value of the control to the current value stored in a SharePoint list item).

Some important things to know here are:

• A value of -1 can be used for the WssId value – you don’t need to do anything more, SharePoint will sort this out
• The TermGuid property maps to the IPickerTerm.key property
• The Label property maps to the IPickerTerm.name property

With that in mind, we just need some code to map between the two object types - I found that having two methods such as the following is needed (to convert in each direction):

Summary

Hopefully this post has been a useful round-up of considerations when building custom SPFx forms. I think this approach works great for more complex forms, and the building blocks listed here really do help reduce the amount of code required. Setting the page to be an app page to eliminate unnecessary page furniture helps, as does integrating with the SharePoint list UI for the new/edit/display experience. In addition to Office UI Fabric, the PnP React controls are all extremely useful in SPFx forms and the TaxonomyPicker is no exception. If you use that one, you'll probably find you need some code like my sample above to help you map between the format used by the control and that used by the SharePoint REST API or PnPJS, but that's not too complex. Happy coding!