Stop Reinventing SPFx- Building Better SharePoint Solutions with PnP React Controls with Siddharth Vaghasia [MVP]

Modern SharePoint development does not mean building every component from scratch. In this episode of the M365 FM Podcast, Mirko Peters talks with Microsoft MVP Siddharth Vaghasia about building production-ready SharePoint Framework (SPFx) solutions by combining the right Microsoft 365 technologies with reusable community components.Siddharth brings nearly 18 years of experience across the Microsoft technology stack, from .NET and the early days of SharePoint Server to SharePoint Online, Microsoft 365, Power Platform, Azure, and modern SPFx development.

WHEN SHOULD YOU ACTUALLY USE SPFx?
Not every SharePoint requirement needs custom development. Siddharth explains a simple principle: first determine whether Microsoft already provides the functionality. If the requirement can reasonably be solved with standard SharePoint capabilities, avoid unnecessary customization.SPFx becomes valuable when organizations need experiences, integrations, or interfaces that cannot be delivered effectively with out-of-the-box functionality.

SPFx VS POWER PLATFORM
Should you build the solution with SPFx or Power Apps?The discussion explores where each approach fits. Power Apps can be effective for relatively straightforward forms, conditional fields, business rules, and scenarios where citizen development and low-code maintainability matter.SPFx becomes particularly powerful when developers need greater control over the user interface, complex data handling, reusable components, APIs, or sophisticated application experiences directly inside SharePoint. Siddharth also argues that generative AI coding tools are changing the traditional assumption that pro-code development necessarily takes longer than low-code development.

THE MODERN SPFx TECHNOLOGY STACK
A modern SPFx project brings together several technologies rather than relying on one framework.Siddharth breaks down the roles of TypeScript, React, Fluent UI, PnPjs, and PnP React Controls. TypeScript provides stronger typing and compile-time checks, while Fluent UI helps custom solutions retain the familiar Microsoft user experience.PnPjs simplifies interaction with SharePoint, Microsoft Graph, and other Microsoft 365 services by replacing repetitive REST request code with reusable abstractions.

STOP REBUILDING CONTROLS THAT ALREADY EXIST
One of the central lessons of the episode is simple: professional development does not mean writing everything yourself.PnP React Controls provide SharePoint-aware and Microsoft 365-aware components for common development requirements. Instead of repeatedly creating the UI, API calls, data binding, and associated logic for components such as file pickers, developers can use established community controls.Siddharth's preferred approach is to check existing capabilities first: use Microsoft functionality when available, then Fluent UI or PnP React Controls where they satisfy the requirement, and create a custom component only when the required functionality does not already exist.

THE FIVE PnP REACT CONTROLS DEVELOPERS SHOULD KNOW
If Siddharth had to choose only five controls, his selection would be People Picker, Taxonomy Picker, List View, File Picker, and Live Persona.These components cover several recurring requirements in enterprise SharePoint applications, including selecting users, working with managed metadata, presenting SharePoint data, selecting or uploading files, and displaying Microsoft 365 user information.

BUILDING REAL APPLICATIONS INSIDE SHAREPOINT
The conversation moves from individual controls to application architecture with the example of a sophisticated project management solution.SharePoint lists can provide the underlying data layer for projects, customers, resources, and tasks, while SPFx can deliver a unified application experience containing dashboards, project views, charts, CRUD operations, role-specific interfaces, task management, and na

Yeah, welcome everybody to a new episode of the M365 and podcast.

SharePoint framework has become one of the most important technologies for

developers who need to extend Microsoft 365 beyond what

organizations can accomplish with configurations alone.

But there's a major difference between simply building

an SPF-X solution and building one that's made in

a channel-resonable performance accessibility and ready for productions.

And developers don't have built everything themselves.

The Microsoft 365 community has created an enormous ecosystem around

SPF-X and including PMP-REC controls and that can dramatically

accelerate development by providing, providing proven building blocks for

common SharePoint and Microsoft 365 sinners.

My guest today is Shina Vagascha.

Yeah, sorry.

Sorry.

He's a Microsoft MBB for office development independent

console and freelancer, founders, speaker, blogger, community

organizer and specialized Microsoft 365 SharePoint SPF-X

Power Platform in Azure.

Today we are going deep into modern SharePoint development SPF-X

architecture, React, PMP-REC controls, Microsoft Graph, APs,

modernification, power platform, integrations, product,

architecture, performance governance, and so on.

And especially also AI.

So Shina, welcome to the M665 podcast.

Thank you, Marco.

And thank you for inviting me.

Definitely this is going to be a good topic to have the discussion

around considering the SPF-X is still relevant in terms of how

SharePoint has been customized and everything.

And as you rightly said, the community has, you know,

bring a very good library around it, so people should be knowing about that.

So how did you organically get into the Microsoft technology from,

however you started?

So I started around here, I mean, like since my career started, right?

Like almost 18 years, I had been always working on Microsoft technology

step.

So I started as a .NET developer when I started my IT professional career.

I was working on ASP.NET and Windows applications and that sort of thing.

But gradually after couple of years, I was kind of introduced to SharePoint,

which was SharePoint on premises back then, right?

And then in a way, you know, the journey,

basically kind of continued from SharePoint on premises from SharePoint

most 2007 to SharePoint 2010 to SharePoint 2013 to 2019.

It's only SharePoint 2016, I believe, which I have not worked on.

Okay, but otherwise I have worked on all kind of version of SharePoint.

And then of course, you know, when it gradually evolved into SharePoint online,

cloud and Microsoft 365.

But yeah, this was my, you know, first kind of experience with Microsoft.

Yeah, when you say you have these all these SharePoint experience,

was the moving from a say traditional SharePoint development to SPFX difficult?

In a way, yeah, it took some time to grasp, you know,

how when SPFX was introduced, right?

Because the traditional way of customizing SharePoint was more or less in and

around using JavaScript and using content editor web part.

And if at all, we needed to have more advanced customization,

we were going with custom web parts, which was basically built in .NET and that sort of thing.

But as the technology evolved in terms of, you know, the web development and

all the front end framework started coming in angular react and that sort of thing.

It was little bit different than what we traditionally used to do.

But then react because because people who would understand the HTML JavaScript very well.

And because react was built on top of, you know, JavaScript to make the developers

life little bit more easier than what we used to do with the JavaScript.

It would take some time, but eventually once you understand the importance of it,

you know, I mean, you will not go back like that.

I have never went back to JavaScript or anything since I started using React.

Yeah.

Yeah, for someone who is new in Microsoft 365 development,

what exactly is the SharePoint framework?

Yeah. So consider that we, because SharePoint has so much of out of the box

capabilities, which are available, right?

We can create pages list.

There are out of the box so many web parts, which are available.

But ideally, whenever an organization choose a product or choose a workflow

or an application or project to be developed, there are going to be the times when the

business requirement from the business is going to be, which is not going to fit into

the right out of the box available features, which are there, right?

So there would be always the time where we need to customize it.

And that is where SharePoint framework basically comes into the picture.

So there are different different options in which we can customize the SharePoint.

We can customize SharePoint with, you know, header and footer to put our custom content into

a SharePoint site, which is basically called as application customizer.

And then we have mainly our web parts, right, which basically allows us to customize and

create our custom user interface and deploy it into a SharePoint page, more or less like

out of the box web part, which we have.

And then now we also have the SPFX extensions, which are available through which we would

be able to add the command set into and out of the box SharePoint list or library view so

that you can add your custom command button on top of it and then perform some operations

if you want to make an API integration call and that sort of thing, right?

And very, very new feature within SPFX is SharePoint, SPFX co-pilot apps.

It means by using the same SharePoint framework, we would be able to create an app which would

be surfaced into Microsoft 365 co-pilot by using, you know, the same kind of UI component.

So rather than interacting with the agent or co-pilot with just, you know, text format,

if we would have built an SPFX co-pilot apps and deploy it by using the MCP server and

by using the tools, the co-pilot would be able to basically find the component and display

it into co-pilot in the agent which would become interactive in nature.

Awesome.

That's cool.

Is there, or, where would you say when people start with SPFX today, where can, can

developers find, find a good way to start?

So there are very good YouTube videos which are available, right, on SPFX on getting started

with SPFX. That would be one of the channel which I would suggest, you know, to people get

introduced to, if they wanted to get started with SPFX.

Another thing is they need to definitely learn the basic of react, okay, because without

having the react knowledge, it would become difficult for certain people to understand

how, you know, the components can be created and how the components would be called from

the different component, how you can create reusable components and all that sort of thing.

So yes, YouTube channel is the right place to go for.

There are lot and lots of videos which are available, which are free and then Microsoft

documentation is also a good example to get started with and then, you know, some starting

with some basic react understanding.

And what kind of business recounts are ideal kind of the ads for SPFX and what showed

absolutely not built with SPFX?

So I would say that if, I mean, there's always been and, you know, kind of argument wherein

do we want to customize SharePoint or not whenever a business requirement comes?

So I mean, as everybody would suggest, a good baseline would be that if you wanted to build

something in SharePoint, show something in SharePoint, does Microsoft provide it, right?

If you have an yes and no answer, if you have a yes and sir, do not build it, right?

If Microsoft doesn't provide it, but you are going to build it, but does it, is it solving

a bigger problem or just a smaller problem?

Are there any alternate ways for you to basically still use the SharePoint out of the box feature?

Not give that kind of experience which the user is expecting, but basically work out with

the user or the business user to make sure that they are okay with basically how they are

interacting with SharePoint.

If they agree, then just go without the box, don't do any customization, right?

But you know how business users are, right?

I mean, sometimes what they want, they want, they would not agree to something which is not

available or any alternate solution which they wanted to propose.

In that case, we do not have any choice and we should go with, you know, kind of SPFX.

Okay.

And how is it with main intents when I don't know, a SharePoint online 2.0 comes out or something?

Is there anything I have to look when I customize?

Yes, so just definitely because SharePoint framework gets quickly, you know, new new versions

which are available, right?

There might be, because it's a ProCode based approach, so there would be definitely at times

where, you know, if your SPFX solutions are so too old with the older version.

And if there are some methods, if there are some attributes or certain things which are

getting depreciated, then you need to upgrade it.

But otherwise, I have seen customers and organizations who have and SharePoint's, for Framework

solution being deployed, which is like, you know, six, seven years old, right?

And they are still on SPFX version 1.4, 1.5, 1.6, right?

Now, we are around, you know, I think 1.21 or 22 is the latest version.

But the solution is still working.

So until and unless it is necessary for you to upgrade, does your organizations, policies,

IT policies ask you to upgrade it?

If there are any security loopholes which are being fined in the packages which you are

using and all that sort of thing, then yeah, of course, it should be of, it has to be.

But now with AI and everything, it is very easily to upgrade it also.

You know, you just have to basically go to, you know, GitHub Co-Pilot or use Clod or,

you know, Codex and just say that, hey, this, I'm using this version, I wanted to just upgrade

it and it will just upgrade it basically for you.

And when I think a little bit about, we have on one time, we have the, if SPFX project

and we have also the power platform with power automate and power pages, when is SPFX the

right decision and when should I build a power platform?

Yeah, yeah, that's a really good question.

And again, you know, same discussion start happening whenever we choose to customize something

right?

So if you think about it, in a way, whenever we want to customize their share point list

or a library form, right, which is basically customizing that, then there is one option

wherein we can customize the form with power apps and then we can basically, you know,

customize the form and update the UI and everything according to the power apps controls

which are available and within the boundaries of what power is basically allows us to do,

right?

And then there is an SPFX thing which is basically will, in fact, now with SPFX form

customizer, you can still do the same thing but using a proc or approach, right?

When it comes to power apps, because power apps has its own control, its own way of doing

things, you have limitations there, right?

In terms of how you are going to build the user interface, I know there are so many,

you know, great people around who has built a power apps which you doesn't feel like it's

a power apps, you know, they were able to basically make it more than that.

But for a normal developer, sometimes it becomes difficult to basically get the required

user interface and control and everything within power apps.

Just giving one example, like for example, in the power apps, if you wanted to show data

combined from two different data sources, two different share point list or two different

data was tables, right? You can only associate one gallery with one data source.

You cannot do it with multiple, in, by associating with multiple, you know, gallery or data

source, right?

So in this case, what you would have to do is you would have to first get the data, put

it into collection and combine the data and then put it here, right?

Same if we go with SPFX because you are doing it with, or an API call, you can merge the

data, combining the data in the JSON format is far, far easier than, you know, what we do

with the power apps and everything. So there is one difference there. So I would say if

you need a very, very good user interface, you can basically go with SPFX and you can create

a full-fledged application there, right? If you do with the power apps, if you have simple

requirements in terms of, you know, showing some fields based on certain conditions and

putting some business, simple business was around it, I would say go with the power apps,

right?

And then another thought would be that initially the time to develop an SPFX thing was higher,

right? When I say higher, it was far more than a low-code platform and then people were

choosing a low-code platform to customize something. But now it has definitely changed because

now with AI, in fact, building something, AI with SPFX is far, far easier than when you

are doing it with power apps. I mean, creating something in power apps with the AI and the

pop-up, highlight and load, it gives us certain users to certain time, but not as, you know,

we get with the SPFX. I mean with SPFX, you can do wonder with, you know, all this GitHub

pop-up, highlight and load and all that sort of thing. So it also depends on as you rightly

say it depends on how much time do you have? Do you want to maintain the code or not? Good

thing about power apps is that you are not maintaining the code. You do not need a skill

set with react or SPFX. Any citizen developer can go there, look at the code and see what

has been done. But somebody who doesn't understand SPFX, they would not know until and unless

they understand what the SPFX is about and all that short.

Yeah, let's a little bit look inside and model SPFX projects. So there, I think, why technology

is that actually so we have TypeScript, JavaScript, through-ends, UI, PNP, JLS, PNP, React

controls. Let us start with TypeScript. What TypeScript knowledge is essential for project?

So in a way, TypeScript knowledge wouldn't be required that much, right? Because ideally,

what TypeScript is, TypeScript is a way for us to, it's an advanced version of JavaScript.

In JavaScript, there was no strong type or interface which was available and hence Microsoft

came up with a TypeScript saying that you can, if you are doing client-side development also,

you can still kind of create an interface or class or models which would be strongly

interface. You can create strongly typed classes, models and attributes so that if you are

writing the code, it doesn't have any leak around what code has been written, what attribute

needs to be written, what should be the type? If the date type is actually been assigned,

the date type or not and we get all type of compile type errors, okay? So TypeScript in

a way is just about, you know, it's more or less, she sharp on this. So anybody who understands

she sharp somebody who understands Java, anybody can just get it, it's just this thing only.

Awesome. And what's the role of through-end UI?

Fluent EI is basically an UI framework for Microsoft to basically build the user interface, right?

So if you think about it that if you are doing a customization in SharePoint, you need something

which is not available out of the box but you want the user to still feel like they are

in SharePoint itself. So Fluent EI is that library which basically gives you all the user interface

controls which merely works similar to what SharePoint Control looks like. So you have

buttons, you have drop-downs, you have checkboxes, you have gallery, all sort of things. That is

something which is a front-end library which is available. And then we have also a PMP,

JS, how to sit within. Yeah, right. So because whenever we are building an SPFX solution,

right, more or less we wanted to get data from SharePoint, we want to get data from graph API,

one drive, it can be anything, right? So what has happened was the way the PMP react controls kind

of evolve, the same way PMP, JS kind of evolved because people were following the same pattern.

Everybody like me or another developer who were building it, everybody needs similar kind

of service class to interact with your SharePoint, to interact with your graph API, to interact with

your any kind of you know, Microsoft 365 products which are available. So that was kind of becoming

a pattern. Now we were repeating the same kind of code, right, you know, making a REST API call,

takes file line of code. That code was been repeatedly written by everybody by in the same code,

there is itself. And that is where you know, PMP, JS comes into picture. What it does, it gives us the

wrapper library on top of it which takes care of authentication on its own, which takes care of

the request object response and everything. Plus it is giving us an easy way to write the code,

rather than writing 5, 6 line of codes, I can just write one line of code and get data from SharePoint,

update data SharePoint into back and that sort of thing. And when I'm saying this, I'm just saying

a very simpler and basic way of understanding PMP, it is so much more than that. I mean you would not

imagine writing an SPFX code where you are directly making an HTTP request call, unless you are

doing a proof of concept or basic, you know, the part, you should always go with PMP, JS basically.

And then the last thing I see is the PMP react controls.

Now what's, I mean the way PMP, JS, I gave the example, right, that people started writing,

similar kind of code to get data from SharePoint and Graph API and everything. Same way,

there were controls which has to be created, right? For example, you wanted to create a drop-down

control, which is going to show you an item from a particular list, okay? Then what you need to do is

you need to use fluent UI, you need to create the drop-down, you need to make an API call,

bind the data with the drop-down and that sort of thing. Now because of that, what has happened was

that in a way people were writing similar kind of code again and similar kind of controls were

been created every time. So what community came up with, right? And I think it was in 2018 or something,

right? SPFX came in 2017, the react controls kind of came in 2018 somewhere, you know, at the end

of the year or something. And thanks to community, you know, like we now have so many controls which

are available, which can be easily used to give some example, like for example, we wanted to create a

folder thicker control. It means we want to allow user to basically select a folder value of building

an SPFX solution, right? So if I have to build it and I have to build it in three different places,

I'm kind of repeating the same kind of code. So rather than that, there are controls available,

which are SharePoint-Aware controls, which are Microsoft 365-Aware controls. So rather than me

writing the code again and again, the control has to be configured in such a way that I just say

that hey, this control needs to point it to this library automatically makes the API call gets the

data, bind the control and gives us all the customization options which are available.

Another is File Picker. If you wanted to give a love user to select a file, upload a file into,

you know, your SharePoint, okay? This kind of user interface. Then there is filter bar, icon bar,

I mean, there are lots of controls which are available and through which you would be, it is

going to be making your life easier to develop an SPFX solution because all these controls are

readily available, tested, verified and available in the community for anyone to use without,

you know, rebuilding the thing. So rebuilding is, you know, main point of PN-Payer controls.

Awesome. And how do you decide between Microsoft components, PNP commands and building your own?

Again, same concept. If Microsoft provides, yes, use that. Thus fluent UI provides that, yes, use that,

but are you going to use, what is your use case, right? If you are creating a drop-down and

that same drop-down is going to be reused after all different different section of your solution

and what you want to do is you wanted to display for example, employee name or a people picker,

right? That means you want to allow user to choose the name of the people within your organization,

right? What you will do, you will have to, if you are just using fluent UI, there is a people

control available, but behind this thing, you need to make the API call first. You need to get the

list of the user, whenever user type searching my name like SIDAR, right? And they will say, SID,

then I need to make the API call to get, okay, give me all the names starting from SID and then

again render it back into this thing, but the people picker control is already available in React,

VPN, TREA, Clivary, right? So, why don't we use it? Behind this, it is still using fluent only,

behind this and it is still making the same API call which I was supposed to make, right?

And then you do it. So, if you think the philosophy I generally take is, when we are building SPFx

solutions, right? Okay, what is your need? Does that need being satisfied from PNP React controls?

Yes, use it. If not, then only go with the custom component, then only go with your custom

component or UI which is required. But if it is already available, always go for React controls,

which is there. Yeah, that's a little bit deeper dive into the PNP React control. So, when I

have here at the expert, so if you could choose for only 5 PNP React controls for SPFx development to

learn, which would you choose? Five controls. Okay, people picker number one because it's definitely

something, you know, where everybody is going to use. Second, I would say, taxonomy picker,

right? You wanted to build a solution wherein you wanted to get a love user to select the taxonomy

to associate some metadata with particular list or live, whatever. That is second one.

Third, I would say list view. Why? Because more or less when you are going to build a solution with SPFx,

you wanted to get data from SharePoint and display to in the similar kind of table view,

what we have with out of the box. It is going to be very much easier to use.

File picker is also very important because the file picker control, which is available in React,

if you see the user interface, it basically merely depicts exactly the same

picker control which SharePoint provides us when you are going to say attach a file, right?

Where do we get in Teams also? Like on the left hand side, you see all the recent SharePoint sites

or recent files. If you want to select a file, you select a file. If you wanted to upload a custom

document, you get that kind of options also available within there. So file picker would be the one.

Another is persona. Persona control is basically you wanted to display somebody's name,

like who is there in Microsoft 365 in your organization tenant. It gives you the same experience,

what you have it in your all SharePoint. So you can put a name, you hover over it, it will open the

pop-up where it will display name and photo and email and whatnot. And then there are tabs and

everything also available. So I think a person, Li-persona is also one of the good control which you

can use. How many I said? People picker, taxonomy, list view, file picker, Li-persona. I think,

yeah, top five should be there.

When we look, let's build something conceptually. Imagine a customer ask us for

sophisticated, prep management experience in such a app, where do you begin?

What does, sorry, I didn't know what customer ask.

For a sophisticated, project management experience in such a app.

Project management experience, right?

Yeah. So see, project management experience in the sense, like we can use SharePoint list,

right, for creating the required database tables to store the project related information,

to store client related information, to store the resources associated with your project,

to store the task associated with your project, you know, that's sort of thing.

All this experience, if you think about it, yes, SharePoint would be there available for us to

basically store the data in SharePoint, list, and Li-person everything. But now when you're talking

about an experience where you wanted to give it and use a single place wherein they would be able

to see a dashboard, how many projects are there in the system, how many projects are in progress,

how many projects are at high risk, how many projects are at low risk, that's sort of data,

right? So and for each project, when I click on one project, I wanted to see what are the resources

associated with that project. Now, we would not be able to store all this information into a

single list. So if you use SharePoint out of the books, you will not be able to go and give the

user an experience that you click on a project, now you're seeing all the resources associated with,

if you click on a project, now you're seeing all the tasks associated with that project, right?

So in this case, if you think about it, what we will build, we will build a project management

dashboard, a PM or dashboard, which is getting data from SharePoint, a dashboard is going to see,

give you an high executive level view of all the projects which are there, how many projects are

completed, how many projects are at risk, high level and everything. In fact, if you want, you can put

the charts also, right? Then because there are all the chart library controls which are available,

so you can put the charts and everything also on top of it. You can show some recent updates or

recent activities related to certain projects, certain tasks been created and that sort of thing.

So this is like, you know, hold dashboard experience. And then on the left hand side or on the top,

you can give a navigation that all projects. So where you go, there you see list of all the projects,

which are available. You would be able to give them crude operations on the project. So use a

click on it, they would be able to update the metadata of that particular project. They can change

that you date, status and whatnot. Plus you can control it, right? You can security control it,

raw. It means that based on your business requirement, you want certain fields only to be

editable to certain set of users. You can program it in your code that okay, this five fields only

would be editable when the user logged in user is a project manager. If it is just a team member,

then they should not be able to update the project name or project details or whatnot, right?

They should only be able to access the task and everything. So that can also be program.

You can have a task view, sorry, go ahead.

So if you can have a task view there, you know, like a planner, you can have drag and drop, you can

change the status of the task, you can create your task, assign task. If you want to put some

billing information or you know, some hours associated with task, that sort of thing, you can do it.

If you want to use behind the scene planner, you can do that also, like not using SharePoint

list, but you getting data from the planner, plan and task and all sort of thing, but displaying it

into a single unified user experience which you can get. And is there also

cases when you say I put my data into data rules or SQL or that you ever use SharePoint list?

No, you can, right? Because SharePoint is going to give you what? SharePoint is going to give you

a way for user to basically come to a place which is familiar to them because they are already

using SharePoint. But now you wanted to build something which is going to get data from outside of

your SharePoint system. So, if you wanted to do it, you can basically make API calls to data

rules, right? Because the SharePoint framework solution is associated with and as your

intra-ID app registration, whatever permissions would be required for your solution to be access to

data to be access within Microsoft 365 ecosystem. You can just put it in your configuration file.

Once you deploy the solution, your SharePoint admin would be able to come, they would be able to

approve that, okay, this solution is accepted to basically make this API call and get this data.

And then you can make the calls and bring data from the data rules and everything, right?

In fact, I had recently submitted one dashboard, okay, which basically shows you,

you would know power automate approvals which we do, right? Now anybody who user who wanted to see

what are the approvals which are available, they would go to flow.microsoft.com and see in the

approval URL or they would use Microsoft Teams approval app, they would be able to see all the

approvals which are there, right? There was one ask from a customer that, hey, I don't want to go

to flow, right? It's confusing for the user. For user, SharePoint is the place where they wanted to go

because they are very much familiar, okay? But there is no web part out of the box web part available.

So, I build a web part for them to basically display the approvals in the SharePoint as an SPFX

web part plus give them ability to approve and reject also from there, okay? And that I had

contributed in the community also, but yeah, so this is one a good example, right? You can get data

from your data was three balls also. You also talked about SQL, right? So, if your data is in your

SQL, ideally, when we are running a client side application, right? We cannot directly make API

calls to any back and database, right? Like SQL or anything, unless there is an API which is available.

So, if there is a database in SQL, it is same for every modern application which are

been built, right? Nowadays, nobody is directly interacting, the front has never interacting with

the database or anything. There would be always an API middle layer which is created. So, you build an

API, the API is going to talk to your SQL, your SPFX is going to talk to your middle layer,

which is your API and then building the user interface. So, in that case also, you know, SPFX

definitely box. Awesome. I think another topic, a lot of developers speak, it's the Microsoft Graph API,

when can the Graph API to SPFX development? Yeah. So, as we say, right? I mean, you, the last question

also, you ask is that if you are building an SPFX solution, it is not just about SharePoint.

It means that your data might reside outside of SharePoint also. You wanted to get data from outside

of the system like data was like SQL and third and big graph. Now, for example, you are building an

SPFX solution, which is, which wanted to get data and show data from your one drive file, right?

It means that you wanted to use us one drive, it goes to users one drive and then get data from

users one drive and display it there. As Graph API is basically an unified way for us to make API calls

to Microsoft 365 ecosystem across all the products which are available. Same Graph API can be

integrated into your SPFX. So, if you wanted to get data from your one drive, if you want to get data

from planner, if you want to get data from your emails like Outlook, right? You wanted to get the data

for the user, you want to get your meetings, for example, you want to get your meeting recordings,

you know, that sort of thing. Anything which is possible in the Graph API, which you wanted to get

data from plus you wanted to update also, that is possible within SPFX. So, you basically use the

graph library, which is available, the graph client factory library, which is available,

that is a native way of accessing the graph API in the SPFX. But if not, PNPJS also has the same

thing. So, I would say go with PNPJS, it has easier way to basically do it.

That's, is there anything the SharePoint APIs, APIs, cannot provide what Graph API,

provide or when issues what? Yeah, so, as I said, you know, the choice of using SharePoint

REST API versus Graph API lies in that whether you are doing certain operation in SharePoint or

outside of SharePoint, SharePoint REST API are also so much of having so much of operations, which

are available, right? I mean, with using SharePoint REST API, you can create list also, you can create

libraries also, right? You can set the site properties, you can set tenant level properties,

there are so vast APIs which are available. But the choice between SharePoint, S,

API and Graph API, one would be when you are doing certain things in SPFX, which is outside of

SharePoint, like the example which I gave. Second, I mean, another thing is previously we used to

have a send email API available in SharePoint, so which you can send an email. Now Microsoft is

basically depreciating it. It means you now you cannot send an email from SharePoint REST API,

then you have to rely on the Graph API, right? Basically, so that's the, you know, ideal distinction

that, okay, if something is available in SharePoint REST API to do certain operation, which is available

and you are doing it with SharePoint, go with SharePoint. If not, obviously you have to go with Graph API

only. Yeah, and how do permissions work when SPFX solutions call Microsoft Graph?

Yes, so good thing about SharePoint framework is that it basically respect the same

delegated permission of current logged in user, right? So when you are building an SPFX

solution based on what operation you are doing, right? There is a manifest file which is available

in which you have to actually configure the permissions, okay? And once the solution gets deployed,

the SharePoint admin has to approve that solution, okay? In the SharePoint admin center that

there is a tab called API access. Now you go there, you see that as soon as the solution is deployed

and the permissions are not there, you would see something called as, you know, pending API

approvals. Admin has to choose and give the approval. Once that approval is only given, then only your

code would be able to make the actual API calls, whatever they are asking, right? Second thing is,

by default an SPFX solution always works with the delegated permission. It means that no matter what,

though your solution has permission to do certain operations, but if you as a user who is browsing a

SharePoint page, who where the SPFX code is going to run, it is always going to run from your

consent from your delegated permission, from with your access token, with your identity token.

So if your code is trying to access the data on which you do not have permission, the code will not run.

For example, your code, you got an access to a page where an SPFX solution is deployed,

but that SPFX solution is getting data from a different SharePoint list from a different SharePoint site,

and on which you do not have permission, right? In that case, the data will not work. So by default,

it is a security-treamed one. So it is very much secure and you won't be able to make an API calls

on which you do not have access to. At plus, you will be only able to get the data

within SharePoint lists itself, right? If you have item-level permissions, if you have document-level

permissions, you will only get an able to access the data, which is available for you, which you have

access to. There is no application-level permission is possible. If you need to do that,

then you don't need to go with the API route, which I discussed previously. They talk about

a bill you're on API. The API is connecting with these all data source with an application permissions,

and the front-end is calling your application API basically. Yeah, cool, cool, interesting.

Also, the second question, but yeah, you have explained it, but the difference is between

delegated and application permissions. Yeah, right. So I will let's go a little bit deeper into

the security topic. What are the biggest security mistakes you see in custom Microsoft 65 solutions?

So when you say big security means as a developer, right? I mean, as a developer, people do.

Correct? Yeah, yeah. So yes, I mean as a developer, right, what we generally use to do, we basically use

to get the higher permission than it is required, which is a very, very big mistake any developer,

you know, who doesn't understand the permission, well, do that. Let me give you an example.

So for example, your part is supposed to basically get data from a share point list, right? And

it's a read-only operation. You do not, the business requirement doesn't allow you to or want you to

update anything from your SPFX solution. Now, what you did is you did it, right? But what you did is

the permission which you have asked into your solution is read, right? Rather than just read, okay?

So when nothing is going to be harmed, why? Because your code is not doing it, but you,

you as a developer has given the solution and extra permission, which is not required.

How do you know the next developer who is going to come is going to do something,

you know, and write a code which mistakenly is going to update something which was not required,

right? So this is the common mistake which people do that they always start with the higher

permission. But rather the recommendation is always start with the lower permission.

First, only get the permission which is minimal permission which you would require and do not get

the higher permission which would be required, right? Second thing is while they are building the

solution, they generally do not consider the actual users permission. So what, like I have seen

and I mean, solutions were in it just, you know, blindly assume that when I am developing it,

I am having access to this list, this library, this site, the user is also going to help.

So what they do is they develop it, they test it from their side and they're saying yes,

it is working fine. But now when you are exposing it to the user, they have not taken care of the

actual permission of giving that user permission to the list or library on which they have.

And then user will say that, okay, you are seeing that is fine, but you are seeing something different.

I'm not seeing it. I'm just seeing a blank screen or I'm not seeing the required data which I want

to see. So they have considered the permission in the SPFX code, but overall as a solution

designer, they have not given the right permission to the right component within SharePoint,

within DataWars and that sort of thing. And that is, you know, a common mistake, yeah?

And I work more with Fabric. So I have a lot, I use often as a key world. Is it also a topic for

SharePoint development? And no, because SharePoint is a client side development tool, right? Key world

basically will not work here. Why? Because if you, whatever code you are going to deploy

and the user is going to browse your code from the browser, right? Anything which you are going to

put, right? Within your code, in a way is going to be converted into JavaScript and then rendered

into the browser. So never, never, ever put any key world or secret information in your

SPFX code. If you want to do it, the right way to do it is via API, right? So your API is running

behind the scene, behind the server, hosted somewhere, where it is accessing the Azure key world.

Getting the required secret key, all the permission and your front end is only able to

make call to the API is basically. And do you try the and the PubeView

play a place or role in SPFX development? InterID does not the PIP. The intri-dy because as I said,

by default, whenever in a particular tenant, if you are deploying the first SPFX solution,

what it does is it provisions and app registration or intri-id app registration into your tenant.

It is called as SharePoint Framework Extensibility, something I don't remember the exact name,

but that intri-id is by default created there. And any further solution which you are going to

deploy basically use the same intri-id. And how can we, I think,

can we have a process for security, I think, like, yeah, and how I ask it.

Should organizations have a formal security review for a custom SPFX page or

all every time secure? No, no, it has to. The reason being because SPFX framework is

supported or developed using all the modern open source tooling chain. So, which MPM package you

are using? Your developer is using whether that package is something which is a stable package,

whether that package which is available is from a trusted developer because it is an open source

tool. So whether it is by a trusted developer or not, if it is by a trusted developer, then you

should use it. Some organization also restrict that you cannot publicly use any MPM package which

is available because SharePoint Framework is based on that. You will be able to use any package

which is available in the node.js, you know, like the whole library. MPM package library, sorry.

So as an organization governance tool whenever an SPFX solution is been deployed,

it has to be checked through various processes in terms of security, vulnerability and all of that.

Good thing is that what I have personally seen is that when you are building a node.js

based application, what you are trying to build a package or trying to run the package in any

node.js based thing which SPFX also use, it will give you some warnings when you are compiling it.

It will say that hey, you are using an MPM package which is so outdated. If you are using an MPM package

which has somebody has flag a security vulnerability into this package. So the good thing is if you

do not ignore the errors and you focus on the warnings. What does warning says is the warning

serious is the warning is supposed to be not neglected, but you know, we need to do something about it

that is going to basically help you. But because it is a pro code tool, there are tools also which are

available which is going to do you a code review assessment for you within your SPFX and identify

all the security vulnerability on this all these packages which you can basically gives you the

report around that and once you basically get the report, it would be up to you as a developer for

you to kind of you know fix it depending on how serious the security vulnerability is.

Yeah, I think security is a good keyword. I have worked on a big company and they have also an SPFX

solution built in SharePoint for security trainings and this was so so amazing slow that you have

to get 50 minutes before the course started. You have to click lock into the course.

Okay. So then slow. Where did you start when people give the feedback

just this SPFX is then they can restart? Okay. Yeah. What I would do, right? If people, I mean,

I had solved that similar kind of problem as you say that somebody developed it and said it is slow.

We wanted to identify why it is slow, right? Where I would start is I would start

browse the page in the browser while I am browsing the page, I will open the network tab, right?

And I will see in the network tab whenever the user is refreshing the page, how many APA calls are

being made? If for example, there are you know 10 calls which we identified, okay, which are being made.

Is that 10 calls necessary or not? Why? Because sometimes what the developer does, he just feels,

you know that whatever data I wanted to get, I will get it on the page load itself while the

reaccomponent is getting loaded itself, okay. That might not be necessary, right? There might be

three API calls which you would need only when the user is doing some operation on the screen.

So first identify what are the unnecessary API calls. Second thing is when you are seeing the

network tab, you might sometimes I have seen that what people do is by mistake people would have

made an API call in the loop itself, right? So for example, you have a parent and a child

list or a data or table relationship which you have. So what you want to do is you wanted to basically

get all the items from your parent list, but for each parent list item, you also want to get data

from the child list to bring some attribute or columns in it, right? What people would have done

rather than calling both the data and making two API calls, people what they would have done,

they would have make the first API call, get data from the parent, may they for loop each look

for each item in the parent, they would be calling a child list, okay. So for example,

wondering, you know like if there are 50 items which are there in the parent list,

what you are doing is you are making one API call to your parent items, then for each 50 items,

you are making a child API call. So there are 51 API calls which are going and then you are waiting

because all the 51 items has to be processed, then you are combining the data and then you are

displaying it to the user, right? Rather than that, you have to optimize your code, get the data

from the parent, get the data from the child as in required and then do the operation at the

client side, whatever combination you have to do, the mappings you have to do because you said you

are working with fabric, right? Like that is what we do with the DAX formulas and everything,

that okay, how the data should be associated, club together and then you point it to a particular

chart or dashboard rather than keeping to both separately, right? So exactly the same way,

you know, you should do. Network tab is your best friend, second thing what you want to do is

nowadays there are also extensions available in the browser which will allow you to also

debug your react components, right? So there might be certain things wherein within the loop itself,

there might be so much of, so many times you are actually rendering the react control, you know,

one by one because react is a state management control. It means what you are doing is you are

rendering a react control and then changing the state and as soon as you are changing the state,

you would have written a code to make another API call or it would go into, you know, some kind of

loop until a particular condition is met and that is where your screen will freeze and user is going to

see. So that is also something important that go to the react component extension library, see

that how your react components are basically kind of behaving. And the topic is matching and catching.

The catching? Yes, yes, yes, yes, always, always, right? Good, good, that you brought up, I almost forgot it,

right? Yes, what you can do is once you identify this kind of issues, right? I mean, I said how to

identify, I never said how to fix it. So once you identify this kind of issues, then you know that

based on your business logic on how you wanted to make these calls, you can basically batch your API

calls. So rather than, you know, sending one by one, you can create a single request object and

do the batch operations and the share point would respond based on that, okay? If it is a patch,

for example, you are updating data into five different lists, okay? Prepare everything together

and make one batch API call so that all the five operations which we are doing are going to be

taking care in the one operation, etc, right? At least from the client side, behind the scene,

the batch operation still makes all the different calls. But we are not doing it at the client side,

that is happening at the server side because share point support the batching operations and all that

sort of thing. Yeah, we, we, as the world, I think a lot of developers of, yeah, heavily focused on

fine genality. And I think the other topic is, it's for the users, it's the accessibility.

Where do you hear the fluent UI and the PNP, React controls help?

So, I mean, there are certain controls, at least in the fluent UI, I know, which are basically having

some attributes and properties which are available to make it, you know, accessible across, you know,

for the, like considering all the accessibility point of view, right? So, depending on if you wanted to

do it, what it will do is there are properties or attributes available, which you can set so that,

you know, your control is basically rendered and it's basically supported with all, you know,

all kind of accessibility mechanism and all of that. For PNP, React control, I am to be very transparent,

I am not sure whether that is there or not. But I am assuming it will be the reason being behind

the scene, most of the React controls are still using the fluent UI, only to render it. So, eventually,

what the React controls are doing, they are a wrapper around your API calls, you know, bridge between

your API calls and your fluent controls, right? Eventually, it is the fluent control only which gets

displayed. So, I think indirectly that also should be supported, that is what I know. But that is a

good point which you brought in, which I would definitely go back and, you know, look and see that,

okay, how we can make, you know, accessibility also supported when we are building an SPFx solution.

And when I have my app ready, all is fine, how get my components into the app catalog?

Yes. So, as an SPFx solution can have multiple web parts, multiple extensions, you know,

you can build a whole solution around it, right? As and when you are ready for deploying, right,

what you do is there are commands available, you know, previously it used to be called, now,

which is heft, which is going to package the solution. So, when you package the solution,

what it will give you, it will give you an SPPKG file, okay, the extension of the packages,

SP.PKG file, what you do, you copy the file, right, and you go to your SharePoint admin center,

and there is an app catalog. Now, this app catalog is a tenant-level app catalog, where you are actually

deploying the package, okay. So, this is where also, we have to understand that deploying is not

installing, okay. It is just deploying, deploying means you are making it available for the people to

install it into the targeted SharePoint site. So, you deploy your package into a tenant-level app

catalog. I will talk about SharePoint site collection level app catalog also later, but, okay,

the, ideally you deploy it into the tenant-level app catalog. If your

solution needs some extra permissions, you go to admin centers, you approve the permission as

a SharePoint admin, then you go to target SharePoint site, and then you basically install it, right.

Now, what does install means? It means the package you have deployed, and you know, SharePoint is more

than just document management system, right. It can be used for so many different ways,

and organization can have thousand sites. You don't want to deploy your solution into thousand sites

until and unless it is necessary. You only want to deploy it into one site, two site, or wherever it

is, right. So, what you do is you go to a SharePoint site, and then you install it as an app. And once

you install it as an app, that is when all the vipads and components would be available for you to

add it into your SharePoint page. That is where your custom vipads started showing up in this SharePoint

page for their targeted site. So, this is how, you know, the deployment work. I talked about

tenant-level app catalog, but there are organizations who would say that I don't want to deploy at all

at my tenant-level, because I am building an, for example, an intranet solution, or I am just

building an contact management solution. I want my solution to only deploy it into the targeted

SharePoint site, nowhere else, right. What you can do is you can enable a site collection-level app

catalog. There is a power-sale script, which is available. Once you do it, it creates a library

within your SharePoint site. And then rather than deploying it into a tenant-level app catalog,

you deploy it into a site collection-level app catalog. Still, you install it, right, because

now again, you have just deployed it in your site collection. Still, you install it,

and then you go ahead and, you know, use it in your web-part and everything.

That's, this is amazing. So, I think I have so much more questions when we are running out of time.

So, yeah, you're in independent consulting. Who looks your ideal client?

So, yeah, I mean, my LinkedIn definitely says independent consultant, which I am still. So,

what I do is I am also a founder of company called Binery Roots. So, I have team of about 25 people,

you know, back in offshore in India. And we provide services on Microsoft 365,

Power Platform, SharePoint, you know, Azure, Copylastory, and everything. You say about clients,

so I have client in US, I have client in Australia, I have client in UAE, I have client in Israel,

and also I have also client in Europe, you know, like couple of friends which are there in Europe also.

But yeah, this is, you know, like different client base, which we have, which we support.

And we, we kind of do the similar kind of exercise, which we do with, you know, any Microsoft 365

based ecosystem.

And a lot of people actually now speaking about

I think Copylastory was yesterday, actually, I'll speak about agents. What role do agents feel

plays in SPF exactly?

Yes. So, as I said, right, like Microsoft recently with the last release, they have released

for the public preview the SharePoint Copylast apps. Okay. So, it still says SharePoint Copylast apps,

and they are saying that they might re-brand it to something else as always. But Copylast apps is

basically allowing us to build an user interface, which can be embedded into agents. Now, that agent

can be a copylate agent. In fact, they can be a copylate, that would be only the agent. I mean,

the copylate user interface one which you are going to do. So, what you are doing is now the same

SharePoint framework is allowing you to actually customize your copylate user interface. So,

rather than showing the responses just in the text format, in the markdown language and what not,

you are actually building a component, which would be rendered in the Microsoft 365 Copylate,

where user will ask something, the component would be rendered, but then now they can interact

on it, right. They don't have to say, okay, I want to submit it, rather than that, they are going to

get the form, they are going to fill in the form, and then they are going to kind of submit it.

The way I relate it to is basically an advanced version of adaptive card, right. With adaptive card,

what we get is we get few controls, but we don't know, get a fully immersive or UI experience,

or customization experience, right. But with SPFX copylate apps, we do look at that. So,

that is what the role is going to be of SPFX into the agent development, and that sort of thing.

Cool. Yeah, we are running a little bit off time. I have every session of rapid fry around. I give

a short question, you give me a short, start with the local or pro code. I would say pro code.

Most underrated SPFX feature.

Underrated SPFX feature. I would say extensions. Yeah. And if such a little bit calls you today,

I say, is that you get all the money and resources you need. What SPFX feature ability build?

What I would build, okay. Yeah, I would build some kind of power automate workflow, automation kind of

capability within SPFX itself so that we do not rely on the power automate if you want to build it.

Is there any myth you will bust about SPFX?

Yeah, now I mean at this point in time, yes, I can, that SPFX is faster to develop than power apps.

Some people are still under the myth that it's the other way around, but now with the

generative AI and AI and everything, that is the myth SPFX is faster than developing power apps.

Coffee tea or energy thing during development.

What's the one skill you develop as under estimate?

What is the one skill? Sorry, I didn't know. What is the one skill?

Usually, but I pass under estimate. I would say react. I don't know. I mean people generally don't

feel it, but I would say that yeah, okay. And who should I invite next and what questions should I ask?

I would say you can invite Nandip, okay, Nandip, I'll give you the reference and

what questions you can ask. You can ask questions about Azure AI Foundry. I mean he is exploring it

and he is very good at it. So that would be my choice.

So I would say thank you for this amazing session and joining me today.

And yeah, I think one of the biggest lessons from this conversion is that professional

development doesn't mean building everything yourself. There's a lot of great stuff. The Microsoft

365 ecosystem already gives developer enormous foundations through SharePoint framework,

ReactRef, API, Power Platform, PMP, you know, SPMP, React controls, Flan,

Azure and yeah, also the community. The real skill for me is knowing how combine those

building blocks into a solution that are security, maintainable, performant and actual exhaust,

a business problem. And yeah, I think yeah, there's a lot of new AI, yeah,

brings a lot of new, better ideas how we can make things better faster and so on. And yeah,

for everyone, you find all the information of the show notes on the MC35 and podcast. And yeah,

so I say thank you again for being part of the show. Thank you for inviting. Thank you. It was nice

talking to you.

[outro music]