Application Navigation with the New Angular 2 Router

Fri, 24 Jun 2016 00:00:00 +0000

We are building an application on Angular 2. We’ve beeing working with Angular 2 since Beta 8. Recently we have made the upgrade from RC1 to RC3. In this upgrade, it seems as if the official Angular 2 docs have been updated to reflect usage of the ‘new’ router. Note the big disclaimer at the top.

The Component Router is in alpha release. This is the recommended Angular 2 router and supersedes the earlier deprecated beta and v2 routers.

There is also a great article on thoughtram.io, Routing in Angular 2 Revisited, written by Pascal Precht, which does a great job outlining the new features of the new router.

Out with the old, In with the new

Managing the way our application handles navigation has been somewhat static to date. Mostly a navigation component with static routeLinks littered throughout. We have always wanted to make this component a bit more dynamic. But, our investigations with the “old” router, always led us into complex solutions.

So, with the news, we decided to take the “new” router for a spin to see if we can’t more simply solve some of our navigation issues, with something more native and simple.

If you are interested, the entire example is available here. This example is forked from Pascal Precht example mentioned earlier.

Gettings things setup

One of the most interesting things you’ll find with the new router is that you can use a plain <any>[]. TypeScript will cast it to the correct RouterConfig type. Which boils down to an interface array of type Route. All of fields are marked nullable, which makes this very simple to configure.

Because this is an interface we can provide members that are not part of the Route type and the router won’t get upset. This is super cool because now we can tie information that is relevant to the route, directly to the route config itself.

As you can see in my example, we’ve attached members name, description, showInNav which are not required by the router. In order to feed this into the router, you’ll need to use the providerRouter() and send the result into the providers array on your bootstrapper.

Viola! That’s pretty much all you’ll need to get things going.

Now that the router is all wired up you can go upon your normal business using routerLink very similarly to how you used to. But, since this information is stored in an <any>[] why not use it as a data source for your navigation.

As you can see it’s fairly straight-forward to use the same RouterConfig supplied to the router for consumption elsewhere. Now you could have done this before, however, it required you to reflect data out of the @RouteConfig metadata. The new router makes this very much less painful.

Just for kicks

Just for kicks, I wanted to exercise again, how cool it is to have this data readily available. We wanted the application header to respond to route events. Allowing us to create a consistent, and generic application header.

What we’ve done here was have our HeaderComponent subscribe to the events being emitted by the router. There are several types of events, but, we only care about the RoutesRecognized events. Simply filter them out and subscribe. When the RoutesRecognized events fire off, the HeaderComponent will retrieve the Route.path and find a match in our AppRoutes constant, and assign the result to the routeData member.

Conclusion

We are very much impressed with how easy and flexible the new Angular 2 Router is. It allows for a bunch of new scenarios natively, without having to resort to “workarounds” or “hacks” to get the desired behavior.

If you are interested, the entire example is available here. This example is forked from Pascal Precht example mentioned earlier.

9 SharePoint Development Blogs You Should Follow

Fri, 03 Oct 2014 00:00:00 +0000

I am always mentioning, to various colleagues and customers, the SharePoint Development blogs that I follow. Below, in no specific order, is the list of blogs that I am following:

###Jeremy Thake’s musings### http://www.jeremythake.com/

Jeremy Thake is a Senior Product Marketing Manager at Microsoft focusing on Office 365 developer platform. Lots of great information on transitioning developers to the App Model.

###Richard diZeregas Blog### http://blogs.msdn.com/b/richard_dizeregas_blog/

Richard diZeregas is a Solution Architect at Microsoft. His blog has a lot of detailed information regarding custom development in SharePoint, Yammer and Office 365.

###Share-n-dipity### http://blogs.technet.com/b/speschka/

Steve Peschka works for Microsoft. Not exactly sure of his responsibility but he has some of the greatest posts in regards to developing against Office 365, Azure and Yammer. I would even say that some of his posts are the point of authority when it comes to App authentication/authorization.

###Wictor Wilen’s Blog### http://www.wictorwilen.se/

Wictor Wilen is a Director, MCA, MCSM, MCM and a Microsoft MVP working at Connecta AB. Posts are primarily focused around SharePoint AppModel and Windows Azure from more of the guy on the ground perspective.

###Vesa “vesku” Juvonen### http://blogs.msdn.com/b/vesku/

Vesa is a Principal Consultant at Microsoft focusing on SharePoint. Posts are very developer oriented, with lots of details surrounding making the jump to the Cloud App Model.

###The Nuts and Bolts of SharePoint### http://www.sharepointnutsandbolts.com/

Chris O’Brien is an independent SharePoint/.Net consultant in London, UK. Posts are developer focused with lots of code samples. Also, Chris write frequently on Continuous Integration as it relates to SharePoint solutions.

###Office Blog### http://blogs.office.com/

The Office product blog is actually really good source for information. Jeremy Thake runs an Office 365 Developer Postcast that gets syndicated in the feed, which has been pretty good.

###SharePoint Community### http://sharepoint-community.net/

Open community of SharePoint professionals. Great place for reading what others are doing in the field.

###SharePoint Stack Exchange### http://sharepoint.stackexchange.com/

Q/A Stack Exchange site geared specifically at SharePoint. Some overlap with StackOverflow.com

Office 365 Roadmap - It’s Finally Here!

Fri, 20 Jun 2014 00:00:00 +0000

I’ve had a couple of Office 365 engagements, where I am explaining current functionality of Office 365 and build expectations around the feature set. All so that Microsoft can make a fool of me and make an update to their service.

We’ve sat in partner advisory councils and explained that it’s difficult to assist in growing the O365 space, as a partner, when we have no in roads to the road map of the service updates. Likely others, have similar frustrations surrounding feature releases to Office 365.

Microsoft has finally heard us and has released an Office 365 Roadmap, that will keep updated details surrounding feature releases. We finally have visibility to Microsoft’s aggressive update schedule. Thanks Office 365 Team!

A C# developer's take on F# - Discovery to Production

Mon, 17 Feb 2014 00:00:00 +0000

I had done some discovery around F# back when it first came out. At that point it didn’t seem like a viable option for end to end application development. I knew then, that F# was very powerful language but didn’t quite seem ready for primetime. Today however, is a different story.

I recently, I grew excited of F# after I read Why F# written by Scott Wlaschin (@ScottWlaschin). Looking at these points made me very interested in investigating further. Here Wlaschin says I can be more concise, write fewer lines of code and have fun. How could I not investigate further.

One of my first questions was; can I do all of the things I could in C#? Scott Wlaschin runs another site F# for fun and profit in which he posts another great article Anything C# can do… Okay great! Now can I interop with .NET seamlessly? He’s got another article addressing this too. Well cheers to Scott Wlaschin for putting this information together. Because, now he’s piqued my interest.

I spent the next 3 days re-acclimating myself to the F# language. All the while thinking about how to apply F# to my day to day development needs. The following is a disjointed explanation of my current process and how I believe F# really hits home for me.

Lazy bones

I’m lazy. I’ve been a developer for the past 15 years. I’ve grown tired of typing code for the sake of writing code (Ain’t Nobody Got Time for That); record types (POCO), boilerplate, intermediate types, overloads, etc. I’ve taken advantage of any means possible for not having to write “boring” code (if you haven’t done this already the Edit | Paste Special | Paste JSON/XML As Classes menu in Visual Studio 2012/2013 is an amazing time saver). Writing all this work just to finally get to writing the “cool stuff”.

Some of the things I have done recently to avoid writing a long C# code-base to discover an approach, is to start with a REPL approach using PowerShell. This gives me the ability to get a lot done very quickly by taking advantage of the pipeline, dynamic typing and large set of commandlets available. Once I have an algorithm I’m happy with I’ll port the PowerShell to C#. The languages are similar enough that this process doesn’t take too long. If I’m lucky I have a junior dev that can crank it out for me :)

This is my process for the most part, better or worse. In this I realize that most of my discovery code still has to be transposed as I would rarely use PowerShell to build an production application. PowerShell is very good but still dynamically typed making it somewhat difficult test and it’s typing system is rather limited. No gripes here, PowerShell wasn’t designed for a hardcore developer, it just happens to make for a nifty tool to get things done.

Typing is important (to me)!

I know that I’ve made a large focus (and will continue to) on typing. It is a personal opinion of mine, that dynamically typed languages feel unsafe, when used without tests. Writing tests to address the lack of a static type system, isn’t something I really want to do. I understand this is a very sensitive topic to some; I don’t want to get into a battle; this is just my personal opinion.

Goodbye PowerShell, Hello F#!

I see now that F# can replace PowerShell in my current process of using F# for discovery. Two of the main reasons I use PowerShell is:

It provides me real-time feedback
The pipeline to move my data from one function to another without a bunch of formality

Interpreted

I’m able to REPL my code and get real-time feedback on the nature of my application. This type of exploration helps me understand what my application is doing, during the writing. I’m able to make adjustments without having to refactor and recompile. I can do this directly in Visual Studio with the <Alt> + ; or <Alt> + <Enter> key bindings. I can also run F# interactive (fsi.exe) and evaluate using typing ;; into the editor.

Pipeline

I love the pipeline in PowerShell and the pipe forward operator |> is pretty much the same thing. This is a way to take data and apply the data to a function. This helps get rid of formally naming data that is only used to pass to another function.

C# Extension Methods have helped, a large amount, allowing the chaining methods together. This begins to fall apart when returning different data types. Some creative brackets, nesting and lamba expressions later, you might achieve what comes very gracefully in F#.

Two birds, one stone

Using F# I’m also able to take advantage of some other cool and powerful features of the F# language:

Immutable (by default)

Most variables are immutable by default. This means we cannot change it’s value once it is set. This may seem odd coming from an impetrative world but when you adjust it actually reduces the amount of errors that mutable code brings (changing state and/or purpose). Because variables must be initialized with a value; that there are fewer null checks. There may be times where you want to mutate a variable. You must use the mutable keyword to allow variables to change and the mutate operator <- to change values. Having a separate operator for this is terrific, as becomes quickly recognizable in code, what is mutable and what is not. Static Typing / Native Types

Won’t go into this much, but, satisfying the compiler, a large percentage means you are in fairly good shape. As an example consider a scenario, where we are updating a discriminating union and not updating Active Pattern matching statements to complete the new scenarios. My example here is a discriminating union that supports only Read, Update, Delete.

type command =	| Read
		| Update
		| Delete

let executeCommand command = 
	match command with
	| Update -> printfn "updating"
	| Delete -> printfn "deleting"
	| Read -> printfn "reading"

executeCommand Update

Now say that we want to extend our command type to include “Create”

type command = | Create
			   | Read
			   | Update
			   | Delete

The compiler complain, saying that the pattern match expression is incomplete. Now, imagine some large C# codebase and trying to find all the dependent statements with one small update. Hopefully, you have tests to back everything and that everything is wrapped and handled in some common library. Making the update less painful, but, this requires composition and disciple. We get this for free with F# AND we are avoiding nulls, without a single null check. YAY!

Production Ready (no more transposing to C#)

F# being able to do all things necessary for both a PowerShell and C# replacement, there is little reason to transpose F# to C#. Rather, I can now build discovery code that I can use for production. This realization is hard for me to believe.

Conclusion

F# seems to hit a wonderful sweet spot for me. Bridging the gaps between my discovery and delivery processes. The language has been thought through, all the way down to the native types (tuples are amazing). With a growing community and large amount of work to get F# a first class .NET language—I believe I will be making some changes. Maybe not 100% but F# will most definitely be my first stop.

Resources

http://tryfsharp.org – Very good in-browser F# interactive and basic tutorial
http://fsharpforfunandprofit.com – Very good tutorials / guides to common questions regarding F#
http://fsharp.org – Great community surrounding anything F#
http://channel9.msdn.com/Tags/fsharp – Channel 9 video’s on F#
http://sergeytihon.wordpress.com – Sergy Tihon (@sergey_tihon) puts out a terrific weekly F# round-up.

SharePoint 2013 - Discovering Timeline View Automation

Sun, 09 Feb 2014 00:00:00 +0000

One of more subtle but great little additions to SharePoint 2013 is the Task Timeline. This is most noticeable when creating a site using the “Project Site” template. During various events within a particular project lifecycle, tasks may be created dynamically. I thought it would be great to automatically populate the timeline with these auto-generated task…boy I didn’t realize what I was getting myself into.

There is little to no documentation regarding the technical nature of the Timeline component on the web. Some posts with people have similar issues as myself and looking for guidance. I still felt this shouldn’t be a terribly difficult task. I started poking around with some the IE Developer Tools. I found code executing from ‘sp.ui.timeline.js’. At this point, I figured I would just read some JavaScript and figure out what I needed to do…wrong! This file is obfuscated. Spent longer than I probably should have, reasoning the obfuscated JavaScript. Even though I did learn a lot, I decided to tackle this a different way.

I popped open Fiddler2 and monitored a simple page load. After interrogating the various requests, I found one that looked like my ticket.

<?XML:NAMESPACE PREFIX="[default] http://schemas.microsoft.com/sharepoint/clientquery/2009"
    NS="http://schemas.microsoft.com/sharepoint/clientquery/2009" />

<request xmlns="http://schemas.microsoft.com/sharepoint/clientquery/2009" schemaversion="15.0.0.0"
    libraryversion="15.0.0.0" applicationname="Javascript Library">
	<actions>
		...
		<query id="12" objectpathid="10">
			<query selectallproperties="true">
				<properties></properties>
			</query>
		</query>
	</actions>
	<objectpaths>
		<staticproperty id="0" typeid="{3747adcd-a3c3-41b9-bfab-4a64dd2f1e0a}" name="Current" />
		<property id="2" name="Web" parentid="0"></property>
		<property id="4" name="Lists" parentid="2"></property>
		<method id="6" name="GetById" parentid="4">
			<parameters>
				<parameter type="Guid">{1293ee92-1074-4687-93d3-516fb8a0b3ac}</parameter>
			</parameters>
		</method>
		<property id="8" name="RootFolder" parentid="6"></property>
		<property id="10" name="Properties" parentid="8"></property>
	</objectpaths>
</request>

The request looks pretty straight-forward. Get the current context, web, list (byID), RootFolders, Properties, then action to select All Properties. The response was as expected. I had all the contents of the property bag in JSON format. Two properties jump out immediately (“TimelineDefaultView” and “Timeline_Timeline”).

[{
	...
	12, {
		...
		"TimelineDefaultView" : "Timeline",
		"Timeline_Timeline" : "&lt;TLViewData&gt;...&lt;\TLViewData&gt;",
	}
}]

Looking at this data, I made some pretty large assumptions. The Timeline supports multiple views. Each view is prefixed with ”Timeline_”. Acting on these assumptions, I took the value of the Timeline_Timeline entry, decoded and formatted. After review it looks like the jackpot. While very shorthand we can see Milestones, Callouts, Tasks, Options and formatting.

<tlviewdata>
  <!-- Item Format Set -->
  <fmtset>
    <fmt id="0" type="0" t2="1" t1="0" thm="0001" clr="FFEE2222" />
  </fmtset>
  <!-- Callout Set -->
  <fltset>
    <ft id="{00000000-0000-0000-0000-000000000000}" h="20" x="0" y="4294967282" fmt="1" uid="4294967295" uidsrc="1" ontl="0" />
  </fltset>
  <!-- Bar Element Set -->
  <tskset>
    <t id="{00000000-0000-0000-0000-000000000000}" fmt="0" uid="4294967295" ch="4294967295" uidsrc="1" ontl="0" />
  </tskset>
  <!-- TimelineOptions Set -->
  <options dateformat="255" panzoomt="9" projsummfmt="3" showdates="1" showprojsummdates="1" showtoday="1" showts="1" timelineheight="110" timelinewidth="-1" timescalet="8" todayt="10" />
  <!-- Milestone Set -->
  <mlset>
    <m id="{00000000-0000-0000-0000-000000000000}" x="0" y="35" fmt="2" uid="4294967295" uidsrc="1" ontl="0" />
  </mlset>
  <!-- Text Style Set -->
  <txtset>
    <style id="0" type="0" thm="0001" clr="FFEE2222" strk="0" und="0" ital="0" bold="0" font="Segoe UI" sz="8">
  </txtset>
</tlviewdata>

Seemed like a rather large bit of xml data to store in a property bag. Made me think—why store information this way, rather than on each item directly? My assumption is, doing it this way, likely prevents any event handlers from being triggered, when simply modifying what items are appearing in the view. One step better might be to store it in JSON format; A bit more concise and likely easier to deal with from browser. If I recall, looking at the obfuscated “sp.ui.timeline.js” there was quite a bit of code to serialize the JavaScript objects into XML.

At any rate, now that I have some sample data, I copied the data and pasted the code into some a .cs file using the “Paste Special”, “Paste XML As Classes”. I found this worked a little better than using xsd.exe to take XML –> XSD –> CS (xsd.exe had generated more unboxing code :T ). I had to fix a little bit of data typing but easier than typing up all the classes by hand.

Now that I had C# classes, I can de-serialize, manipulate, serialize and store back into SharePoint. I’m a bit lazy, so I have leveraged .NET server side (was already in a provider hosted solution). I would have rather liked to have done this on the client, but, that means I have to find a good library that can serialize/de-serialize JavaScript objects from/to XML (in browser). If anyone knows of a good one, I would greatly appreciate a link Smile

All this headache for doing something, that should be, so simple. I hope I have, at the very least, saved someone the work when automating the creation of Timeline views. I’ll try to follow up with a commented XML document and/or a set of documented classes with XML serialization attributes.

Application Navigation with the New Angular 2 Router

Out with the old, In with the new

Gettings things setup

Generating some navigation

Just for kicks

Conclusion

9 SharePoint Development Blogs You Should Follow

Office 365 Roadmap - It’s Finally Here!

A C# developer's take on F# - Discovery to Production

Lazy bones

Typing is important (to me)!

Goodbye PowerShell, Hello F#!

Interpreted

Pipeline

Two birds, one stone

Immutable (by default)

Production Ready (no more transposing to C#)

Conclusion

Resources

SharePoint 2013 - Discovering Timeline View Automation