Nov 14 2018

My new book: Hands-On TypeScript for C# and .NET Core Developers.

Category: Asp.net core | JavaScript | TypeScript | AngularFrancesco @ 03:28

An exhaustive introduction to modern client side techniques for .Net Web developers.

All you need to learn for using modern client-side frameworks like Angular in a single place! I conceived this book to avoid the frustration of a never-ending search for the knowledge required to afford a modern JavaScript framework. This book consolidates in a single place all the knowledge required to implement a modern "rich-client" Web application using a non-trivial JavaScript / TypeScript code base:TypeScript, ECMAScript 6 features, JavaScript modules, TypeScript library development  and testing, bundling modules with WebPack, and the Angular single page application framework.

TypescriptCover_

JavaScript was initially conceived to enrich server-generated HTML pages with JavaScript widgets, including date pickers, autocomplete, tabs, and so on. With the increase in available internet bandwidth, and the enhanced computational power of desktops, laptops, mobile devices, and smartphones, in order to ensure faster responses to all user inputs, and to be in a position to better exploit all available resources, increasingly, application logic moved from the server-side to JavaScript code on the client machine, that is, until the diffusion of single page applications, where the entire application logic runs in JavaScript on the client machine and the server's role is limited to handling shared data, as well as authentication / authorization logic.The increasing complexity of JavaScript code bases led to the definition of new JavaScript specifications and toolsets to bring JavaScript from the level of a scripting language to that of modern object-oriented languages, like Java, C#, and C++. Among the significant changes and tools, the following are worthy of mention:

  1. The new ECMAScript 6 specifications that turn JavaScript into an advanced object-oriented language.
  2. The new TypeScript language that adds types to JavaScript to enable better compilation-time checks, and implements almost all new ECMAScript 6 features that are not yet supported by all browsers. What makes TypeScript great is that it is JavaScript of the future plus types, and that it transpiles to browser-compatible JavaScript.
  3. JavaScript library repositories, such as NPM, that are capable of automatically tracking dependencies among libraries.
  4. JavaScript test frameworks, such as Jasmine.
  5. The organization of JavaScript code into modules, and the usage tools called bundlers that facilitate the linking of several interdependent modules into a few JavaScript files to add to each HTML page.
  6. Frameworks such as Angular, that contain everything needed to implement single page applications.

Somewhat unfortunately, knowledge of the above subjects is spread across a variety of locations, so it is very frustrating when you come to write modern "rich-client" web applications. For instance, if you decide to learn Angular, you'll discover that you need to learn TypeScript beforehand, and then you'll discover that a knowledge of TypeScript is not enough either, because you also need to learn more about ECMAScript 6 and JavaScript modules. Finally, if you have resisted hitherto, you'll discover that you also need to learn about bundling and WebPack.

This book consolidates in a single place all the knowledge you require to implement a modern "rich-client" web application using a non-trivial JavaScript/TypeScript code base:TypeScript, ECMAScript 6 features, JavaScript modules, TypeScript library development  and testing, bundling modules with WebPack, and the Angular single page application framework.

What the book covers in detail.

Chapter 1, Introduction to TypeScript, explains how to install and configure TypeScript transpiler, TypeScript base types, variable declarations, and scoping. It also discusses TypeScript's mission, and how TypeScript types can help you to write, debug, and maintain your code bases.

Chapter 2, Complex Types and Functions, explains the basics of the language: arrays, tuples, interfaces, and function declarations. It also explains how to define new types by performing operations on existing types, and how to simplify your code with ECMAScript 6 destructuring and spread.

Chapter 3, DOM Manipulation, covers TypeScript types used to describe and manipulate the DOM, and how to use JavaScript libraries such as jQuery from TypeScript.

Chapter 4, Using Classes and Interfaces, covers TypeScript object programming, classes, interfaces, inheritance, and interface implementations. A complete code example explains how to architect a modular application with the help of abstract classes, interfaces, and inheritance.

Chapter 5, Generics, covers TypeScript generics, and how to define constraints on generics and type-mappings based on generics. TypeScript generics mimic C# generics, but, like C++ generics, they disappear in the compiled code.

Chapter 6, Namespaces and Modules, covers TypeScript's modular organization of code based either on namespaces, or on ECMAScript 6 modules. While TypeScript modules are completely based on ECMAScript 6 modules, they may run also in environments that do not support ECMAScript 6 modules, since ECMAScript 6 syntax may be processed by JavaScript bundlers such as WebPack, or transpiled in the syntax of AMD, CommomJs, or
SystemJs loaders, that run on all platforms/browsers.

Chapter 7, Bundling with WebPack, contains a quite complete and practical description of WebPack, and of its more frequently used modules and loaders. Here, the reader can learn everything that is worth knowing in terms of using WebPack with most modern JavaScript frameworks/libraries.

Chapter 8, Building TypeScript Libraries, describes how to develop a TypeScript library package with VS Code, how to test it with Jasmine, and how to package it as an NPM package.

Chapter 9, Decorators and Advanced ES6 Features, covers all ECMAScript 6 features, such as Symbols, Iterators/Generators, and Promises, that were not covered in previouschapters. The chapter also covers TypeScript's async/await notation, that is transpiled to Promise-based code, and TypeScript decorators and metadata that are important Angular building blocks.

Chapter 10, Angular ASP.NET Core Project Template, introduces Angular architecture, and describes all the parts an Angular CLI project is composed of, and how to configure a project. The chapter then lists all Angular building blocks, focusing on modules,
components, and data binding.

Chapter 11, Input and Interactions, explains how to take and validate user input, and how to customize standard data binding behavior with pipes and life cycle hooks. The chapter also covers the interaction of components through JavaScript and custom events.

Chapter 12, Angular Advanced Features, covers the details of attribute and structural directive usage and definition. The chapter also explains how to customize components with content projection (that is, filling predefined holes with input content), and how to improve the user interface with Angular animations, giving all details of Angular animation syntax.

Chapter 13, Navigation and Services, covers all Angular features conceived for complex applications, navigation among application pages, and how to dynamically load Angular modules. It also covers how components can communicate with the server using Angular HTTP Client class, and how HTTP Client and other services can be injected into components' constructors with the help of dependency injection. It also describes how to test components and other Angular classes.

Tags: , , , , ,

Oct 4 2017

Building Web applications with Knockout.js and ASP.NET core

Category: Asp.net | Asp.net core | MVC | TypeScript | WebApi | JavaScriptFrancesco @ 05:40

Amongst all the client side frameworks backed by big companies, React.js and Angular.js appear to be the most popular. However, Knockout.js still maintains a good market share, thanks to its interesting peculiarities.

Knockout is based on an MVVM paradigm similar to Angular.js, but unlike React.js. While it is adequate for modular complex applications, at the same time, it is very simple to mix with server side templating, similar to React.js, but unlike Angular.js….Read full article

Contact us if you want to learn more

aspnet-core-running-spa

Tags: , ,

Jun 1 2017

Using TypeScript to implement Multi-Platform Libraries

Category: JavaScript | TypeScriptFrancesco @ 02:40

This time my post has been published on Dotnet curry.com. Enjoy it!

TypeScript can target several JavaScript versions and several module export conventions (AMD, CommonJS, System, ES6, or simply globals + namespaces).

However, in general, each platform requires different configuration settings and a different module structure. As a result, there is no built-in option to simultaneously generate JavaScript and declaration files (d.ts) from a single TypeScript source file for several platforms.

More specifically AMD and CommonJS conventions are covered simultaneously by selecting the UMD module target; but globals and ES6, require different settings….Read full article.

Tags: , , , , , , , , ,

Jun 3 2016

Will Google Angular2 survive to Google own Polymer?

Category: JavaScript | TypeScriptFrancesco @ 00:56

A couples of weeks ago Google presented Polymer features at I/O 2016. In a few words Polymer is about Web Components. Web Components (also known as Custom Elements) are part of the Html and Dom specifications. They are a way of encapsulating both JavaScript, Html templates and Styles within reusable components. Everything is inside the component is not accessible from the external world. So for instance, component internal styles and JavaScript do not affect the remainder of the Web Page. Custom elements are associated with custom Html tags,so the developer may use them, by simply writing the custom tag. Since custom tags may contain other Html inside them Web Components may be nested. So for instance, you may define a “grid” custom element that may contain custom row or column templates inside of it..

At moment browser support for Web Components is limited basically to Opera and Chrome, but there are hundreds of polyfills that simulate them.

Polymer furnishes both:

  • A polyfill for browser not supporting Web Components
  • A complete set of already implemented components
  • Various tools to help you build web component based applications.

Angular team declared that they will end up adopting Polymer Web Components inside Angular. Since there is an overlap between Web Components and Angular custom elements, it appears that most of Angular UI logics will end up being completely substituted by Polymer Web Components.

This transition will be driven by the support provided also by other Browser to Web Components. In fact, with native browser support Web Components will over-perform slower simulated Angular UI constructs.

To say the truth, also polyfilled Web Components are faster than their equivalent Angular constructs, because normally Angular2 must visit the whole Model behind the page to perform changes detection each time an event occurs!

Thus for instance if you change a value in a grid with 10.000 items, it must check all all 10.000 items looking for changes that might affect the DOM. Luckily, if you use either Immutable objects or observables it is able to restrict changes detection just to the path within the overall page Model that contains the changed property. Please refer to this article for more details on Angular changes detection,and on how immutable objects and observables help the process.

However, this means you can’t use plain JavaScript objects as they are returned by the server, but you have to copy them into ad-hoc designed objects before binding them to the DOM .This was the main criticism moved by Angular sustainer against knockout.js, because of knockout.js usage of observables!

But why Angular1  started with plain JavaScript object and then moved toward immutable objects and observable? Simple! They hoped they might have improved performance thanks to the browser support of the forthcoming Object.observe api!

For the ones that never heard about Object.observe, changes in standard plain JavaScript objects should have automatically caused notifications to functions registered with Object.observe. Unluckily, Angular performance when using Object.observe was unacceptable! In a few words the reason of this unacceptable performance was the too many notifications coming from modified objects. In fact each event may cause a chain reaction of object modifications which in turn causes an unacceptable number of notifications being sent to  the Angular changes detection engine.

Similar problems with other software caused the removal of the Object.observe api from Chrome and  other browsers, and their consequent removal form the initial “standard” proposal.

Summing up, after this bad experience Angular team was forced to move to other techniques to improve performance, i.e.: immutable objects and observables.

So, from one side we have an UI based  on Polymer that has the following advantages:

  1. Based on a W3C standard
  2. Efficient, because in a short time all main browsers should support natively Web Components
  3. Modular, easily integrable with other frameworks, and not opinionated, since Polymer components are not tied to Polymer,but are completely independent chunks of software you may use in any application.The only constraint is that a polyfill be provided for browser not supporting Web Components yet. However, this constraint is going to be removed in a short time since Web Components will be soon implemented by all major browsers.

On the other side we have Angular:

  1. A complete framework, containing everything is needed to develop a client-techniques based Web Application, from User Interface  to client-server communication, and Dependency Injection. However, it is opinionated and quite difficult to integrate with other frameworks.
  2. Slow as compared to native Web Components and with no hope to overcome this gap.
  3. Forces the usage of Observables and/or Immutable objects in performance critique applications. True,that the usage of Immutable objects is expected to grow (give a look to this post for a quick introduction to JavaScript Immutable objects), but being forced to use them, for sure, makes life more difficult to developers in any case. Moreover, the immutable objects  paradigm doesn’t fit all situations,and for sure is not adequate for complex big business objects.

We might expect that with the increasing native support for Web Components Angular will be forced to integrate Polymer style web components,  till an almost complete substitution of its User Interface. Now the point is, is it worth using Angular once its UI stuffs have been substituted with another framework?

For sure a lot of people will continue using it, since it will continue being a “glue” that keeps together various client-side technologies, offering everything is needed to implement a client-based application. It will continue being attractive for companies that need its developers be guided by the “pre-defined style”  of an opinionated framework: a kind of guarantee all developers conform to a common universally accepted “standard”.

However, a lot of freelancers and company with a stronger “governance” of their teams, or company was strength is flexibility, will prefer implementing their applications by assembling modules from different authors/frameworks. Thus choosing each time the tools the more adequate to their current needs: say Polymer for UI,but tools from different authors for client/server communication and routing. In fact notwithstanding  the need of some companies for a complete  omni-comprehensive framework the community is preferring always more self-contained modules easy to assemble with other technologies.

Anyway while its difficult to forecast in detail the future of Angular, for sure it’s worth to start learning Polymer, and/or similar Web Component based frameworks like for instance React.js!

Have fun with Web Components!

Francesco

Tags: , , , ,

May 24 2016

Html enhancements, processing, and fallback: how to organize all of them?

Category: Htnl5 fallback | TypeScript | JavaScript | Asp.netFrancesco @ 02:44

I already analyzed and classified JavaScript techniques for Web Applications in a previous series of posts. In this post I’ll propose a solution to the main problems associated with the enhancement of Html with jQuey plug-ins or with other Html post-processors.  The solution I describe here is implemented in a JavaScript library available on both bower and npm registry

But let start the story from the beginning!

Html post-processors add Widgets or further functionalities (like, for instance drag and drop based interactions). that  either are fallbacks of features not supported by the browser, or that are completely new features (features not supported by any browser and not mentioned in Htnl5 specifications).

Since Html enhancements depend strongly on browser capabilities and on the usage of JavaScript they can’t be processed on the server side with some smart server side template engine, but must be processed in the browser itself.

So there are just two possibilities:

  1. Using client templates that adapt to the browser capabilities
  2. Performing an Html post-processing, that adds widgets and/or features.

If we don’t use an advanced JavaScript framework like Angular, React.js, Knockout, or any other client-templates based framework we are left just with the post-processing option. This is the famous jQuery plug-ins way, where we enhance static Html with by selecting target nodes with jQuery css-like selectors: basically a kind of super-css with no limits on the effects we may achieve.

Also when  we use a client-side template engine, often, we are forced to use Html post-processing techniques! Why? Simple, just because often the functionality we need is not implemented in the chosen client-side framework, so we are forced to use some jQuery plug-in, in any case. This is very common, since there are several mutually incompatible advanced client side frameworks, and their average life is quite short (they either die, or evolve in a partially incompatible way), so the community hasn’t enough time to produce a complete set of useful libraries, while, on the other side, jQuery plug-ins always survive and increase since they may be easily adapted to any framework.

Moreover, Html post-processing may be applied also to the output of already existing modules and for this reason, often, it is the only viable option also when using client-side templates. Suppose, for instance, you want, to apply not supported Html5 input fallback to existing Knockout.js, or Angular.js client controls, you have just two options, either rewriting all controls to include the fallback feature, or applying somehow an Html post-processing.

Summing up, unluckily, Html post-processing still has a fundamental role in Web Applications development. I said, “unluckily”, since while all new advanced client-side frameworks were conceived to improve the overall quality of the client side code, the html enhancement/post-processing paradigm suffers of well known problems;

  1. .While initial page content is processed automatically, dynamically created content is not!  So each time we receive new Html as a result of an Ajax call, or as a result of the instantiation of client-side templates, we need to apply manually all transformations that were applied to our initial static Html, in the same order!
  2. Transformations must be applied in the right order, and this order is not necessarily the order implied by the JavaScript file dependencies. For instance, say module B depends on module A, so A script must come before B script, However, in turn, this implies that all transformations defined in A are applied before the ones defined in B,…but we might need that B transformations are applied before A transformations.
  3. Usually transformations are applied on the document.ready event so it is very difficult to coordinate them with content loaded asynchronously

Summing up, all problems are connected with dynamic content, and with operations timing, so after, analyzing the very nature of these problems, I concluded they might have been solved by creating a centralized register of all transformations to apply and by organizing the overall processing into different stages.

Transformations register

If we register all transformations in a centralized data structures then on one side we may decide with no other constraints their order of application, and on the other side we may apply all transformations, in the right order to each chunk of Html with a single call to the an “apply-all” method of the centralized data structure.That “apply-all” method might be applied at page load after all needed asynchronous modules (if any) have been loaded,and each time new dynamic content is created.

Invoking, the “apply all” method is easy also in most of the client framework based on client templates, that usually allows the application of some processing to all dynamically created content, 

3 Different stages

The complete freedom in choosing the right order of application isn’t enough to deal with several interconnected cooperating modules.In fact, the overall relative order constraints network might admit no solution! Moreover, also when relative order constraints may be satisfied the addition of a new module might break the stability of the application. In a few words: application order constraints undermine software modularity and maintainability.

So we need to reduce relative order constraints by removing all order constrains that depend on the way the modules are implemented and interact and not on the transformations very nature.

For instance if a module applies a validation plug-in while another module performs not supported Hrml5 input fallbacks the very nature of these two transformation implies that the validation plug-in must be applied after the fallback, since it must act on the already transformed input fields (the original ones are destroyed).

However, if modules A, B, C, D,  furnish further features to the main transformation applied by M, it would be desirable that there are no order constraints among them. Imagine, for instance, M transforms some Html tables into grids, while A, B, C, D apply additional features like for instance grouping, sorting, and virtual scrolling.

Order constraints among A, B, C, D may be avoided only if they act in a coordinated way, by exploiting extension points provided by M. In other terms when, A, B, C, D transformations are registered, instead of operating directly on their target Html, they should connect to extension points of M that then applies all of them properly and at the right time during the Grid construction.

If A, B, C, D were explicitly designed as extensions of M the designer would take care of their coordination, but what if we are putting together software from different authors?

We must build wrappers around them, and we must use a general framework that takes care of the coordination problem.  A three stages protocol may do the job, and ensure transformations are applied efficiently:

  1. Options pre-processing. During this stage each module connects to extension points of another module it is supposed to extends.
  2. Options processing. during this stage each module configure itself based on its options and extension. Since, this stage is executed just once all processing that doesn’t depend on the nodes to transform should be factored out here. This way it will be executed just once, and not, on each transformation call.
  3. Actual node transformation. This is the step we previously called “apply all”. It is automatically invoked on the initial content of the page, and then it must me invoked on the root of each newly created content.

All above steps are applied in sequence (all modules perform 1, then all modules perform 2, etc.)

Since, module coordination, is handled in step 1 there is no need to impose order constraints to ensure coordination of cooperating modules. This way order constraints are minimized. Only the “natural” constraints easy to figure out just by the definition of each transformation, should remain.

In the software implementation of the above ideas, called mvcct-enhancer, for registering a module we specify 3 functions each executing one of the threes stages described above. All module options are specified within an overall options object where each module has its own sections (i.e properties). Connections, to other modules extension points take place by adding option values (that may be also functions) in the options section of the target module. The functions that process steps 1 and 2 receive just the overall option object as argument, while the actual transformation function receives two arguments, the root node of the chunk to transform and a bool set to true only for the initial processing of the page static content.

mvcct-enhancer has functions for applying all transformations on a dynamic node, for initiating the three steps protocol, and for waiting for async JavaScript loading. It has also a basic Html5 input support detection and fallback module that has extension points to add jQuey widgets.

We implemented also a module that provides widget extensions based on Bootstrap, called bootstrap-html5-fallback. It is a good example on how to build wrappers around existing software to use it with mvcct-enhancer. In fact the the main purpose of mvcct-enhancer is to provide a framework for coordinating several already existing modules written by different authors, at a price of writing a few lines wrappers.

That’s all for now!

In the next post we will see an example of how to use mvcct-enhancer to provide, Html5 fallback, and globalized validation to Asp.net Core Mvc with the help of the Asp.net core new version of the Mvc Controls Toolkit.

Francesco

Tags: , , , ,

Nov 20 2015

New Mvc6 Controls Toolkit

Category: TypeScript | JavaScript | MVC | Asp.netFrancesco @ 04:50

Web development changed dramatically in the last few years and the Mvc Controls Toolkit team run after all changes to offer a state of the art toolkit, but now it is time to redesign the whole toolkit from the scratch! JavaScript world evolved, and web applications reliy always more on client side techniques. New JavaScript frameworks appears and evolve quickly, thus the need of a better separation between server side and client side world. The new Mvc 6 Controls Toolkit answers to these new Web Development boundaries are: TypeScript, a better separation of JavaScript world coordinated with server side C# code through trans-compilation of C# classes and attributes, native support of the most common client side frameworks like Angular.js, and Knockout.js, and open support for other client side framework by means of providers,…and more!

 

Please leave you feedback on the specifications of the new Mvc 6 Controls Toolkit!

 

Francesco

Tags: , , , , , , ,