Working with @Polymer 2 in @VisualStudio 2017 #webcomponents

You'll be pleased to know, that we now have excellent support in our favourite IDE for creating and consuming Polymer 2 components! Sure, you could use JetBrains' WebStorm or the cross-platform Code editor from Microsoft. But Visual Studio still has your back! Let's explore the support together:


Let's pick a .NET Core project template, choose to create a MVC Web Application and right-click on the bower.json file to manage our bower packages (Polymer is still using Bower):



Then, install Polymer and iron-icons:



If you get a nasty error message, saying something along the lines of  ECMDERR Failed to execute "git ls-remote --tags --heads git://...", exit code of #128 fatal: unable to connect to github.com ... , then open a command window and type out  git config --global url."https://".insteadOf git://  to connect to github using https instead of the git protocol. Then try installing again 

Alright! Let's do the coding required. This part of the article is shamelessly stolen from the Build an element tutorial on polymer-project.org.


Add a components directory beneath the wwwroot and add a HTML Page underneath, calling it icon-toggle.html. This is the component which we'll consume inside another component, which - in turn - we'll consume from our view page. Something like this:

/Home Controller -serves- /Home View -embeds- demo-component -embeds- icon-toggle.

As you edit your code, you'll see how Visual Studio holds your hand:

*sighs happily* (。◕‿‿◕。)


Then, we'll code its consumer - the demo-component. It should look like this:


We will not need to touch the controller, since it already serves the Home/Index view. The view, however, we'll adapt as such:


So far ... so ... meh? Embedding local HTML components/web parts/partials is something we've done forever. Let's move the components to another server, so that we feel like we're actually doing something new.

Let's take our components and the lib ('cause we're too lazy to traverse the icon-toggle's dependencies) and put them in a random storage account in Azure using Microsoft's Azure Storage Explorer!



Now, while I'm sure this is not a representative example, I couldn't happen to notice that there were an awful lot of dependencies in the lib folder:


However, once everything is done, we can rewrite the path to our demo-component and point it to the skies!

Views/Home/Index.cshtml


And lo and behold! It still works 




Now, for this to work, I had to
1) Ensure that the Public Access Level for the Container was set to Public Read Access.
2) Ensure that the CORS settings for the Blob Service allowed access from http://localhost.

Fun times! Let's all write web components a plenty!

Comments

Popular posts from this blog

Auto Mapper and Record Types - will they blend?

Unit testing your Azure functions - part 2: Queues and Blobs

Testing WCF services with user credentials and binary endpoints