SharePoint Framework Summer 2020 Wish List; what's on yours?

Last September, I shared what items were on my wish list for the SharePoint Framework. The response from that post surprised me a bit… I didn’t expect a healthy discussion to start up in the comments and on social media. It’s been nine months since that post and I thought it was time for another installment - it’s the first official weeks of summer 2020, so it’s the time for another one!

I went back and read my post, as well as the conversations that sprung from it in the post’s comments and on social media. One thing I want to clarify is that this is my list & it’s focused on the developer aspects of SharePoint or those things that directly impact developers following the recommended guidelines for SharePoint Online extensions & solutions.

Before I refresh my wish list, let me explain why I’m doing this as it seems like it was missed last time around. Years ago I wrote that I didn’t think SharePoint was a development platform and received a lot of heat from people both inside & outside Microsoft. While the points I made in that post are dated, today my feelings are much the same. Why? Lack of confidence in SharePoint as a reliable platform is a big part of this.

Over the last few years, I’ve observed when it comes to developer topics, the SharePoint team doesn’t exactly have a track record you’d want to model for follow-through finishing features and addressing core issues with the features they’ve shipped.

When your job metrics focus on shipping features & not delivering on promises or finishing the job, that’s what you focus on. Keep this in mind as you read through my issues below… you’ll notice a theme.

previousWishlist.Repeat(MyState.Disappointed);

To start this off, it’s disappointing to see little forward progress on the items I pointed out in my previous post. Not because they’re on my list, but because these are commonly held items among SharePoint developers. They are things Microsoft has promised in the past so you’d expect at least some progress.

I really had hoped the next time I came back to this list I could talk about some improvements, but I’m hard-pressed to find any improvements on existing issues.

They’re all still on my list, but I’m not going to repeat my explanations here. If you’re interested, you can go back and read them:

Summer 2020 SharePoint Developer Wish List

Now let’s move onto some new items.

Fix the SharePoint list conflict with the SPFx

This one is hard to appreciate and understand. There are many client-side events that are defined and supposed to be raised from within the SharePoint Framework (SPFx) on SharePoint lists. Things like when a list view changes, the state changes, or just navigating from one list to another. The SPFx API contains events that should be triggered that developers can handle and address service events.

While they may have worked at one time, the team that’s responsible for the list UX rolls out changes that break these events with no consideration of the impact to developers… at least that’s how it seems.

Furthermore, when these issues arise as reported in the SharePoint developer issue list, they aren’t addressed. Sometimes you see someone from the list team jump in and say “we’re working on a fix” and maybe follow-up weeks or months later with “we rolled a fix out”, but there’s no detail or follow through explaining what was addressed or what the fix was. The community is left trying to figure out what happened and if things are really fixed or not.

This friction erodes confidence in the platform.

For example: #5321, #5034, #4819, #4547, #4061, #4056, #4054, #3236, #3117

My wish: Get the SPFx & lists teams in sync… today they act as they work for competing companies. The lists team should have test plans to make sure they don’t break someone else when they roll changes out. When there’s an issue, provide clear guidance like real product teams do with detail on what the issue is & when it’s resolved, what was fixed.

Fix & finish the SPFx + Microsoft Teams integration

Microsoft Teams is hugely popular, and it’s also a great option to host custom enterprise apps. Microsoft added support for using SPFx web parts to implement custom tabs and personal apps in Microsoft Teams. These solutions are hosted and served up by SharePoint Online in Microsoft Teams.

This is a great option for developers to build Microsoft Teams apps as they can leverage their existing SPFx knowledge and skills.

Except for one thing: it’s not reliable.

When I build an SPFx component that can be used in SharePoint Online and Microsoft Teams, I expect it to work.

But, if you head over to the SharePoint issue list, you’ll see tons of issues. Such as solutions not working in mobile or the desktop client, authentication issues, isolated web parts not working, and many more. And, like the other points, I’m raising in this post, they aren’t being addressed.

For example: #5823, #5739, #5736, #5320,

My ask: if I build it with SPFx & it works in SPO, it should work in Microsoft Teams - all experiences.

Until then, I don’t recommend someone use SPFx to extend Microsoft Teams. It’s just not reliable and has too many sharp edges you’ll potentially cut yourself on.

No follow through on SPFx extensions

When SPFx extensions were introduced soon after SPFx was released, Microsoft promised they were going to add the ability to expand on field controls to use them in an edit experience. That was 3 years ago… yet nothing.

Last year Microsoft said they were looking to add more extensions and placeholder options for application customizes. All we’ve seen is a preview for hijacking text before it’s sent from the search box (something we could have done with a bit of jQuery).

My wish: just follow through and finish the feature.

Enable (by unblocking) using SPFx to create custom forms

This is one of the most popular requests from customers. Last year at two different SPFx workshops at the SharePoint Conference, this was the number one request in both workshops.

Today, the only supported way of customizing forms in SharePoint is to use Power Apps. I get Microsoft wants the licensing money so they don’t want to give us options, but that’s what customers have been asking for: options.

We just want the option. If you’re confident PowerApps works for most people, then let us have another option and see what your customers do.

My wish: let me use SPFx to create a custom form for a list and replace the default new, edit or display form on a list.

What’s frustrating is that this isn’t all that hard to do, except for the fact Microsoft broke the ability to do this from the pre-modern lists.

There are properties on a list for each of these form types. However, modern lists ignore them so we don’t have an easy way to do this. I’m not looking for a big engineering effort… let’s start with an MVP:

Let me set the properties on a SPList object, via the REST API, to define the URL of the new & edit form
Let me override the display form option so I’m not forced to have the tiny side panel that works great most of the time, but it’s “one size fits all”

I’ll create a web part deployed as a single page app (SPA), create the full page app page and update the properties on the list to point to my SPA. I’ll handle all the read/write data access to the list and data validation.

Let’s see what people do and go from there.

Conclusion

I’m a fan of the SPFx and what Microsoft has built. This is the way we developers should be extending SharePoint Online in conjunction with other available tools. While it may seem like I’m unhappy and just complaining, that’s not at all the case.

The SPFx engineering team has done a great job so far! In fact, I’d be hard-pressed to request additional features… maybe SPFx is almost “done”!

I just feel like, at this point, it’s like we’ve built the booster, command module & lunar module in the mission to put a man on the moon… except for one thing: we forgot the landing legs & the door to get out of the LEM when we landed on the moon. We’re so close… just help with that final push!