When developing a SharePoint Framework Extension to display a custom header and/or footer, the SharePoint Composite Header can be very redundant to the custom header.

The Composite Header (css classname is 'ms-compositeHeader'), is what SharePoint provide out of the box and includes the square site logo, site name and navigation.

When creating your own custom header that includes all of these things and possibly more, the existence of the Composite Header is redundant and can be confusing for users...(Ex: redundant navigation).

While CSS can be used to hide this, such a technique is not playing within the rules of only controlling the DOM elements created by the extension.

This request is to have a configurable property created that can hide the composite header to remove the redundancy when creating a custom header.

This could be a site property configured using PowerShell or a property defined in the SPFx Extension itself.

This would help ensure that rogue overriding of the CSS to hide the Composite Header does not occur and helps developers to stay within the rules requested by Microsoft when developing for the Modern Experience.

While the SharePoint online version is supported, we would like to see the SharePoint on-prem versions (SharePoint 2016/2019) supported with .NET standard CSOM APIs.

https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform/suggestions/16585795-support-net-core-with-csom
^ this only allows for SharePoint Online .NET Standard CSOM support.

Many customers have significant investments and longer term roadmaps to get to SharePoint Online, but in the interim would like to start developing solutions that can be more easily converted to work in SharePoint Online along with being able to leverage the latest version of the Microsoft technology stack - that is growing the skillsets / toolset familiarity without waiting for longer term plans to move fully to SharePoint Online.

We can do templating on SharePoint, through Site Designs and Site Scripts. We now also have the option to "Create a Microsoft Teams from Template".
Unfortunately, both do not work together. We either have a templated SharePoint site with a generic Teams or a templated Teams with generic SharePoint site.

I would love the possibility to combine both templating options. Preferrably with an API from day 1.
This would give us an end to end templating scenario, where we can create preconfigured Teams with a preconfigured SharePoint site. (In the future, hopefully with a preconfigured Planner etc as well ;) ).

Currently working with the API's for drive, graph, sharepoint are very difficult due to the throttling that can be encountered.

Each api offers different guidance to avoid throttling. Example are:
1) use a special user-agent header
2) respect the retry-after header

Speaking with microsoft representatives they instruct us to perform major api processing in off peak hours. Additionally tenant's can have hard locks placed on them.

This request is to get better information around tenant usage returned in the API's.

1) If a tenant is hard locked, tell us in a distinct message so that don't just hammer the requests over and over again.
2) Give us feedback in our api calls regarding the health of a tenant. If we are approaching a threshold limit, give us some type of header we can use to instruct us to slow down our requests.

It would be nice to have the ability to extend some of the functionality in the SharePoint Admin Center. Specifically, the ability to deploy SharePoint Framework Web Parts into the Admin Center (via an App Page?). Currently, the community builds lots of SPFx Web Parts to fill the gaps in the Modern UX.

Such Web Parts include:
Theme Manager
Site Design Studio/Manager

These are SPFx solutions that have been built to help better manage our environments through a UX experience (as there isn't one via First Party). It would be nice to have a centralized location where these SPFx solutions can live and be used.

As described in https://github.com/SharePoint/sp-dev-docs/issues/3110

Untill SPFx version 1.4.1 there was an option to use the ClientSideWebPartManager to create webparts from another webpart. Currently we are working some time already on a custom 'widgetzone' with an easy dragging and dropping grid layout (Muuri, https://haltu.github.io/muuri/), user zones and a lot of other awesome stuff which isn't supported by the default SharePoint grid. (which is off course understandable)

Currently I am not seeing another path to make this possible, so for now we have to stick on the SPFx 1.4.1 release. I do understand this is something not many companies will encounter, but I can also see some other scenario's where this might come in handy. For example with reusing an spfx webpart to perform an action like creating sites in an custom navigation spfx extension.

JSON formatting supports a few field types, but currently we cannot do any kind of JSON treatment on multiline RTF columns.

The JSON formatting framework outputs @currentField as text inside the selected elmType.

I propose two possibilities which are not mutually exclusive to improve compatibility:

elmType: html

this elmType would assume the content of the @currentField to be well-formed html, and just use that at the column cell's content.

@currentField.html
This selector would treat the contents of the currentfield as well-formed html, and would allow it to be inserted inside an elmType.

Bonus points if the html tree can be traversed using object notation as well.