Add UI instead of console.log for SignalR sample

[DovydasNavickas]

/cc @giedriusgrabauskas

[DovydasNavickas]

Gonna add TypeScript + React + Simplr Flux solution and make the sample visual.

Later on, abstract away the messaging pipeline and add two implementations: SignalR and HTTP using same authentication logic, which might be a good start for a simple standalone JS library.

And when we will have abstracted messaging pipeline, PRs for other JS frameworks will be really welcome.

Also, after implementing this we'll most probably rename the project to Single Page Application + ASOS sample or sth. More ideas on naming are welcome :clap:

[kevinchalet]

Copied from https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server/issues/173#issuecomment-162612250

---

@DovydasNavickas :

That would be absolutely fabulous! Yes, please, count me in.

I highly appreciate your offer to help me in creating the Web API part!

Which kind of requirements would you want to see fullfilled by the front-end part? Are there specific framework versions you would request to be used (Angular v1/2, Typescript v1.x)?

Do you believe we have a chance to get this finished til January? In January I would want to get back to work. That would then considerably restrict the time I could spend in this project.

[DovydasNavickas]

I think of something like this maybe?

And by saying Identity server client I mean that it will understand Identity server tokens.

Also, Angular version could be any that you are comfortable with, although if I were to choose - I'd say Angular 2 is pretty stable already and might be a good way to go. As we are using RC1 packages here and will update samples to use RC2 as soon as they are released and stable (cough.. rc1-update-1), it's on the bleeding edge either way.

For the TypeScript though, I'd prefer using the newest version, for which we could have a common gulpfile.js. Another question would be about CI and TypeScript compilation. Any ideas, @PinpointTownes?

[SetTrend]

Sounds good to me.

So am I right to assume that we would have five projects in the solution, three of them being ASP.NET Web applications and two of them being TypeScript projects?

[DovydasNavickas]

Yes, that is correct. Although I'd make TypeScript applications also ASP.NET applications, just with simple StaticFiles and "Route everything else through index.html" middlewares.

And I think it is possible to finish sample until January :+1: That'd be great Christmas / New Year present for many people :tada: :clap:

[SetTrend]

This sounds amazing to me! :smiley:

OK then, let's dive right in ...

Let's join our ideas

From what you wrote, I added a few additional features which I believe are important:

To have the sample be most versatile I would expect the solution to allow for an arbitrary number of client projects being able to connect to an arbitrary number of front end servers (SignalR/WebAPI) and an arbitrary number of identity providers.

This would look similar to this:

I suggest the solution to contain the following projects:

• Identity Server (SSO)
• SignalR 1
• SignalR 2
• Web API 1
• Web API 2
• TypeScript 1
• TypeScript 2

Except for Identity Server, each project will exist twice ("xxx 1" and "xxx 2"). Each of the two project copies ("xxx 1" and "xxx 2") will be rather identical, with just enough differences (e.g. client name) to distinguish them.

Later, the "2" projects may be deleted from the solution, but for now while debugging it'll be most valuable to always have two of them, so during development we can test whether we correctly provided all the prerequisites to separate the sibling "channels" from each other.

For the front end servers (SignalR/WebAPI) ...

I believe it'll be sufficient to have two actions, both dealing with a local int variable, maintained for each authenticated user (implemented as in-memory dictionary):

• The GET action retrieves the variable value.
• The POST action adds some integer value to the variable.

The client front end ...

• should allow the user to log in with Identity Server and any kind of external OAuth2 provider,
• should be able to connect to any of the front end servers
• should be able to switch between any of the front end servers on the fly.

The client front end will be a single SPA, consisting of only HTML, LESS/CSS and TypeScript. I wouldn't suggest to strain the client side projects with server side overhead. I believe adding server side infrastructure to a pure client side project would lead to confusion and unnecessary configuration overhead.

Yet, how about adding two additional MVC6 front end projects, connecting to the Web API front end servers and delivering Razor content?

To give a live preview I created a front-end mockup today:

(In reality, when connecting to a SignalR front end server, the get button would be hidden and replaced by a Web Socket receive event.)

For this mockup I used AngularJS v1 to fake the user logging in, selecting a front end server and getting/posting value changes.

You may download and unzip the mockup file from here. I stuffed everything (HTML, CSS, JavaScript) into this single file so it can easily be opened without any prerequisites.

[DovydasNavickas]

during development we can test whether we correctly provided all the prerequisites to separate the sibling "channels" from each other.

I don't really get the point of having two WebAPI and SignalR servers.

To have the sample be most versatile I would expect the solution to allow for an arbitrary number of client projects being able to connect to an arbitrary number of front end servers (SignalR/WebAPI) and an arbitrary number of identity providers.

I agree, but that does not require having multiple copies of frontend clients.

Also, I don't think that having multiple OAuth connection points is benefitial. We are trying to show ASOS functionality and configuration here and having more providers would be kind of additional burden that I don't think is good. Of course, that is up for debate.

And yes, with SignalR that would be messages sent to and from server, but to keep it simple, a simple action switch is sufficient I think.

[SetTrend]

I don't really get the point of having two WebAPI and SignalR servers.

Having two of the same clients we can have a minimum of overhead and at the same time have two clients, so we can see how authentication is behaving when a client front end accesses more than a single front end service at the same time, with each of these services authenticating against the same SSO server.

In reality Web API 1 might provide the creation of PDF files while Web API 2 might provide weather data. The same company would choose to provide both services at the same time. And the client front end may access them both from a single web page. Both front end servers would authenticate against the same SSO server.

[DovydasNavickas]

It may be that when I understand how it works I see that there is almost no difference whether there's one or multiple clients, except for client_id's.

How about we make one client for each server and not copy code first and if you will still see the need, we will add them. Sounds fair?

[SetTrend]

Absolutely. I believe it's important, though, to have the code ready and prepared for an n:m relation between front end client and SSO server. We don't need to have two or more similar clients, but I think the code should be safe to deal with two or more when the need arises.

[DovydasNavickas]

I really don't see why it wouldn't be able to, even without adding additional projects. I mean, we could add them to test the integrity you want to have and be calm about it :)

At the moment I'm working on a structure I want to propose... As soon as I have it, I'll post link here.

[DovydasNavickas]

Ok, I'm quite happy with what I have already.

You can find the code here :tada:

As you can see, directory and projects structure is like this:

Servers
    IdentityServer
    SignalrResourceServer
Client
    SignalrClient

I separated IdentityServer, SignalrResourceServer and SignalrClient.

No we need another ResourceServer for WebAPI and start working on frontend structure.

For the WebAPI part it's quite straight forward: Setup WebAPI as usual and add the same JwtBearerAuthentication like here, just without custom event handling, because that is meant for SignalR to be able to authenticate.

If you want to make WebAPI resource server and Angular frontend, I'll wait for a PR then :clap:

Tomorrow I'm gonna be working on incorporating the existing MVC sample into the structure I have now. We'll see how it goes and whether it adds too much complexity or not.

Also, as we talked with @PinpointTownes, I'm gonna add the HelloSignalR sample back. Until we're finished with the whole 5 project thingy we're building here and are happy with it, simple samples that we have already are going to stay where they are.

[SetTrend]

Alright. I'm taking a fork from your project now.

[DovydasNavickas]

Hey @SetTrend! How is it going? Any help needed? :clap:

[SetTrend]

Actually, I'm struggling with setting up a working project. Gee, I haven't been creating so many GitHub issues and MS Connect cases in such a short time since SQL Server 2008 came up in 2007.

These are just the highlights:

• When using a TypeScript project, IIS Express won't start.
• When using an empty ASP.NET 5 project, I struggled to remove unnecessary startup code.
• I couldn't add Angular2 to my project using Bower, because while the Visual Studio Team announced Bower to be the new package manager of choice, the Angular2 team instead abandons Bower in favour of NPM.
• I can't add the GULP packages of choice, because in its current version, NPM creates paths which are too long for Windows.
• The Visual Studio Git extension fails because the paths created by NPM are too long.
• After adding Angular2 to my project using NPM, I'm now struggling with TypeScript because TSC tries to compile the Angular2 sources coming with the Angular2 package.

So, up to today, I haven't been able to set up an empty project with dummy content yet.

That is what I originally meant when I was asking whether we will get this done until end of the year. It's not that there won't be a solution once the obstacles have been pinpointed. But I must evaluate the cause of the trouble first, which is taking so much time.

[DovydasNavickas]

Snap... :grin: You're having some of the pains that me and my team @QuatroCode solved through a lot of pain ourselves...

We were to open-source our gulpfile.ts (yeah, we wrote gulpfile in TypeScript :smile:) and maybe the whole VS project for TypeScript soon, but I see that we're gonna have to do it sooner :sweat_smile:

The Visual Studio Git extension fails because the paths created by NPM are too long.

To solve this and maaaaany other problems, use JSPM. Basically:

jspm init

jspm install mypackagename=npm:packagenameinnpm

Aaaand, assuming you have:

• Your JSPM libs folder set to js/libs
• JSPM config file to js/config.js
• Your main app file at js/app/app.js

In your index.html add these scripts:

<script src="js/libs/system.js"></script>
<script src="js/config.js"></script>
<script>
    System.import('js/app/app');
</script>

Aaaand you're good to go with your React/Angular/Angular2 or any other.

After adding Angular2 to my project using NPM, I'm now struggling with TypeScript because TSC tries to compile the Angular2 sources coming with the Angular2 package.

For turning off TypeScript compilation in VS itself, try adding TypeScriptCompileBlocked=True to your .xproj file:

<PropertyGroup>
  <SchemaVersion>2.0</SchemaVersion>
  <DevelopmentServerPort>8189</DevelopmentServerPort>
  <TypeScriptCompileBlocked>True</TypeScriptCompileBlocked>
</PropertyGroup>

As soon as we add the gulpfile.ts and other stuff to GitHub, I'm gonna ping you here.

/cc @giedriusgrabauskas

[SetTrend]

Thanks, Dovidas, I'll have a look at JSPM now. ... Does it work with devDependencies, too? This is where I'm having the "path too long" trouble with.

[DovydasNavickas]

How specifically are you using devDependencies?

[SetTrend]

I'm using it for GULP packages mainly:

    "devDependencies":
    {
        "gulp": "^3.9.0",
        "gulp-watch": "^4.3.5",
        "gulp-less": "^3.0.5",
        "gulp-minify-css": "^1.2.2",
        "gulp-requirejs-optimize": "^0.3.0"
    }

[DovydasNavickas]

Oh, devDependencies for gulp are still going through package.json, but if I'm correct, npm 3.0+ downloads packages in a flat tree manner instead of nesting everything.

To update npm, if you still have an older version, open cmd as an admin (Win + X -> Command prompt (Admin)) and write command:

npm install npm -g

Also, if have an old version of node, simply download a new version of it.

[DovydasNavickas]

Soooo, @SetTrend. Here you can find an empty VS solution for TypeScript with our gulpfile.ts.

Repository for gulpfile.ts itself and instructions how to use it.

If you find something not clear enough - please tell me :smile: I will update instructions and/or code accordingly.

[SetTrend]

OK, updating Node did the trick. I now have NPM 3.5.2 installed.

Thank you for providing me with your VS solution. I'll have a look at it now.

[GiedriusGrabauskas]

Open cmd as Administrator. Go to: cd C:\Program Files\nodejs And write update command: npm update npm

[SetTrend]

That didn't work for the Node version I had installed. Apparently a minimum Node version was required to update NPM to the current version.

[SetTrend]

But the update didn't change a thing:

It seems there must be a configuration setting somewhere in NPM to tell it not to use recursive directories.

I'll investigate ...

[DovydasNavickas]

Did you delete the old node_modules folder with all it's contents before running npm install with npm 3+?

[SetTrend]

Yepp. Absolutely. It wasn't trivial because Windows File Explorer wasn't able to delete the files in the deeply nested directories. So I had to manually shift some of them up to the drive root. But yes, the whole node_modules tree has been completely rebuilt by Visual Studio's NPM (the new one).

I even rebooted my machine before opening the Visual Studio solution after having Node installed; just in case any updates would silently require this.

[DovydasNavickas]

Ohhh.... Visual Studio npm... :smile: VS has its own npm binaries...

Try using command line for everything :smile: You'll have newest versions and predictable outcome.

[SetTrend]

Hmm... Command line?

That's not what I bought Visual Studio Enterprise for :disappointed:

[SetTrend]

I'll have a look at it ...

[GiedriusGrabauskas]

Try this to update Visual Studio node and npm versions:

• Download node.exe

• Replace node.exe in:

  C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\Web Tools\External\node

• Open cmd as Administrator and go to:

  cd C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\Web Tools\External\npm

• And then update npm:

  npm update npm

[SetTrend]

@GiedriusGrabauskas :

Thanks for the valuable hint!

I've been trying to apply your update procedure for Visual Studio now but although I have updated Node.exe (by copying it to the Visual Studio location) I still get these errors when trying to update NPM:

[GiedriusGrabauskas]

Try to close all Visual Studio and cmd windows. I think some process is using this directory.

P.S. latest npm version: 3.5.3

[SetTrend]

After rebooting I don't believe it did to anything now. It just returned immediately after I entered the command. No progress bar, nothing:

Moreover, the NPM directory is empty now. So the installer apparently had been able to delete everything in the first place but then wasn't able to rename anything afterwards because it had nothing left to rename:

Do you know how I can now easily re-install NPM for the Visual Studio version?

I have just downloaded the latest stable Node package from here. It came with v3.5.2.

[GiedriusGrabauskas]

Use command: npm install npm or npm install npm -f (force)

[SetTrend]

Excellent! That worked. Thank you.

Now I can have a look at the gulpfile.ts project.

[SetTrend]

It looks like the project's GULP file isn't targeted to Visual Studio. It doesn't rely on IIS Express and runs its own TypeScript compilation.

Has there been some change of paradigm which I am not aware of? Is the use of Visual Studio being deprecated?

[DovydasNavickas]

Yep. I can't find an article about this quickly, but if you have VS 2015 Enterprise (newest version is VS2015 Update 1) you are supposed to use task runner (Gulp or Grunt) for TypeScript compilation. They did this because VS TypeScript versions were getting too old too soon and TypeScript versions were being release quite often.

They made great integration with task runners, because you can bind Visual Studio events (project opened, project being built, etc.) for Gulp and Grunt tasks.

So, using gulpfile that we provide, you do not need much configuration yourself (ideally, none at all), except for binding tasks to your VS events.

We might add this to gulpfile itself if we see the need.

[DovydasNavickas]

And for IIS... We don't really use IIS as a SPA development server, because it's a bit easier to configure hot-reloading with Gulp and node server (we use express now).

And it's a few nice features you get with it: By updating CSS (or SCSS and compiling it to CSS) files you get instant visual feedback in the browser. By updating index.html or JavaScript files (or TypeScript and compiling to .js) you get an instant refresh in the browser.

Both of these handy features speed up development quite a bit.

I understand your concerns of "buying VS Enterprise" and then using open-source tools, but up until Visual Studio Code is not a decent enough editor, there is nothing better than Visual Studio anyway.

P.S. We had a good half a year with WebStorm, because VS did not support newest TypeScript version and React JSX... Boy, that was a long half a year.... Now? We simplly use VS for tooling and Gulp for task running, which makes us less dependent of VS release cycles :+1:

[SetTrend]

I'm sorry for the delay. I need a day to dig this ... I've been using Visual Studio as my sole and comprehensive development environment for almost twenty years now. It's hard for me to face the new situation and change a habit that's been growing for those many years. ...

So they now resign and advise to use alien development environments for web client projects because they fail to keep abreast with the fast pace of Open Source? Please understand: to me this feels like an old friend with whom I've been sharing a good and trustful friendship with for twenty years is telling me that he's seriously ill now ... :disappointed:
So, just to make sure and only for my personal peace of mind, helping me to apprehend (my following questions seriously stir up my mind since yesterday. They are meant out of curiosity and, by no means, are meant to be tainted):

• Microsoft has published their strategy to not fully support web client projects in Visual Studio? They endorse to exclusively use an alien tool set/framework (Node)?
• Where did they publish they would relinquish?
• We are supposed to prefer a command line tool (Node) in favor of an integrated development environment? (The last time I had been programming using the a command line shell's lack of comfort ever since was in 1991. Well, except for DOS batch files and PowerShell.)
• We are supposed to script our web client build process manually? No GUI whatsoever? So we actually have to spend a reasonable amount of time for preparing a web client build? And these scripts will rely on a number of third party Node packages?
• We are supposed to fully rely on different source's Open Source - thus lack of SLAs, unfulfilled promisses, lack of thorough documentation, lack of support, lack of common denominator, high pace of breaking changes?

[DovydasNavickas]

In a way, you are right to feel... Different about VS that promotes external tools.

But the world is changing and what you want from VS is to be do-it-all tool for you, which is a bit tricky with the pace of Open Source. Keeping up with OSS and still maintaining SLAs is somewhat impossible, because as soon as you test things out, there are 3 new versions released by OSS community.

Also, Microsoft is building TypeScript as a compiler and compiler has one task: to compile code thrown at it. Watching files is not actually compilers job, which is somewhat you heard from @paulvanbrenk here.

Answering your questions:

Microsoft has published their strategy to not fully support web client projects in Visual Studio? They endorse to exclusively use an alien tool set/framework (Node)?

They did not even have to publish that, even though I think I saw something about TypeScript and task runners... Just can't seem to find the article. The statement you're implying here:

not fully support web client projects

Has evolved over the years and nowadays, if Microsoft would like to "fully support web client projects" according to what people use in web development, they would have to create and maintain their own JSX compilers, task runners, package libraries registry... And invest money and time where others invest anyways (mind React-server for JSX compiling, npm as package libraries registry, Gulp/Grunt/MSBuild for task running, etc.)

Therefore, for Microsoft to add Visual Studio hooks and UI to utilize 3rd party tools more easily, is somewhat what saved Visual Studio from not being used by developers working with bleeding-edge technology, like myself and my whole team. For example, half a year when VS did not support newest TypeScript versions, we had to either use another IDE (which we did, WebStorm) or say "No!" to newest TypeScript features. Believe me, that half a year with WebStorm was a hell of a long one... We were almost dreaming for a day when we can go back to Visual Studio.

And to conclude this comment, I think using task runners has no need for SLA, because they are development time tools, not production time. They simple have no SLA (mind, Service Layer Agreement). And I think you still can use Visual Studio alone for TypeScript compilation and not use task runners at all, but then you sacrifice stuff like SCSS compilation (which is not Microsoft created tooling)

Where did they publish they would relinquish?

If I find the source - I will post it.

We are supposed to prefer a command line tool (Node) in favor of an integrated development environment? (The last time I had been programming using the a command line shell's lack of comfort ever since was in 1991. Well, except for DOS batch files and PowerShell.)

In a way - yes. Because those tools are simply better suited for the purpose. Also, it's not really exchanging IDE for command line. It's just using IDE hooks for calling command line tools.

We are supposed to script our web client build process manually? No GUI whatsoever? So we actually have to spend a reasonable amount of time for preparing a web client build?

Yes, but that's why I'm open sourcing the Gulpfile of ours. It took a great amount of time to fine-tune it and it still can be improved, which we will do. You get those changes for free + you can fill issues if something does not work. Everything like in a descent OSS project.

And these scripts will rely on a number of third party Node packages?

They do, but I simply don't see anything bad with that. NPM as a registry is stable for quite some time already and people bet their businesses on it. Package versions that you use can be fixed and never change if you don't want them to. Also, as I said earlier - there is no SLA required here, because they are used only in development time, which makes worst case scenario - you will not be able to see your style changes in real-time or have to manually run a command for tsc.exe with tsconfig.json that you have either way. And usually, soft like that does not break for no reason.

So, in conclusion to all this, I see these changes as a good thing, because Microsoft can focus on bringing the best IDE experience for writing code, analyzing our projects and giving autocompletion for them, adding IDE event hooks (build, clean, publish) for us to wire our task runner commands and also, on tooling for DNX and vNext in general, which in result comes out as a better outcome, because OSS community takes the role in developing task runners and other tools that we need.

[SetTrend]

I don't want to distract too much from the original meaning of this thread, yet:

I have been struggling for the last six months with Open Source projects coming with no documentation and no support. Up until today the TypeScript team doesn't provide a full up-to-date documentation at all. RequireJS's documentation is incomplete (I added a lot of valuable content to the documentation, yet it wasn't pulled because it was too "hard" for @jrburke to compare them because our line endings differed), Entity Framework does not come with a full up-to-date documentation either, same for ASP.NET. I could continue endlessly... For me as a programmer, that's lack of SLA.

As soon as any of these projects is regarded "finished", they are equally regarded "obsolete". So I find myself most of the time with no documentation (because the project's still beta) or obsoleted documentation (because the project version has been released and now isn't being used by anyone anymore).

That's the next issue: Whatever documentation or samples you find on the Web, it handles obsolete versions of a framework. Samples contradict each other, because they are targeting different versions of a framework. No-one is deleting or updating their samples. So you find yourself asking: "Huh??? Why is he doing that? The other sample leads another way. What's true now?!?"

The lack of stability and the high pace of evolvement yields a new problem: As soon as you have reached a certain degree of knowledge in one framework, another framework you have learned two months ago has changed so much that you can start off right from the beginning learning it again. Given that you want/need to keep up your knowledge with about 20 different frameworks this is a fight you cannot possibly win. (Which is my current, personal point of view. Anyone being able to cope with this fact I honestly invite to share his secret with me.)

Also, Microsoft is building TypeScript as a compiler and compiler has one task: to compile code thrown at it. Watching files is not actually compilers job, which is somewhat you heard from @paulvanbrenk here.

If that's really true then I didn't make my point clear. I wasn't aware that my issue could be regarded as something like dealing with watching files. What I have been suggesting was to use dynamic configuration in preference to a static one. I have now added another comment to clarify.

Has evolved over the years and nowadays, if Microsoft would like to "fully support web client projects" according to what people use in web development, they would have to create and maintain their own JSX compilers, task runners, package libraries registry...

Which is what they actually did over the last years. They are still providing a web browser, for example, although other good implementations exist on the market. They even provide an operating system although there are a number of Open Source solutions on the market. If it was true that the market only required the implementation of an idea once, we would all lose knowledge. I believe it's necessary to have different implementations, different products and different, competing solutions. If there'd be only one single solution to everything, we would soon get a cultural absolutism.

And invest money and time where others invest anyways (mind React-server for JSX compiling, npm as package libraries registry, Gulp/Grunt/MSBuild for task running, etc.)

I'm not asking Visual Studio to redesign these. I'm asking Visual Studio to embrace these gracefully and thoroughly. From my point of view Visual Studio's task is to write a GUI which I can address, and Visual Studio is supposed to convert my GUI input into command line arguments for controlling these tools in the background. It currently does exactly this. But, for example, instead of using the global Node installation it uses its own copy, which I believe is redundant.

I believe that the Visual Studio task is to provide GUI adapters and MSBuild adapters for all those frameworks. Nothing more. If Open Source is so easy to handle it shouldn't be a problem for the Visual Studio team to provide for this.

For example, half a year when VS did not support newest TypeScript versions, we had to either use another IDE (which we did, WebStorm) or say "No!" to newest TypeScript features.

So they seem to be struggling with the same problems I do. That's appeasing.

Yes, but that's why I'm open sourcing the Gulpfile of ours.

I see. But anyway, for each new project one has to re-evaluate if the Gulpfile still satisfies the requirements of that project. Given the fast pace of Open Source that'll result in re-evaluating the Gulpfile each time a new project gets started. So there is no need to put too much effort into it. It'll surely obsolete sooner than you think. So there is no true saving in time.

They do, but I simply don't see anything bad with that. NPM as a registry is stable for quite some time already and people bet their businesses on it.

I'm not talking about NPM, I'm talking about the packages themselves. They obsolete faster than dayflys live. My customers always demand the latest in technology. That's something I cannot deliver anymore, given that they require a thorough knowledge of about 10 different average sized Open Source projects.

I believe - and that's what I mean when requesting an SLA - something should be invented like a Settlement, or, "Usage" time span: "When a version is finished, don't publish or endorse any new "alpha" version for 12 Months. Instead, settle on the achieved project version and only provide support/bug fixes." - That would keep my customers from requesting "new shiny", yet non-existent, features I simply cannot deliver nowadays.

Six months ago the TypeScript team advertised version 1.5 although it still was beta. Google is on their best way advertising their Angular2 like it's been finished, too - although it isn't. This imaginary feature advertising and surreal expectation stirring is something that has to stop. My opinion.

[SetTrend]

Here's a good example: One month ago I moved from NuGet to Bower, because the Visual Studio team endorsed using Bower now to install client packages. As soon as I had learned Bower's syntax and behaviour (which admittedly isn't too different from Gulp/NPM) I now learned that Bower is obsolete and NPM is the package manager to use.

This is just one single example of the many days I have unnecessarily invested from my working time in the last couple of months.

[SetTrend]

You haven't had a chance to look at the mockup file I created 10 days ago. I actually finished it in a few hours. It was only lacking the AJAX calls (which I replaced with dummy calls in the mockup) and ASOS authentication.

It was - so to speak - finished. In a few hours. 10 days ago. Using Angular, CSS and JavaScript.

Today, I find myself not even having a project set up in Visual Studio to provide the prerequisites for that same thing.

[SetTrend]

@DovydasNavickas :

I'm deeply sorry but after giving it a thorough thought I think it's best for me to quit this project now. My vacation is over soon, Christmas and New Year's Eve are near and failing to get some coding done until today I've almost forgotton what I originally wanted to achieve by participating in this sample project.

I think I'm better off by finishing reading the Node, NPM and Angular2 documentation now and have a few days off then before I get going working for my customer afresh.

I deeply regret.

[DovydasNavickas]

It's all good, @SetTrend! Have a great holiday and merry Christmas! Great job on plotting some charts and making me use them also :clap:

[SetTrend]

You, too, have a merry and wonderful Christmas and a great new year 2016! :sparkles: :christmas_tree: :fireworks: :sparkles: