Angular routing is pretty nifty. Going into how it works is beyond the scope of this post (and there’s plenty of resources out there doing just that), but suffice it to say if you’re working on an Angular application, you’re using Angular’s routing.
One of the things Angular’s routing does to increase performance is reusing a Component for a route that has already been instantiated. Say you have a Component, “MyComponent”, tied to a route, “/MyPath”. “MyComponent” isn’t created until the user actually navigates to the “/MyPath” route. That makes perfect sense – why instantiate a component that doesn’t need to be used yet? What’s interesting about this design, though, is how parameters factor into it. Let’s say you add a parameter to your “/MyPath” route, making the route “/MyPath/:id”. The first time the user navigates to some version of this route, let’s say “/MyPath/1”, “MyComponent” will be instantiated (with the id parameter set to 1). Then if, without leaving that route, the user changes only the parameter – for example, there’s a link in the component to go to “/MyPath/2”, “MyComponent” will not be recreated. In fact, if not handled correctly, to the user nothing will have changed. It will still look like they’re seeing the “/MyPath/1” version of “MyComponent”. Read more
With the push to move away from On-Premise SharePoint environments in favor of the Office 365 SharePoint environment, Microsoft has drastically changed the landscape of SharePoint development. I’ve been a SharePoint developer since 2007 and making the jump to SharePoint Online has been the most jarring change yet. Of course when SharePoint Online was first announced and as features have been introduced, I’ve played around with them in a strictly “Hello World” capacity, but as any developer will tell you, creating a “Hello World” project for play purposes is drastically different from actually creating a real-world-use project.
I recently got to create my first “real” SharePoint Framework Web Part and here are my thoughts, as someone coming from over 10 years of On-Premise SharePoint development.
When working with Angular Routing, it’s very useful to be able to respond to routing events – the most obvious and useful being when the route changes. In AngularJS this was accomplished with by attaching a callback function to one the “$routeChange” events on the $scope. In Angular the concept is similar but has some key (and in my opinion, useful) differences.
Once you have a reference to the Router for your application you can subscribe to its “events” observable. This observable will emit a route-event whenever applicable that you can listen for. Being an observable you can subscribe to it in multiple places, filter for the specific event you want, transform the raw event, or anything else you could do with an observable.