Bo is a Principal Consultant for ThreeWill. He has 18 years of full lifecycle software development experience.
As I started to write this blog I used the Google box to see if there were other posts like it out there and as it turns out Andrew Connell has a great one Angular, React or Vue – Which Web Framework to Focus on for SPFx?. Given that his post is so good and takes the high road on which framework to choose I instead will provide you with my personal journey through the choices I made, the challenges I had and how I feel now.
Let me start by first saying I am a huge fan of Angular. I started like most with AngularJS and moved on to Angular 2, then 4 and 5. As a framework, it gives me everything I need and more. I’m a SharePoint developer from way back and Angular with TypeScript has made the transition from server-side C# development to client-side easy. Since I have so much familiarity with Angular and have built some great Single Page Application in SharePoint using it, it is my go-to framework.
Master Plan Thwarted
Given where I was coming from when it was time to develop a highly customized client-side application in Microsoft 365 I was no doubt going to start with the tried and true Angular pattern. Using Angular CLI, Angular 2+, PnP Core JS, TypeScript and then taking over the home page with index.html from our Angular app. Easy Peasy. This pattern is battle tested, robust and allows us to control every aspect of the UI. WCGW.
Well, it turns out if you decide to go with this approach there are some things that can go wrong. The most important consideration is whether the site collection you are going into is a classic site collection or a modern site collection. If you are still rocking classic, then this pattern is still a viable option, business in the front and party in the back. You can create a folder on the site (through SharePoint Designer or PowerShell or whatever) and upload your assets and you are good to go. Angular hanging out in your site collection making REST calls all day.
However, if you are targeting a modern team site or communication site this simply will not work. Microsoft will prevent you from creating folders outside of actual Document Libraries. But I’m a Site Collection Admin you say? Don’t care, I tried, no dice. Ok fine, I’ll just stick my files in a folder in Site Assets. Sure, okay but how are you going to render index.html? Now that it’s in a document library it will show it in the file previewer. Nice HTML you got there.
Before I move on to where I went next, I want to add yet another caveat to this. If you do decide to go classic but you know some level of Microsoft Teams integration is in your future, think long and hard about your choices. Adding your angular app via Web Site Tab link is an easy “integration” but it just keeps the user in Teams, it’s not really integration. True integration, the kind that comes from developing an actual Teams app with Tabs (configurable and static), connectors and bots and all that awesome stuff, well that can get bumpy with the index.html app approach. The biggest issue is that SharePoint is going to prevent it from being i-framed in a static tab. That means your UI isn’t reusable in Teams and that’s a bummer. Fortunately, modern pages are super smart, and when used in teams all the SharePoint chrome and navigation is hidden, leaving you with just your page and the SPFx web parts on it. So, you know, that’s sweet.
Where do I go from here?
Okay so at this point I was licking my wounds a little bit looking for my next course. Basically, saying to myself, Angular I am not giving up on you. This is where I found great articles from Sebastien Levert (SharePoint Framework & Angular Elements: Building your first Web Part) and again of course Andrew Connell (Solve the SharePoint Framework + Angular Challenge with Angular 5.0 Elements). Angular Elements to the rescue!
Following their examples, I got the typical hello world scenario working and continued to build upon it all the while asking myself if I was doing the “right thing”. By right thing, it was a little voice saying give React a shot, Microsoft is using it, it can’t be that bad. I ignored the voice and moved on. Progressively, I layered in components, injectable services, directives and third-party modules. Somewhere along the way I broke things but kept digging deeper into the mess to fix and resolve and pull out some hair. I had many factors working against me, many of my own creation. Transitioning an Angular CLI app targeting ES6 and trying to get all of that refactored into an SPFx approach using Gulp, ES5 was probably a bad idea. know I could have changed the target from ES5 to ES6 but that’s a whole other mess of transpiling and other things I didn’t have time for. This all made me feel like I was running in circles instead of following a path Microsoft paved for me with React, so I abandoned Angular Elements. For now, that is.
The other factor in my mind that lead to this abandonment is that Elements are still being developed and I like cutting edge, but I don’t like bleeding. I know I will revisit Elements when they are ready but for now, they are on a shelf in the garage. I also considered how they don’t work with Office Fabric UI yet and my thoughts are if you don’t get to own the whole playground then maybe you should play nicely with other kids on the playground.
Sure, I could have looked at other framework options, but if I’m in SharePoint and dropping Angular why try to rock the boat, just embrace what Microsoft is using. Tail between my legs but the new goal in sight I set off. My goal was simple really, I just wanted to rebuild some version of the Angular App I had already built to get a meaningful feel for the framework in a real world (no hello world) scenario.
My first reaction is…man, it renders fast. I felt like the UI was quick to redraw on state changes. Speaking of state, I sort of get it. I define an object and when that object changes UI do your magic and update as needed. I’m sure I butchered it there but it’s a start. I’ll need to dive deeper into all the different react elements and how state is managed between and among them to create a harmonious relationship.
Like everyone, I am NOT A FAN of the approach of having my HTML in my code and returning it out of a render method. That is probably my first and biggest beef, as I am sure it is with others. Not a technical issue by any means just one of habit, it doesn’t “feel” right and I could see my render method being the biggest chunk of code in the file. I think the size of some of these render methods can be managed by creating smaller more composable React Elements very similar to how I have many components in Angular. I just wish there was better separation between an HTML file and more code-based logic in my TS file. Oh wait, I mean TSX file…I thought that was an Acura, but I digress.
Admittedly, I’m still a newbie but my two main other complaints are probably more because of my so-called baggage coming from Angular as a complete framework. First is routing, it’s great in Angular and a bummer that you’ve got to use a third party in React to do this. Second is dependency injection. This was so easy in Angular that I took it for granted. Again, I’m new so I will figure out the best patterns or libraries to make this better, but I mean instantiating my own services I mean who does that. I loved that Angular did this for me and managed it the whole time.
The jury is still out. I mean I don’t hate React and I am sure with time I’ll establish some consistent approaches and patterns within the framework. I didn’t become a fan of Angular overnight, after all, it took a few rounds with it to get there and I’m sure this is no different. I do think that exposing myself to another framework on some real-world scenarios can only make me better when I go back to Angular. I mean if…no I really meant when.