The Good, Bad & the Ugly: Using Angular Elements with the SharePoint Framework

In this series, I showed you how to build custom elements, a native web technology supported natively by most browsers (except you Edge & IE…) and presented two options for how you can go about it. One option involves using one big project with the SharePoint Framework & Angular in it while the other utilizes two projects to mitigate the downsides of the one-project approach.

So, you can now use Angular in SharePoint Framework projects and this is made possible by Angular Elements which was introduced in Angular v6 back in May 2017.

Sweet! We’ve got the “can you do it” question answered!

But, should you do it? There are always tradeoffs when picking a web framework for your next project and using one with the SharePoint Framework is no different. Let’s take a step back and look at the whole picture. Only then can you decide if it makes sense for you.

The Good

The clear implication of this is that those of you who have existing Angular experience can transfer that straight over to the SharePoint Framework. You can leverage everything you’ve learned in the past with Angular.

If you elect to go with the two-project option I wrote about in part 3 of this series, all the skills in working with the Angular CLI in your SPFx projects can also be leveraged.

There’s something to be said for not having to learn a new web framework.

The Bad

To me, the downside to going with this approach is the fact you don’t have a native set of UI controls to use in your project that looks and feels like Office 365. The Office UI Fabric team has created reusable controls that you can use in your projects. However, these were built using React which means you can’t easily use them within your Angular project.

If you built your SPFx project using React, you could leverage easily in your React-based SPFx components.

While you could import them into your Angular app and leverage them there, you’re now mixing two frameworks and that is going to get messy quick.

So… if you go with the Angular approach, you are left without a UI control suite that looks and feels like Office 365. That doesn’t mean you couldn’t use something like Angular Material, but it just won’t look exactly like Office 365. Is that important to you or your customer? Only you can decide on that one.

The Ugly

Now for the big downside. How do you use the SPFx APIs in your Angular-based project? What kind of APIs am I talking about? Things like the SPFx context object, the page context, the SPHttpClient, the MSGraphClient, the AADHttpClient and others.

Can you use them? If you elect to go with the one-project approach that I wrote about in part 2 of this series, you can and do it pretty easily. All the dependencies are there, and loaded in the SharePoint context.

But what about the two project approach? You can’t easily just add one of those objects as an input property on your custom element created using Angular Elements. Why not? Because in your Angular CLI project, you have no SharePoint context so when you build, you’ll be missing all that stuff & will likely get loads of errors. Could you make it work? Sure… get all the necessary packages and it should work, but it’s messy.

This point is a bit moot to me anyway because I don’t think it’s a good idea to throw these big SPFx objects into components anyway be they Angular Elements based custom elements or React components. Why?

For the simple reason that it makes testing your components a major pain… a royal PITA if you ask me. These things require so much stuff that testing just your code becomes overly complicated as you need to create mocks or fakes for each one you’re using so you don’t get some tangled mess in your project.

Brass Tax: Should You Use Angular in SPFx Projects?

I’ve addressed this in previous posts when I’ve written about Angular & Angular Elements and how they related to the SharePoint Framework. However, now that we have some good implementation options and with the Ivy rendering engine coming in another month or so in Angular v7, it’s time to revisit it.

Only you can make that decision. But thankfully, you are now armed with all the information you need to make the best decision for you, your organization and your customers.

However, I’ll share with you what I tell people when they ask me: “Should I use Angular or React? with the SharePoint Framework?”

• If you have no web framework experience, learn React. It works natively and has the best support with freebies from Microsoft (IE: Office UI Fabric “Fabric React” components), plus its widely popular outside of the SharePoint Framework.
• If you have experience with both frameworks, use React. Same reasons as the last one.
• If you have no React experience, but you have Angular experience. Try the Angular approach I pitch in this series… try to do a few proof of concept web parts. Try to get data from a SharePoint list or the Microsoft Graph. Maybe try using some of the Angular Material controls. If it works for you, then go for it!

“That’s Great, But What Do YOU Use AC?”

When I need a component, I switched to React. There… I said it.

I used to be an Angular guy, and I still like the framework. Those guys are doing some great work with it and Angular Elements is exactly where Angular needed to go to be competitive and offer a “component” story like Vue.JS and React.

But I find React to be much simpler and have less ceremony than Angular. Getting started is simple, there’s no heavy bootstrapping needed, there is no need for a CLI to simplify all the getting started, configuration, testing and debugging complexity that Angular has.

Unlike Angular, I feel like I’m much closer to working with pure TypeScript/JavaScript classes than I am with Angular. That was a big pitch from the Angular team when they introduced Angular 2, but the bootstrapping and Angular specific decorators still has a learning curve and there are still some concepts you have to grok that you don’t have in React.

I put off learning React for a while because I didn’t want to go through that Angular learning curve again. But when I finally bit the bullet, I was surprised at how easy it really was.

So for me, I default to React, but I’d still consider using Angular if I was building a big and robust web application as opposed to the components we build in SharePoint Framework projects.