Forem: Progress Telerik

Angular Basics: How To Get the Value of a Selected Dropdown Menu Item

Progress Telerik — Thu, 10 Jul 2025 07:51:22 +0000

Brought to you by the team behind Kendo UI for Angular — a complete set of enterprise-grade Angular components that help you design visually stunning, accessible and high-performing apps faster. Originally published at the Telerik blog.

Have you ever had to ask, “How do I get the value of the selected dropdown menu item in Angular?” Let’s answer that!

In Angular apps, the dropdown is a typical HTML element used in forms and components to allow users to select values. Today, we will learn three ways to get the value of the user’s selected item in a dropdown list with Angular.

Our three approaches are:

Using a change event
Using ngModel
Using ViewChild

Our example app has three components with the same HTML markup, a dropdown with a list of NBA teams, and one property, selectedTeam, on the TypeScript file. We will implement each solution to assign the selected value from the dropdown to the selectedTeam variable.

TeamWithChangeEventComponent: Uses the HTML change event and template reference.
TeamUsingViewChildComponent: Uses the viewChild decorator and template reference.
TeamWithNgmodelComponent: Uses the ng-model directive.

The HTML markup looks like this:

<div class="col">
<p>You select your team {{ selectedTeam }} using viewChild</p>
    <select #teams (change)="onSelected()">
        <option default>Pick a team</option>
        <option>Lakers</option>
        <option>Miami</option>
        <option>Cleveland</option>
    </select>
</div>

And the TypeScript file will have the variable selectedTeam.

{
    selectedTeam = '';
}

Let’s work with the first solution TeamWithChangeEventComponent.

Using the Change Event and Template Reference Variables

To work with this approach, we first use HTML reference variables to read the value and the dropdown event change, listen when the user changes the selection in the dropdown, and create a new method onSelected to assign the value to selectedTeam.

How to Build Modern Angular Dropdowns in Minutes with Kendo UI
Go beyond HTML select by learning how to implement modern dropdowns.

First, create the template variables for dropdown using #teams. Use the event binding to listen for the change event and link with the onSelect method.

The onSelect method receives the reference variable and takes the value of the dropdown element.

The code will look like this:

<div class="col">
<p>You select your team {{ selectedTeam }} using change event</p>
    <select #teams (change)="onSelected(teams.value)">
        <option default>Pick a team</option>
        <option>Lakers</option>
        <option>Miami</option>
        <option>Cleveland</option>
    </select>
</div>

Next, create the onSelected(value) method in the TypeScript file. Take the value as a parameter and assign it to the selectedTeam variable.

import { Component } from '@angular/core';
@Component({
    selector: 'app-team-with-change-event',
    templateUrl: './team-with-change-event.component.html',
    styleUrls: ['./team-with-change-event.component.css'],
})
export class TeamWithChangeEventComponent {
    selectedTeam = '';
    onSelected(value:string): void {
        this.selectedTeam = value;
    }
}

How Does It Work?

Angular uses event binding to link the method, and it gets the value from the parameter because it uses template reference to gain access to the dropdown HTML element.

You can read more about template reference variables and event binding in Angular.

Next, using the viewChild—let’s do it!

Using viewChild and Template Reference Variable

The new approach uses the @ViewChild decorator and template reference variables. In the new scenario, we create the template reference variable for the teams dropdown using #teams and listen for the (change) event. However, the method onSelected doesn’t require passing the value with a slight change.

The HTML looks like this:

<div class="col">
<p>You select your team {{ selectedTeam }} using viewChild</p>
    <select #teams (change)="onSelected()">
        <option default>Pick a team</option>
        <option>Lakers</option> 
        <option>Miami</option>
        <option>Cleveland</option>
    </select>
</div>

In our TypeScript file, add the variable teams, using the decorator @ViewChild with type ElementRef and create the method onSelected() without parameters. But using the reference of teams, we can read the value of the reference of teams and assign it to the variable.

The code will look like this:

import { Component, ElementRef, ViewChild } from '@angular/core';
@Component({
    selector: 'app-team-using-view-child',
    templateUrl: './team-using-view-child.component.html',
    styleUrls: ['./team-using-view-child.component.css'],
})
export class TeamUsingViewChildComponent {
    @ViewChild('teams') teams!: ElementRef;
    selectedTeam = '';
    onSelected():void {
        this.selectedTeam = this.teams.nativeElement.value;
    }
}

But How Does It Work?

The ElementRef is a wrapper for the DOM HTML element, and the property nativeElement has a reference to the DOM object. Using the @ViewChild decorator, we get ElementRef in the component class.

Feel free to read more about the ViewChild decorator and ElementRef.

Using NgModel Directive

Angular has another way to get the selected value in the dropdown using the power of ngModel and two-way data binding.

The ngModel is part of the forms module. We need to import it into the NgModule list in the app.module, which will be available in our app.

The ngModel directive helps us listen and update variables when the event changes trigger, and to use it, add the ngModel using [(ngModel)]="selectedTeam".

Angular automatically gets the value and updates the variable selectedTeam using the ngModel approach when the user changes the value. We don’t need to create the onSelected method in our TypeScript file.

<div class="col">
<p>You select your team {{ selectedTeam }}</p>
<p>The change Event</p>
    <select [(ngModel)]="selectedTeam">
        <option default>Pick a team</option>
        <option>Lakers</option>
        <option>Miami</option>
        <option>Cleveland</option>
    </select>
</div>

How Does It Work?

First, the ngModel directive uses the ControlValueAccessor, because Angular provides access to all HTML form elements like input, select and checkbox by default. It sends the value, and the two-way data binding creates the link between the value and the variable.

If you want to read more:

NgModel
Two-way data binding
SelectControlValue
ControlValueAccessor

Conclusion

We built three different ways to work with dropdowns in our apps. You can find a full code example for this article and play with the example app in the following links:
GitHub repo
StackBliz

If you want to save your time and create fast and advanced dropdowns, then I recommend visiting the article about Angular Dropdowns in Minutes with Kendo UI—it shows you how to use Angular DropDownList in your apps.

Thanks for your time. I hope you can see how many ways there are to work with dropdowns and pick the best for your app.

Can We Make Open Source More Sustainable?

Progress Telerik — Fri, 06 Mar 2020 04:58:47 +0000

If you’re a software developer, you might not realize that the economics behind open source make zero sense to most people.

For example, consider this conversation I had with a normal person a few days ago.

Me: “Sorry I’m a bit late. Crazy day at work”.

Friend: “Ah, no worries, what’s up though?”

Me: “We’re just trying to decide between three different JavaScript frameworks for that project, and the deadline is next week so we have to pick soon.

Friend: “Ah, gotcha. Well which framework is the cheapest?”

Me: “Oh they’re all free.”

Friend:

In most industries you pay for tools that help you do your job, yet in the software world—a world where there’s a ton of money involved—most of us build apps using a variety of free tools.

The most popular text editor? Visual Studio Code—free. The most popular source-control provider? git—free. The most popular JavaScript libraries? React, Angular, Vue, and their competitors—all free. Although paid software very much exists, it’s amazing how much of our critical infrastructure has moved to free and open-source software over the last handful of years.

And although this switch to free-and-open-source tools has been enormously beneficial for developers, and for software in general, this same shift has also had consequences. In this article I’ll discuss one of those consequences: a problematic economic model, and I’ll discuss what I think we can do about it.

Let’s start this discussion by taking a brief look at how we ended up with the open-source model we have today.

How did this happen?

To give you a sense of how much times have changed, here are a few quotes from Microsoft executives from the early 2000s that haven’t aged well.

“Open source is an intellectual-property destroyer. I can't imagine something that could be worse than this for the software business and the intellectual-property business.”

— Jim Allchin, former Windows chief

“As history has shown, while this type of model (open source) may have a place, it isn't successful in building a mass market and making powerful, easy-to-use software broadly accessible to consumers”

— Craig Mundie, former Microsoft senior vice president

Although it’s easy to laugh at these quotes today, they weren’t very radical opinions at the time. Even though open source was already an established and growing concept by 2000, most companies primarily used paid solutions to build applications.

I started my career in software in the early 2000s, and my first job involved an IBM-based IDE for writing Java code, a proprietary source-control solution that I’d prefer not to remember, and an IBM mainframe to host our production apps.

IBM’s Rational Application Developer. I used it in the early 2000s, and it’s still around today.

All of these tools cost money—a lot of money—but they were deemed an acceptable expense because the tools provided enough value to warrant their cost.

The switch to open source happened slowly throughout the following decade. Companies increasingly realized that open-source tools like MySQL and Apache were not only viable, but oftentimes better than the commercial products they were paying big money for.

My personal experience for this transformation was on the web, which in the mid 2000s was the wild west compared to the web we have today. Web developers were tasked with supporting a dizzying set of browsers, ranging from the newly released Internet Explorer 7, to the venerable IE6, as well as Firefox, an open-source browser that was starting to challenge Microsoft’s stranglehold on the browser market.

The tools developers built to manage the complexity of cross-browser development included the likes of Dojo, MooTools, jQuery, and many others.

The jQuery homepage in June of 2007

And while these frameworks took different approaches and used different APIs, they had one important thing in common: they were all free and open source.

Whereas more established development ecosystems—Java, .NET, etc—were still conflicted about the benefits of open source, the web was built on free-and-open-source software from its onset.

This was a boon to new web developers like me, as it meant I could instantly start tinkering with Dojo and jQuery at home, and even start using them at my corporate day job—a place where I was used to paying for the software tools I needed.

And it wasn’t just me who jumped at the chance to use these new libraries. jQuery usage exploded in the late 2000s, and created an enormous ecosystem of jQuery plugins that built upon what jQuery had started. The overwhelming majority of these plugins were free and open source, as that had become the expectation for any web framework or plugin by this point.

This new generation of web software inspired a lot of developers—myself included—and helped build the web into the dominant platform it is today. But this expectation that all software must be free and open-source helped to create one problem we have with open source today: a problematic economic and funding structure.

Open source and economics

Open source projects often start as a passion project for an individual or a small group, which they then share with the world for free. The fact that this is commonplace in the software world is actually kind of awesome.

But that doesn’t mean that the work these developers do is 100% altruistic. The primary incentive to working on an open-source project today is career advancement. For example, many former members of the jQuery team now have prominent roles at major tech companies. Several MooTools contributors now work on React at Facebook. Personally, I worked on jQuery UI for two years, and that involvement helped me get the job I have today at Progress.

There’s nothing inherently wrong with career advancement as the primary incentive to work on open source, but it can become problematic when the project author(s) achieve some success. Because, as it turns out, once you’ve achieved whatever notoriety you had in mind, suddenly dealing with random GitHub issues no longer feels like the best way to spend your Saturday nights.

In this situation, many developers try to gather donations to cover their time and effort. For example, if you look back at jQuery’s site from 2007, notice how there was already a donation button on the bottom-left corner of the screen.

The Dojo project had a similar donation on their site dating back to the same time frame.

Today, these calls for donations more typically happen through Patreon, or through some form of sponsorship, which projects like ESLint and Vue.js use. Perhaps the most notorious example occurs in the popular core-js library, which includes an overt donation request every time you install the library, and which has generated some controversy.

Thank you for using core-js ( https://github.com/zloirock/core-js ) for polyfilling JavaScript standard library!

The project needs your help! Please consider supporting of core-js on Open Collective or Patreon: 
> https://opencollective.com/core-js 
> https://www.patreon.com/zloirock 

Also, the author of core-js ( https://github.com/zloirock ) is looking for a good job -)

In an even more controversial move, last year the Standard JavaScript project started showing ads every time you installed its package.

I guess we now live in the post-"ads in the npm install log" era pic.twitter.com/pSnBnMDNSg

— Quine atom (@qntm) August 24, 2019

As you might expect, developers weren’t too happy about the ad, and npm quickly took action—banning any package that “display ads at runtime, on installation, or at other stages of the software development lifecycle, such as via npm scripts.”

Regardless of what you think about ads in your npm logs, there’s one thing we can probably all agree on: from an economics perspective, the idea that authors want money for their work shouldn’t be surprising at all.

In today’s open-source world there’s a massive disconnect between the amount of value projects like core-js and Standard provide, and the financial proceeds maintainers earn in return for their effort.

With that background in mind, let’s look at what I believe are three different ways we could attempt to solve this funding gap.

Solution 1: Foundations

The oldest solution to open-source funding comes in the form of foundations. The most well-known foundation is the Linux Foundation, which was founded in 2000, and which today has a crazy number of corporate members. The foundation supports some of the biggest open-source projects out there, from Linux itself, to Node.js, to jQuery, and just about everything in between.

The Linux Foundation supports development on a ton of projects.

Although the Linux Foundation is the largest software foundation, there are a variety of others for more specialized software technologies or fields. For example, the .NET Foundation helps support .NET projects, and FINOS, the Fintech Open Source Foundation, supports open-source projects in the financial space.

Although these foundations have done unquestionable good, and are the reason that big open-source projects like Linux stay maintained, they’re not a silver-bullet solution to solving open-source funding.

Perhaps the biggest issue with foundations is the sheer breadth of projects they support. If you’re a company and you pay money to join a foundation—and it’s usually a whole lot of money—you’re relying on the foundation to allocate those funds into the individual open-source projects appropriately. And when there are a crazy number of projects these foundations support, there’s no guarantee that your money will go to projects your company uses or cares about. There’s also some chance that your money will go into a competitor’s open source project or initiative.

Because of this, I see foundations as an excellent solution for large established projects, such as Linux, Node.js and jQuery, but less useful for less-established open-source projects. But the good news is, there’s another model aimed at these smaller projects that’s gotten a lot of attention lately: subscriptions.

Solution 2: Subscriptions

Subscriptions have long been a popular way for open-source project authors to raise money to support their work.

In the early 2000s, services like PayPal were popular for one-time donations and recurring payments. More recently, Patreon popularized a subscription model for funding open-source projects, and a number of different subscription platforms now compete to provide a similar service.

For example, the Open Collective platform launched in 2016, offering a funding model that revolves around public donations.

Today, an impressive set of projects use Open Collective, including projects like Bootstrap and core-js. Because the donations on Open Collective are public, they provide a rare view into how much money some of these projects actually take in. For example, here are the top financial contributors to Bootstrap on Open Collective.

What I like about this model is it offers an incentive for organizations to sponsor projects—and that incentive is appearing on the list of top financial contributors. For example, I had no idea what Segment was, but I looked up the service after seeing they were the No. 2 funder of Bootstrap.

Open Collective is not the only player in this space, as last year GitHub debuted GitHub Sponsors, an open-source sponsorship program built into GitHub itself. GitHub has a pretty big competitive advantage for making GitHub Sponsors succeed, as GitHub itself has been the canonical place to host open-source projects over the last decade.

To GitHub’s credit though, they do take steps to ensure their program gets positioned alongside competing donation services. For example, any project on GitHub can now create a .github/FUNDING.yml file, and in that file you can list all the sponsorship options your repository offers—whether those options are GitHub Sponsors or not.

If you do, GitHub will display a “sponsor” button on your repository, which lists all those sponsorship options for your users. For example, here’s what that process looks like for the core-js GitHub repository.

The last service I want to discuss appears last in the screenshot above, Tidelift, which has a rather unique offering. Tidelift is a ~$1,500 monthly subscription product that provides something they call “managed open source,” which Tidelift’s website describes in three parts:

Tools. We provide tools to keep track of all the dependencies you use, flag issues, and enforce policies
Management. We manage core, mission-critical packages on your behalf, including researching and resolving issues so you don't have to anymore
Maintainers. We recruit maintainers for many important projects and pay them to proactively prevent problems and address the root causes of issues

I’m a bit skeptical of this approach, both because it feels like an indirect way of supporting open-source maintainers, and because I don’t see much incentive for companies to subscribe. Nevertheless, I do like that there are companies out there trying innovative new ways to create a different open-source funding model. And I should also note that Tidelift has raised a shocking $40 million dollars in funding, so there are investors out there that think Tidelift’s model has some real potential.

Overall, perhaps the biggest reason to be optimistic about the future of subscription services is the current number of competitors. More competitors means more ideas, and if economics works like it should, the best ideas will find their way to more and more projects. And the fact that GitHub is now involved, and providing sponsor buttons on repositories, will help ensure that these sponsorship services remain visible.

The reason to be pessimistic about subscription services is they rely heavily on goodwill. Convincing companies to donate money is not easy, and even though these subscription services offer incentives, such as appearing on a list of top donors, I believe they’ll need to offer companies more in return for their cash.

Before wrapping up our tour of open-source funding solutions, I want to discuss one final option you might not have thought about.

Solution 3: Paying for software

In researching this article I read a lot of opinions on how to fix open-source economics, and none of them included the simplest economic solution: having companies pay for the software they use directly.

I have a lot of personal experience with both free and paid software, as I’ve spent my career with both, and over time I’ve gone from a die-hard open-source fan, to being far more pragmatic about when paying for software makes sense—largely because I’ve seen the difficulty of funding open-source projects firsthand.

I was a member of the free-and-open-source jQuery UI project for two years, and am proud that our components helped web developers around the world build better apps. But at the same time, I also saw that when maintainers’ interest goes away, and when sponsorship money can no longer cover the bills, a project can quickly die off. Today, jQuery UI is technically part of the Linux Foundation, but the project’s last release happened in 2016.

I then worked as part of the free-and-open-source NativeScript project for five years, and our framework has helped tons of JavaScript developers build iOS and Android apps. But while working on NativeScript I learned how hard it is to finance a framework when you make no money directly—especially when you compete with the likes of Facebook’s React Native and Google’s Flutter, companies that have a seemingly endless budget and zero revenue goals.

As a contrast to my work on jQuery UI and NativeScript, for the last several months I’ve switched over to work on the KendoReact team, where we sell premium UI components to React developers. Whereas with jQuery UI and NativeScript I had trouble explaining the finances around everything I did, with KendoReact it’s quite simple: developers pay us money, and in return, we give them a suite of awesome user interface components.

A sample app showing off several KendoReact UI components. You can try it for yourself here.

Paid software has a number of benefits. By paying, you get a number of assurances you don’t from a random project you find on GitHub—for example guaranteed updates, more consistent APIs, and a company you can get contact when things inevitably go wrong.

That doesn’t mean that paid software is perfect. Charging money for software makes it harder to build a community, as you’ll never have as many paying customers as you will have free users. Receiving payments also requires you to have some corporate infrastructure, which can be onerous for small projects.

For these reasons I’m not suggesting that all, or even most software charge money. Open source software has done a lot of good for the world, and should continue to be the way we develop most of our software. But I do believe that paid software has a place, and shouldn’t be something that developers immediately reject out of principle.

Along with foundations and donations, charging money for software should be seen as a viable way to fund software projects.

Wrapping up

In today’s software world there’s a huge disconnect between the value open-source projects provide, and the financial compensation they receive in return.

This disconnect has spurred the creation of a number of services to attempt to make open-source economics more sane. Foundations help ensure large open-source projects continue to run, and subscription services can help smaller open-source project maintainers pay their bills.

My hope is that, in general, we can encourage companies to increasingly pay for the software they use. These payments can come in the form of foundation memberships, subscriptions to open-source projects, or through payments to the software they use directly. Hopefully, the ongoing innovation in this space will help make these payments easier, and encourage more corporations to give back to an industry they benefit from enormously. If they do, it’ll help us explain how open source works to our friends and families a lot easier.

How to Use the KendoReact Editor

Progress Telerik — Wed, 05 Jun 2019 15:48:47 +0000

The editor is a powerful and versatile component of KendoReact, making it easy to add and format text and other HTML content. Learn how to use and customize it in your React apps.

The Editor component in KendoReact is a full-featured, highly customizable WYSIWYG rich text editor that can be integrated wherever you need to provide HTML editing (CMS, forums, ticketing systems, mail clients, chat clients, etc). It enables users to input free-form text, apply a large spectrum of formatting options, and insert HTML content such as images, tables, and hyperlinks.

The Editor offers a large set of built-in tools. You can also add custom tools, change the rendering of all the editor's elements (custom rendering) and extend the built-in functionality by adding plugins. The Editor, like all other components in the KendoReact UI library, is built in TypeScript.

In this blog post, I will show you how to use the Editor, and we will go through:

Getting Started with the KendoReact Editor
How to Customize the React Text Editor's Built-In Tools
How to Implement Custom Tools into the KendoReact Editor
Why Sanitize Pasted Content?

Getting Started with the KendoReact Editor

First, you need to import the Editor component and EditorTools module from the package, @progress/kendo-react-editor. Then, get the needed tools from EditorTools and pass them into the tools prop of the Editor. Setting initial content happens through the defaultContent prop. Getting content from the Editor or setting new content happens using the helper getHtml() and setHtml() functions exported by the EditorUtils module.

Up to this point, you don't need to know how the Editor manages its content or how the tools work. If your project requires customization or needs the Editor's functionality to be extended though, keep reading as we dive into the different ways you can customize or extend the functionality of the Editor.

How to Customize the React Text Editor's Built-In Tools

There are two ways for customizing this editor's built-in tools:

Using the Editor's utility functions for generating tools
Wrapping the tool into a higher-order component (HOC) function, through which to add the new props you need

Using the Editor's Utility Functions for Generating Tools

All the Editor's tools are React components and are generated by a corresponding HOC function. Each tool also has a settings object which is being passed to its generation function as a parameter. The Editor package exports both the functions and the settings needed for tool generation. For example, the Bold tool has been created in the following way:

import { EditorToolsSettings, EditorTools } from '@progress/kendo-react-editor';
const BoldTool = EditorTools.createInlineFormatTool(EditorToolsSettings.bold);

Passing a modified version of EditorToolsSettings.bold to EditorTools.createInlineFormatTool() will create a custom tool. Here's how the default settings of the Bold tool look:

const boldSettings = {
  mark: 'strong', // toggle the 'STRONG' tag
  altMarks: ['b'], // recognize the 'B' tag also as Bold

  // recognize an inline node with font-weight style and a
  // value matching the regular expression
  altStyle: { name: 'font-weight', value: /^(bold(er)?|[5-9]\d{2,})$/ },

  // props which will be passed to the Button component of the tool
  props: {
    icon: 'bold',
    type: 'button'
  }
};

// The messages keys used by the tool for localization. See
// also https://www.telerik.com/kendo-react-ui/components/editor/globalization/#toc-messages

{
  messages: {
    title: 'editor.bold'
  },

  // the name of the command that the tool executes
  commandName: 'Bold'
};

This approach allows you to easily modify the appearance and behavior of the tools without having to learn in-depth how the whole component is built. Follow this link for a full list of settings and functions for Editor tool generation.

Wrapping the Tool into a HOC

The HOC will extend the props of the desired tool and return the custom tool. Then add the HOC function into your tools collection. Simple as that:

const CustomBold = (props) => {
  return (
    <Bold
      {...props}
      title="Custom Bold"
    />
  );
};

<Editor
  tools={[
    [CustomBold, /* ... */]
  ]}
  <!-- ... -->
/>

Currently, the props of all tools extend the KendoReact Button and DropDownList props. In our case, the props that are available for our custom tool are listed in the ButtonProps interface. In other words, when it comes to customizing the tools, you can also configure everything that the KendoReact Button or DropDownList allows.

How to Implement Custom Tools into the KendoReact Editor

The above approach for customizing built-in tools can also be used for generating new tools. For example, if we take the Bold tool settings and change the mark to 'code', props.icon to 'code-snippet', and remove altMarks and altStyle fields, we can generate an entirely different tool that will toggle the <code> element.

const codeSnippetSettings = {
  mark: 'code', // toggle the 'code' tag
  props: {
    icon: 'code-snippet',
    type: 'button'
  },
  messages: {},
  commandName: 'Code'
};

const CodeTool = EditorTools.createInlineFormatTool(codeSnippetSettings);

The Editor's package also exports all the functionality that is used from the built-in tools, which includes functions for formatting, inserting content and others. This allows you to create your own tools for which the foundations have been already laid out (i.e. how to insert HTML content or apply formatting).

Here is an example of our custom code tool and a few more tools for formatting and inserting content:

Why Sanitize Pasted Content?

Pasted HTML content could look quite ugly, especially if copied from MS Word. Lists are presented as styled paragraphs, and content could contain invalid HTML styles, comments and XML strings.

In our experience, people are not always happy with the built-in paste functionality. They often have project-specific requirements, which need to be handled externally. For this reason, we have decided to move the format-stripping functionality outside of the Editor, so everyone can play with the code and edit it as needed.

Theming

As with all KendoReact UI components for React, the Editor can also be styled in all three out-of-the-box themes: Bootstrap theme, Material, and our own Default theme. If you are working within your own design system/theme, you can easily customize the Editor's styling using CSS or create your own theme using the KendoReact ThemeBuilder.

Under the Hood

For the Editor, we have decided to use an external engine instead of implementing our own from scratch. Since HTML editing has been here for a while, currently there are a lot of available engines to work with, and there is no value added in starting an Editor from scratch. After evaluating the available options, we decided that the ProseMirror toolkit is the right choice for our use case. It is very powerful and written in pure JavaScript.

The Editor in KendoReact is a versatile WYSIWYG rich text editor whose functionality can be customized or extended to meet any project requirements. Built specifically for React, it is as fast and lightweight as the framework itself and can save you a lot of development time.

A Look Back at React Europe 2019 in Paris

Progress Telerik — Wed, 29 May 2019 15:54:43 +0000

React Europe 2019 concluded last week. I want to share my experience from the perspective of a first time visitor to Paris, and highlight some of the amazing talks, speakers and attendees that made this event so incredible for myself and my teammates from KendoReact.

For the 5th year in a row, React Europe has held a fantastic conference in Paris, France. My company (Progress Software) had an amazing time not only as a sponsor of the main conference event, but we also participated in the hackathon on Saturday.

The event was held at the Espace Charenton event center in the Porte de Charenton area of Paris and drew around one thousand React developers from all over the world.

Host and emcee Jared Palmer led the conference with a really good message about embracing React, building new things, contributing to open source including ReactJS, writing understandable docs, welcoming newcomers to JavaScript and the community as a whole. If we don't give these people the room to grow and improve, they will find another community that does welcome them.

React has always been a growing and welcoming community, and we have to work extra hard to make sure that doesn't change. I felt Jared's keynote to be an inspiring way to open the conference, which ended up being one of the more intimate of the conferences I had been to as all of the speakers were super approachable. It was a very friendly vibe amongst the attendees and I never once encountered anything to the contrary. The coordinators were not only welcoming to me and my team as a new sponsor, but they went out of their way to show us a good time. I recommend this as one of the few must-attend and must-sponsor events if your team is thinking about going next year.

The food and catering throughout the event was top notch, french breakfasts and baguette sandwiches for lunch, and of course there is no shortage of amazing restaurants in Paris.

It doesn't hurt that React Europe is held in one of the most romantic and beautiful cities in the world. As a first time traveler (as was most of my group), we made some time to get around the city and take in the great landmarks and attractions. But the conference really was the shining light in this trip and I would like to quickly highlight some of my favorite talks and give you my experience as a first time attendee.

We heard from many amazing speakers at this event. Some of them were veterans of react Europe, like Lee Byron, who is the only speaker to have graced the React Europe stage every year since it began in 2015. Others included Michael Westrate, Ives van Hoorne, Brent Vatne, Josh Comeau.

As an avid viewer of the previous years talks, I noticed a lot of new faces that may not have been on the main stage before or had only been involved with lightning talks in the past years. I thought many had extremely amazing talks, including: Ankita Kulkarni, Charly POLY, Olga Petrova Ella van Durpe, and Alec Larson, Charles Mangwa, Lisa Gagarina and Tim Neutkens just to name a few.

One of my favorite talks as a UI developer who loves animations and React Hooks was from Alec Larson (@alecdotbiz), you can check out his full talk "Hooks in Motion" about natural animations!

Another great talk that really resonated with me, and which is valuable for everyone no matter their skill level, was Paul Armstrong's "Move Fast With Confidence" talk. You can preview this already on the React Europe YouTube channel, and they are adding more and more talks every day from the conference, so you should go check them out now to see all of the amazing sessions that you might have missed or just want to watch again. I know I have been spending a lot of time in the past few days checking out the talks that I liked or maybe missed out on while I was there.

It's important as a conference to not simply progress with more advanced talks each year, but to always have something for those who are new to React or even the industry for that matter. This keeps the roster of speakers each year fresh and keeps form alienating newcomers to the React space by making sure there is something for everyone.

A few talks were what I feel to be a little on the advanced side (and this is OK), one example of which is Julien Verlaguet's talk on SKIP, the language recently open-sourced by Facebook. SKIP was a research project to explore language and runtime support for correct, efficient memoization-based caching and cache invalidation. Or I think he described it better when he said that it's a programming language built from the ground up with the ideas of React at its core, meaning that it deals with state in a similar way to React. You will need to watch the talk as it is a very interesting presentation.

I can't talk about everything that was presented on at the main stage, we would be here for hours, but it's all a great reason to go and check out day one and day two of the conference on YouTube, I'll put a list of all of the talks below so you can pick and choose and jump straight to the individual talks.

Talks on YouTube

Currently there are only a few talks posted to the React Europe YouTube page. The full day's video was posted after the conference but was removed yesterday as each individual talk began to be posted. Below are the talks that have been uploaded. I will try to keep the article updated as new ones are posted each day, but it's a time intensive process and it may take a while for all of them to get posted.

React Europe Conference Day One (May 23rd)

The State of React and its Future (Jared Palmer)
Saving the Web, 16ms at a Time (Joshua Comeau)
React-spring: How Hooks Mark a Shift in How We Think of Animation (Alec Larson)
Designing a Rich Content Editor for a Third of the Web (Ella van Durpe)
A Hitchhiker’s Guide to the new ReasonReact (Nik Graf)
Totally Native React With Revery (Bryan Phelps)
Move fast With confidence (Paul Armstrong)
Skip (Julien Verlaguet)
Coders are the new Rock Stars (Daniel Stein/DJ Fresh) (Not Available Yet)
Magic Move transitions in React-native (Hein Rutjes)
Data models all the way; GraphQL + mobx-state-tree (Michel Weststrate)
Lightening Talks (Not Available Yet)

React Europe Conference Day Two (May 24th)

Links still being processed, update coming soon!

Hackathon

This was held on the Saturday after the conference. We posed a KendoReact challenge, offering attendees the opportunity to win an Apple Watch by hacking a demo we put together where attendees built a travel booking site using our React components.

This event was attended by about 20 developers that stuck around an extra day to try their hand at our coding challenges.

Everyone did such an amazing job that we decided to give three runners up KendoReact licenses as well!

One winner (shown above), who combined both our KendoReact challenge and the AWS Amplify challenge, took home the well-deserved Apple Watch and a KendoReact license. As I said above three runners up also walked out with a KendoReact license. Thanks to everyone who participated!

Web Accessibility for Developers: What It Is and Why It’s Important (Part I)

Progress Telerik — Wed, 08 May 2019 19:15:16 +0000

Web accessibility is an increasingly important component of web development, for usability, compliance and many other reasons. In this series we'll explore the topic in depth.

Introduction

In the process of implementing accessibility compliance (Section 508, WCAG 2.0 and WAI-ARIA) for KendoReact, our suite of native UI components for React, we learned a lot on the topic. With this blog series, our goal is to introduce fellow engineers to web accessibility and share our practical knowledge and best practices.

This first article is an attempt to answer what accessibility is and why it matters.

The W3C definition is a great starting point: accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them. More specifically, people can: perceive, understand, navigate, and interact with the Web, and contribute to the Web.

The perfect example for accessibility is if you can use your site without looking at it. Instead, you would listen to a screen reader that describes the UI and navigate with keyboard only.

Why Accessibility is Generally Neglected

While there are many reasons why accessibility is not omnipresent, as it ideally should be, three of them seem to be key. First, it’s hard to accommodate for something that you don’t understand well. Second, making your application accessible requires a lot of work – from understanding the premises of the standards you need to follow to designing the needed features and functionalities into your app (or finding a good way to modify it if it’s a legacy project). Then of course, there’s testing whether your approach has yielded the desired result – and much of the testing can only be done manually. The practices described in this series will make this effort easier, but we are still talking about a serious undertaking.

Third is the economic argument which rightly or not dominates modern decision making: in most cases, a smaller percentage of your clients (or users) would be affected by a disability, which serves as justification to postpone implementing those accessibility improvements for the next release.

Why Accessibility is Important

Ethics

People with disabilities deal with a lot of challenges on a daily basis. If they are among your clients or users, enabling them to interact with your web app is plain human decency.

Market

There's data that one billion people worldwide, and 20% of all internet users, have some form of disability. This is still a minority, but it comprises of a lot more people than most of us would think.

Legal

As legislation in this domain develops, it becomes more and more likely for your business to be required by law to be accessible. The next section focuses on this topic.

User Experience

Accessibility guidelines are designed to help people access and use your website more easily. As a side effect, most of them improve usability and directly benefit all users, including those without disabilities. For example, readable text helps not only people with poor sight, but all users.

Engineering

Many of the good practices for accessibility are good engineering and design principles in general. Often it is the poorly written code that is not accessible. For those of us who strive for mastery of our craft, accessibility is just a matter of doing a good job.

Reputation

Having a more accessible site than your competition is a competitive advantage and can potentially create positive buzz around your brand.

SEO

There is some overlap between good practices for SEO and web accessibility. For example, writing semantic HTML with proper use of descriptive attributes such as labels, video transcription, image captioning and using title and header tags all improve both a website’s SEO and its accessibility.

Legislation

Current legislation is moving in a direction where accessibility is becoming a mandatory feature of the web. In the USA, accessibility is covered by the Americans with Disabilities Act (ADA). Many of the developed countries have similar laws, for example, the UK has the Equality Act of 2010. In practical terms, these laws mean that public sector organizations and businesses are required by law to follow the Web Content Accessibility Guidelines (WCAG).

It’s not just your customers and users you should be thinking about. If your organization has 50 or more employees, you need to accommodate those that have disabilities. This means your internal web tools will have to be accessible as well.

If you are a contractor working for the government, you need to comply with Section 508 of the Rehabilitation Act in your work in addition to the above. By law, all US government services need to follow Section 508.

These laws are not just an indication of good intentions. More and more law firms take legal actions based on accessibility legislation.

Conclusion

We hope you are convinced that accessibility matters and is a worthwhile project to pursue. Now that we’ve laid the foundations, in the following parts, we will explore how to achieve good results meeting accessibility requirements with a reasonable investment of effort.

The Whole Series: What's to Come

Part 2: Types of Disabilities and Best Practices to Accommodate for Them. Here we further define the problem, break it down into sections on different disability types, suggesting individual solutions.
Part 3: Technical Best Practices. This part is technically oriented and focuses on working with screen readers.
Part 4: More Best Practices and Resources. Here we go over more practices about organizing our workflow and further explore how to make this daunting task manageable.

Discovering React Hooks with KendoReact

Progress Telerik — Wed, 01 May 2019 18:52:04 +0000

React Hooks have been available for use since the React 16.8 release. We'll learn how we can start applying these Hooks by using our KendoReact components.

With the release of Hooks, building applications in React and managing the local state of its components is now easier, more straightforward and concise. There is a lot to know about Hooks from a conceptual standpoint, and we have many articles here on the Progress Telerik blog to help you get acquainted with them - I've highlighted a few of them below. In this post, we'll learn about Hooks and how to apply them using KendoReact components.

Building React applications has not always been a breeze - before Hooks there was a lot you had to know about several patterns and practices in React just to do everyday things like state management, separating logic within your components, ensuring that you could share lifecycle methods and such across components, etc. It required understanding about several different techniques like Mixins, Higher Order Components, and or Render Props, something typically only done with classes.

Before Hooks React developers, when faced with ever growing state concerns, would reach for Redux or MobX to manage their data and communication state. This was a natural use for Redux, but there are other forms of application state that using Redux might not be as good of a choice for, like the state inside of class-based components that would use this.state and setState. setState is a method provided in React allowing the user to define and change state over time. This capability used to only be available in class components, until Hooks.

Below are some articles on our blog explaining Hooks in more detail:

Say Hello to Create React App (2/3) to help get started in React
Learn Basic React Hooks State and Effects for local state and effects
Learn Basic React Hooks for Context
Learn Basic React Hooks for Reducers
Learn to Create Custom React Hooks

The ReactJS.org documentation on Hooks is also a great resource that you should know about.

As I stated before, Hooks are great for dealing with certain types of application state. A few examples are control state, local component state and session state. I'd like to leverage Hooks when working with our KendoReact components, but I want to start simple. Let's refactor one of the StackBlitz demos from a demo that uses classes and switch it to using functional components instead.

We will look for instances where the demo is using this.state and this.setState, because when we convert the component to functional we will not have to use the this keyword anymore, and we will not need to use a constructor or call setState. When we work with Hooks, we do things slightly differently. So let's get into refactoring the KendoReact demo that shows how to work with our KendoReact Dialog. I have forked the original StackBlitz demo from the Dialog Overview page, that will be our starting point.

If you look at this demo's main.jsx page which I have shown below, there are several target areas we can identify that will change when using a functional component and React Hooks. The code and lines highlighted in GREEN will need modification, and the lines highlighted in RED will be able to be removed completely.

On line 6 we have a class definition, we need to convert this to a functional component.
On line 7 we have a constructor, on line 8 a call to super() and on line 10 we have some binding. None of these are needed in our functional component using Hooks.
On line 9 we create an instance of our state and give it a default value of true this will instead be a call to the useState hook.
On line 13 we need to rename the toggleDialog function and switch it to the ES6 Arrow Function style syntax, lines 14 through 16 will simply call an update method provided by our useState() assignment called setVisible and the value it will be referencing will be visible instead of this.state.visible.
On line 19 we have a call to render() which will not be necessary in our functional component
On line 22, 23, 26 and 27 we have references to this. and this.state that will need to be to reference visible and toggleVisible instead of toggleDialog and I will explain later on why I want to rename that function.

Let's get started. The first thing we need to do is to convert the class to a functional component, remove the constructor and call to super(), the binding of the toggleDialog() function. There are multiple syntax options we could use here - I prefer the ES6 Arrow Function style:

const multiply = (x, y) => { return x * y };

In our component line 5 would now look like this:

const DialogWrapper = () => {

Let's go ahead and set up our hook that will take the place of the state object. Instead of creating an object named state, we will set up a call to useState() and destructure its return value into a variable that will hold our state and an update/set method to update that piece of state. Our name of our state will be visible and its update method will be called setVisible. We will basically remove the entire constructor and replace it with this one line:

const [visible, setVisible] = useState(true);

Since we are using the useState() basic hook, we also need to import it. Our React import will now look like:

import React, { useState } from 'react';

Next, we need a function inside this component that will deal with calling setVisible for the purposes of toggling its value. We decided that we would name it toggleVisible instead of toggleDialog and since we are in a functional component, the syntax that was used before will not work. For this reason, I will update it to the ES6 Arrow Function style.

This function will simply set the visible state to the opposite of its current state at the time. Behind the scenes React is managing this visible variable in a similar way as it would if you were calling setState in a class component. That management is just being abstracted by something behind the scenes called useReducer but we are not going to get into exactly how all of that works in this simple example. Our new code looks like the following:

const DialogWrapper = () => {;
  const [visible, setVisible] = useState(true);
  const toggleVisible = () => setVisible(!visible);

Now we need to get rid of the render() block and its two curly braces. Also, we need to remove all references to this this.toggleDialog and this.state.visible and change them to toggleVisible and visible accordingly. Now inside of our return() we will have the following changes:

return (
  <div>
  <Button className="k-button" onClick={toggleVisible}>Open Dialog</Button>
  {visible && <Dialog title={"Please confirm"} onClose={toggleVisible}>
    <p style={{ margin: "25px", textAlign: "center" }}>Are you sure you want to continue?</p>
    <DialogActionsBar>
    <Button className="k-button" onClick={toggleVisible}>No</Button>
    <Button className="k-button" onClick={toggleVisible}>Yes</Button>
    </DialogActionsBar>
  </Dialog>}
  </div>
);

Again we have just updated our code in the return() to not reference the this keyword and to use our new function name toggleVisible.

These are all the changes that need to be made. We have successfully converted our KendoReact demo to use a functional component and the basic useState hook. Let's take a look at what our overall changes looked like using and awesome tool called GitHistory:

What I have done here is downloaded the original StackBlitz class based demo into its own Git repo. The class-based version would be the initial commit and then I made a second commit after refactoring to the functional hook style that we made. GitHistory gives me the ability to scrub through those commits and see in an animated way how our main.jsx file has changed over those two commits. I think it's a powerful visual for someone learning how to use Hooks and seeing the change from the old class-based approach to the function based approach.

I have also pushed this repo to my GitHub account where you can view it with GitHistory on your own. GitHistory (created by Rodrigo Pombo) is a very cool plugin that allows you to diff any file in your repo and scrub through the commits and see how over time the file has changed in a very visual way.

This is a great place to stop. We learned what it takes to convert a class component with a simple state object into a functional component using a hook. In the next part of this blog series, we will take a deeper dive into setting up several KendoReact components which have more basic Hooks, plus some advanced Hooks like useReducer, and take our Hooks skills a little further.

Dealing with CORS in Create React App

Progress Telerik — Thu, 25 Apr 2019 18:05:11 +0000

If you've ever built a web app that had to request data from a different domain, you've probably had to wrap your head around the browser's same-origin policy and CORS.

In this article we'll learn how to get around CORS issues using Create React App's proxying capabilities.

The Problem

If our app is hosted under a certain domain (e.g. domain1.com), and it tries to make a request to an API that lives under a different domain (e.g. domain2.com), then the browser's same-origin policy kicks in and blocks the request.

CORS is a feature that allows domain2.com to tell the browser that it's cool for domain1.com to make requests to it, by sending certain HTTP headers.

However, CORS can be tricky to get right, so sometimes people avoid it altogether by serving their frontend and backend under the same domain in production.

Create React App allows us to replicate this setup in development, so that we don't have to deal with CORS there either. It provides two options to do so: one that's very straightforward but is not very flexible, and one that requires a bit more work but is very flexible.

Automatic Proxying

We can tell Create React App to intercept requests to unknown routes and send them to a different domain, using the proxy option in package.json. It looks something like this:

{
  "name": "flickr-client",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "react": "^16.8.6",
    "react-dom": "^16.8.6",
    "react-scripts": "^2.1.8"
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject"
  },
  "proxy": "http://localhost:4000"
}

When we start our app, it will be served under http://localhost:3000. If we request the root path /, then Create React App will respond with the corresponding HTML for our app. But if we were to request a different path like /api, Create React App would transparently forward it to http://localhost:4000/api.

If we look at the network requests in your browser dev tools, we'll see that the request was made to http://localhost:3000/api, but it was in fact served by http://localhost:4000/api without the browser knowing.

It can't get easier than this!

Manual Proxying

If we need more control over how these cross-domain requests get made, we have another option, which is to create a file src/setupProxy.js that looks like this:

module.exports = function(app) {
  // ...
};

That function receives app, an instance of an Express app, so we can do whatever we want with it.

For example, we can use a middleware like http-proxy-middleware to proxy requests just like we did with the proxy option:

const proxy = require("http-proxy-middleware");

module.exports = app => {
  app.use(
    "/api",
    proxy({
      target: "http://localhost:4000",
      changeOrigin: true
    })
  );
};

But we can go further, and use http-proxy-middleware's options like pathRewrite to change the path of the request:

const proxy = require("http-proxy-middleware");

module.exports = app => {
  app.use(
    "/api",
    proxy({
      target: "http://localhost:4000",
      changeOrigin: true,
      pathRewrite: {
        "^/api": "/api/v1"
      }
    })
  );
};

With this configuration, a request made to http://localhost:3000/api/foo will be forwarded to http://localhost:4000/api/v1/foo.

We could also add a logger like morgan while we're at it:

const proxy = require("http-proxy-middleware");
const morgan = require("morgan");

module.exports = app => {
  app.use(
    "/api",
    proxy({
      target: "http://localhost:4000",
      changeOrigin: true,
      pathRewrite: {
        "^/api": "/api/v1"
      }
    })
  );

  app.use(morgan('combined'));
};

So now every time a request gets made to our proxy, it will get logged to the console.

The possibilities are truly endless.

Conclusion

If your web app needs to request data from a different domain, and you want your development environment to mimic a production configuration where frontend and backend are served from the same domain, make sure to take a look at the proxy and src/setupProxy.js options of Create React App. They'll make development of your app much easier!

A Look Back at React Amsterdam 2019

Progress Telerik — Thu, 18 Apr 2019 20:26:47 +0000

React Amsterdam took place last week in Amsterdam Noord at De Kromhouthal organized by GitNation an amazing group of folks who do an amazing job at running developer conferences like JS Nation another Netherlands based JS community project and now conference, React Day Berlin a first of its kind, a full day conference in Berlin Germany, and others. This year's React Amsterdam conference was attended by more than 1500 React developers. I attended the conference, volunteered for both days of workshops and ran a booth for my company Progress to show off our suite of KendoReact UI components.

An Amazing Conference Location

The Kromhouthal used to be a major marine engine manufacturing plant. I showed up the day before and got to see the hall before most of the conference setup was complete. Alone it's a cold dark hall, a scene that in the past would have been a labor intense atmosphere with massive machines, today it's used for major events and can hold thousands of people with its long hall and massively tall ceilings. The venue was easily accessible using the ferry from Central Station to the IJplein terminal but I also could have come from the Noordpark Metro station and in either situation just had a short 5 minute walk to the venue through a bustling creative area having a mix of local resident housing and soon to be a hotel and packing district. This area will continue to be a great location especially with plans to extend a bridge from the city center over the IJ (river). Check out these well-produced videos from the organizers to get an idea of the venue, atmosphere and moods from React Amsterdam past events.

Amazing Workshops Teaching Valuable Principles and Patterns

Although not at the infamous Kromhouthal, part of React Amsterdam (the workshops) took place nearby, in the shadow of A'DAM Lookout at the Tolhuistuin a restaurant also fronting the IJ with amazing views for the workshop attendees. This is where I volunteered for two days and had a great opportunity to work with the workshop instructors and attendees. I love helping out wherever I can, I figure that if I'm in Amsterdam for the conference, I can only do so much sightseeing, I like to work in the city to a certain capacity, feel what it's like to be there with deadlines, requirements and work to get done. There are many others like this and I met a lot of them, I worked with a few amazing volunteers and organizers like Olena, Daria, Sara, Ravi, Nicholas, Maksym, and Aleksandra directly and others that had given up their time in this amazing city to serve the community and I want to thank them for being so awesome. You may not know these people but I want you to know that the success of this conference is greatly affected by their hard work.

Speakers like Kent C Dodds did two workshops (Advanced React & Testing React), one each day and he also spoke at the conference. His workshops were exactly the kind I would have gotten so much value attending, I was able to be a fly on the wall, but I hear that you can visit his sites and get some of this same training. There were also speakers like Andrey Okonetchnikov & Artem Sapegin who gave an amazing workshop on Design Systems for React Developers showing how to design systems offer a systematic approach to the process of product creation. Their view of the IJ was amazing, which in my horrible pictures you can't see.

Maybe I got one of the river, ... Here we go!

In this same venue, we had Michel Weststrate's TypeScript for React Devs and React Native Workshop by Alex Lobera & Horacio Herrera, all of these workshops in three different rooms at the Tolhuistuin.

Across the river closer to the Amsterdam City Center, there was another set of workshops that I'm sure provides as unique of a location as the one I was volunteering at. It was at the Royal Industrieele Groote Club which I walked past several times admiring and not knowing it was actually where the other workshops had taken place. Such a beautiful building like so many others in Amsterdam the City. At that location there were talks from Kitze on two different days (GraphQL Workshop & Advanced React). They also had another interesting fundamentals workshop on [Max Stoiber Modern React.

I could not be in two places at once, but I am very interested in the differences between Kitze' and Kent's workshops. Would love if these workshops were recorded adn given access later on like the talks are done. I know that it would have gaps where the class is working, but the instructors could get clever during this time and maybe live code the exercise on the broadcast. I don't know many ways to make this conference experience more immersive, but this sounds like something they should explore. maybe they already are!

Conference Kickoff

Helping at the registration was so much fun getting to meet everyone even if it was just for a minute to get them a badge and some swag. As an attendee, I got to walk away with a bag and I love my new coffee mug! There were a lot of people to process and I felt we did a good job of getting those people who showed up at the beginning, into the event on time for the kickoff, although hectic with 1500 people coming through the doors over a few hour period. It felt like a success and the conference got underway. I headed to my booth to check in with my tam where I switched hats one last time at React Amsterdam. Working our booth and meeting people that were interested in installing our components and playing with KendoReact. I love talking about the library and getting others excited about it.

Conference Talk Highlights

There were so many great presentations and Lightening talks, I want to take some time to highlight what I think were the most valuable ones that I attended. Being someone who works with a lot of UI, layout, and presentation in React, I am a big proponent of the fundamentals and general knowledge. I start to get lost when it comes to the advanced and deep dive topics outside of UI and basic React, and what's great about this conference is that they have something for everybody. Let's look at some of those talks and review them here:

Requisite React (Kent C Dodds)

The conference started off strong with Kent C Dodds on the main stage with a talk called "Requisite React". In his own words, this talk is about: "Taking a few steps back and thinking about the usefulness of the fundamentals". We learn how to fix a droopy faucet head (with pics), and learn how understanding abstractions help us to be more effective when using them, not only in real life ?? but also in our code. This means being mindful of our abstractions and understanding that each one ultimately has some type of cost. My favorite abstraction that he dives into is that of JSX and I won't ruin the talk, but getting a look at how we can easily convert our Babel into raw JS, we are able to see under the hood and understand this abstraction better. I felt a lot of the talk was mostly about how to level up as a React developer and if you were a boss or manager who sent several of your developers out to React Amsterdam, this is exactly the type of information you want out of the gate!

Refactoring React (Siddarth Kshetrapal)

No time is wasted getting into another very valuable fundamentals based talk around refactoring in React, again we are definitely getting our value right out of the gate with many helpful tips this time from Siddarth Kshetrapel an independent developer from India who does an amazing job refactoring a login and authentication form. Starting with class components and constructors with a fair amount of prop drilling involved, we refactor this code quickly into something more manageable and future proof. Some of the techniques that he talks about are spreading props, using methods passed down in props the proper way and how to ensure that we are not overriding prop values for methods or applying them due to not managing our props correctly. He touches on principles like "Single Responsibility" and "Separation of Concerns". I really like most the parts where he talks about understanding about mixing of controlled vs uncontrolled state and how to avoid this. Pick one, he likes uncontrolled components, and this gives us the chance to get into higher order components or better yet, React Hooks. useSmartness() FTW!

So those talks were very code heavy and I was already in the mood for some straight up slide talk! My favorite kind fo talks! I don't have to strain my eyes and I still learn some new stuff I didn't know before.

A Common Design Language (Andrey Okonetchnikov)

Andrey who also did an amazing workshop on the same topic of Design Systems in React, puts all the pertinent info into a very clean and easy to understand talk on building a common design language and reducing the choices of options between typography, spacing and color to create a design language system. Using a common design language systems allows for reusability of design choices across multiple products and logos. This can be something as simple as he points out as the design of the German government logos vs Austrian government logos. One has a clear design system and language the other although creative lacks distinguishable characteristics that would show a clear alignment of all of its properties through a common design language.

Andrey's presentation had many strong visuals like above that helped to show us how a design system language can help not only your developers and designers talk, but also help your organization speak to its clients and customers clearly and with great meaning and commonality. The presentation leads into design languages for digital products and this is where we tie in the component-oriented capabilities of React that make it easy to define a common language with your UI achieving similar results as discussed before but now within digital products. Truly amazing talk and I really suggest taking the time to watch. I also want to note that React Amsterdam has an amazing design language and have continued year over year to capitalize on this using a similar set of logos, typography, and design.

Designing with React (Mark Dalgleish)

Following the previous design language presentation, we nicely transition into a talk from Mark Dalgleish on designing in React. Using design systems paired with React Mark is able to design in the final medium. Because React is so component oriented, it allows us to build our own domain specific language. I have seen first hand at companies I have worked at like Tesla capitalize on the ability to do this in React and other web technologies. Mark has some other examples of this idea spreading throughout our industry as many companies build their own design systems. Mark's major points back up the ability to capture the design intent from our design systems and applying them to the web and native apps. Seek style-guide is something that Mark's company has created and is a great resource and example of a design system for React executed remarkably.

Another amazing resource that Mark shows off is the React Sketch.app which renders React components to Sketch helping to design with real data, in react with real component code and manage your design system implemented in React. Watch the video for information on an amazing npm package they created called html-sketchapp. I will let you discover that amazing gem on your own.

Server Side Rendering Talks

So far I'm 4 talks in, and I have watched the majority of the talks running back to our booth each break to interact with the attendees and talk components. For someone like me who just likes to be totally immersed in technology and talking about it, this event allows you to get into your element. It's great to have the support of a company like mine that gives us the opportunity to do these events in an organic way and let the people representing their product come here and just geek out on React. Aside from questions I had to field about our own component library, most of the talk at the conference was around fundamentals, bleeding edge features and the React roadmap, what's coming next. just an amazing conference to really get knee deep in JavaScript and React more specifically.

The next four talks are all on Server Side Rendering (SSR) using frameworks like Next JS for pre-rendering, Crystalize for the backend to create lightning-fast scalable SSR React apps, the upsides and downsides of creating apps that use SSR, topics like rehydration, time to interactive and other things related to how our larger e-commerce sites render. In the e-commerce world, shaving milliseconds or maybe even full seconds off of load time can be very valuable. These 4 talks take you on a journey through the benefits and gotchas of SSR.

Next for Next.js (Tim Neutkens)
Lightning fast SSR React (Håkon Gullord Krogh)
Speeding up React SSR (David Mark Clements)
Demystifying Server-Rendered React Apps (Fernando Porazzi)

Lightning Round... One .. Start! (Read Rapidly and Fast)

OK, really fast, let me tell you about the amazing lightning round talks, read this section really fast to get an idea of what lightning rounds are like. There were four amazing lightning talks, I caught two of them in person and watched the other two from home today and I have to say that I walked away from all of them with golden nuggets from each topic that I could use to explore that topic more on my own. below are the talks and a link to them on YouTube.

Fetch Like a Boss With React Async (Gert Hengeveld)
Microjob Multithreading (Vincenzo Ferrari)
URQL Powerful and Simple GraphQL (Andy Richardson)
Showcase of Git History (Rodrigo Pombo)

I'm a huge fan of the library showcased in that last talk called Git-history and after being reminded of its awesomeness as React Amsterdam, I will be playing with this package and using it in some of my upcoming talks and demos to show the change when refactoring class based components to functional components with Hooks, I think this will provide a great visual aid in teaching on this subject. It's easy to use, I can show you right here.

Take any file in any repo of your on GitHub. Like for instance, this article I am writing now:

https://github.com/httpJunkie/telerik-blogs/blob/master/react-amsterdam-a-look-back.md

Replace http://github.com with http://github.githistory.xyz resulting in the following string:https://github.githistory.xyz/httpJunkie/telerik-blogs/blob/master/react-amsterdam-a-look-back.md

Here is a look at what Git History has done with my file from my repo:

If you are not instantly in love with this, you don't exist. I showed my son and he was mesmerized, we noted that if I were to have saved more often, I would have a much more granular step through. This is my nomination for the next years GitNation Open Source Awards (which means nothing, because I'm in no way affiliated with GitNation lol). I just think it is people like Rodrigo who will be highlighted for their contributions to open source. Truly amazing, have I said that enough?

Tech Regrets at Spectrum (Max Stoiber)

I admit that the SSR talks were a little bit over my head, but next up was Max Stoiber to talk about his Tech Regrets at Spectrum which was acquired by GitHub. Another great talk and I don't want to spoil the regrets that Max goes over and I suggest taking a listen to this talk on your own to get the value of lessons learned from hindsight and his experience building a real-world product and shipping it to users.

Scaling Applications with Microfrontends (Max Gallo)

Every once in a while there are talks at a conference where I think the guys on stage are on another level than me. TO be honest I have never built any micro frontends and if I did, I would have no idea how to scale them. When he asked for us to raise our hands if we had even heard of them, I was under strict contract to keep my hand down as I had never even heard of this. Once he started explaining the idea, I understood from a very high level. I like how his talk sets up three main tracks for understanding this micro frontends thing. Why do we need them? What is it? and how do they work under the hood? I was going to need all the hand holding I could get for this talk.

Microfrontends are like a mix between microservices and the actual frontend single page application. Microfrontends are a way of splitting up the codebase of the frontend over many teams, obviously using some type of design system to keep them all similar in style and branding, we have already heard how to do this with extra benefit from React.

Women of React Amsterdam

There was no better way to end the General React Track and the conference than to have three amazing talks by pioneering women in the React space. My absolute favorite talk from React Amsterdam was from Elizabet Oliveira. As well, I was truly inspired by both Peggy and Ashi because I'm slowly getting into GraphQL and to see WebGL and Hooks used together painting pixels has to be one of my runners up for second most inspiring talks at React Amsterdam.

An SVG's Tale (Elizabet Oliveira)

An SVG's Tale like I said is my favorite talk. She is a senior UX designer at Optum in Ireland. If I could give an award for the most inspiring talk at React Amsterdam and the most likely to get me started playing with an old but amazingly robust technology that been given a new lease thanks to React, it's SVG. I have always been a huge fan of SVG, but after her talk, I have so many ideas of how I can use SVG's properly and dynamically in my React applications using inline methods or with JSX and components. It's possible with React JS to create animations and styling that under the React hood may be complex but can allow developers not as well versed in SVG to easily use them through your components. Beyond SVG and React, Elizabet showcases a few of her side projects over the years. One of them is an app that you can record your own vocals over dank hip-hop beats which Elizabet demo's for us with some amazing lyrical skills. This speaker definitely blew my mind and I wish I could have spotted her after the talk to give her a big thank you. Truly amazing presentation, she had everyone out of their seat cheering including myself and at other times fighting back tears because her (fictional) story was so amazing and warm and her performance was pure dope!

The GraphQL Developer Experience (Peggy Rayzis)

Peggy Rayzis has to be the most compelling speaker on the topic of GraphQL especially for beginners like myself. It was one of the talks I was most amped up to hear and as happens in most conferences I got sidetracked and missed it ??. But listening back today I was not surprised at all when Peggy told us that she lived in Amsterdam for a month last year and that it is her favorite city in the world. I think most of us who came out for our first time to Amsterdam has the same feeling. I cannot think of a better backdrop for this event. It was my introduction to Europe proper! I enjoyed taking in all of the knowledge that Peggy brings to us on the subject of GraphQL and she has a great perspective as an employee for Apollo where she works as an Engineering Manager. This company builds the most amazing implementation of GraphQL. Apollo helps us bridge the gap between application and API and I don't want to spoil her talk so I simply suggest checking this one out if you are interested in learning about GraphQL.

Painting Pixels With WebGL And Hooks (Ashi Krishnan)

Ashi Krishnan is a seasoned speaker on so many different topics beyond React. She has been on my radar because of amazing talks like Deep Learning in React and Learning from machines. She works with GitHub in the UK and at React Amsterdam she closes out the General React track at React Amsterdam taking us on a journey into WebGL and how to leverage this journey with Hooks. This talk reminds me of the many things we can do in React that challenge the way we think about what a React application is and what it can do. I first started realizing all the amazing things we could do with React and rendering from Ken Wheeler's talk on building a drum machine or rendering web pages with canvas. Ashi continues to challenge our thinking about React with an amazing live demo using WebGL to paint pixels in React. If I was able to select one talk that I believed mostly encompassed creativity and thinking outside of the box it would be this one. Without giving too much away, she runs through many demos truly artistic in nature that achieve different styles and approaches to painting the screen using WebGL in React.

The React Native Track

Although I have "et, slept and breth'd" the General track at React Amsterdam I was not able to get over to the React Native track that often. But I did make a conscious effort to watch some of it. I have never used React Native but I have heard so many great things about it and did catch a few bits and pieces while I was at React Amsterdam. If I could point to one talk specifically that I think helped me understand React native better it would be the presentation given by the React Native core team member Parashuram which just so happens to also be the first talk of this React native track: Building React Native.

The React Native track can be viewed in its entirety on YouTube. Below is a complete list of all of the talks you might want to hear! If you're more of a web developer and less of a native developer, I would suggest also checking out Native Web Apps by Florian Rival.

On the React native track, we saw strong talks on Practical Perfomrance by Anna Doubková and Making React Applications Accessible by Ankita Kulkarni and Demystifying The Complex Animations Creation Process with Vladimir Novick. All were talks I was able to easily follow along not being a React Native developer.

Building React Native (Parashuram N)
Practical Performance for React Native (Anna Doubková)
Sharing Code Between React and React Native: What Not to Share (Ben Ellerby)
Building for a Bigger World Than Mobile (Wouter Van Den Broek)
Advice Lounge (Panel Discussion)
Make Your React Native Apps Accessible (Ankita Kulkarni)
Native Web Apps: React and WebAssembly to Rewrite Native Apps (Florian Rival)
Full-Stack React Native in the Era of Serverless Computing (Nader Dabit)
Demystifying The Complex Animations Creation Process in React Native (Vladimir Novick)
React Native App Rollout - an Alternative Approach (Adam Terlson)

Open Source Awards

Since React Amsterdam at heart is a JavaScript conference, a love for open source is at the heart of every conference run by GitNation, they really do a great job of highlighting and recognizing great open source projects. This year they had several categories and you can watch the awards ceremony for more context.

Breakthrough of The Year

Taken home by Michel Weststrate a Nederlander and main contributor of Immer the popular open source library used to create the next mutatable state by mutating the current state. I have just barely scraped the surface of what this library can help with, but I have used it to make returning state from my reducers in React used to mutate (while keeping immutable) my local component state. I'm sure there are many other great uses for this library and I think it was well deserving of the award. Nominees for this award were Linaria, Formik and React-navigation.

Most Exciting Technology

This award was given to the VX open source library that makes it easy to combine D3 charts into React to build amazing visual components. A demo can be seen on vx-demo.now.sh and shows how easy it is to make both your own reusable chart library or your own slick custom one-off charts. A representative was not available to take t his award home, but many props go out to the VX team for making such an amazing contribution to JS open source.

Fun Side Project of The Year

The title of the award says it all, this is just an open source contribution that GitNation believed to be fun, light-hearted and amazing in its own right. The nominees for this category were React95 (a play on Windows 95) is a React component library with Windows95 style UI. This would have also been my pick although I think both projects are absolutely fantastic. The next nominee was React-insta-stories A React component for Instagram like stories. The component responds to actions like a tap on the right side for the next story, on left for previous and tap and hold for pause. The custom time duration for each story can be provided. The winner for this award was React95. Gabriel Daltoso and Alysson Dos Santos (São Paulo - Brazil) both came up on stage to accept this very well deserved award!

Most Impactful Contribution to The Community

The winner of this award was React-testing-library. Other nominees for this award were Detox and React-navigation, and Downshift and are all very impactful in our JS community. It should be and is noted by the announcers on stage that two of these libraries have the main contributor in common with Kent C Dodds. And if he wasn't given an award himself for most impactful and influential person to React Amsterdam, he should as well with a few other speakers who did both workshops and speaking at the conference, it just so happens that kent was able to pull off a trifecta in also winning an open source award, but there were many people wearing many hats speaking, volunteering, teaching workshops and overall just living and breathing this conference.

Productivity Booster

The final award category is all about being productive as a developer. The winner is near and dear to my heart as someone who loves to write in Markdown, I'm writing this article now in markdown using VS Code and I use Git to record my progress and iterations of each and every article I write for this blog. As well, I write many presentations and slide decks and love using markdown for those as well. As you can guess, the winner of this award went to MDX Deck and was accepted by Time Neutkens and delivered to Brent jackson. Other nominees for this category were Formik, React-cosmos, and React-table.

React is Amsterdam

Talk about how Amsterdam is a perfect city for JavaScript and more importantly React developers. Some of the sponsors at the vents were based in or had offices in Amsterdam or Netherlands. The city offers so much in historical, artistic, tech and shopping, so it's obviously a great place to bring the React community and is very relaxed yet highly invigorated at the same time. Given enough time and the ability to travel throughout the city and learn the Metro, Dutch national rail company NS (Nederlandse Spoorwegen) and the various other ferry and tram systems, you can easily move around to the areas that you want to visit and crank up the energy or turn it down by traveling just out of the city's center.

I stayed in the Wilbautstraat area just 4 stops off the metro from Central Station at a wonderful hotel that I talk about more in my Developers Guide to React Amsterdam.

React 2020

If you are planning on attending the React Amsterdam 2020 event, mark your calendars now, it will be April 16th and 17th. I know I'm missing other amazing things that happened, but hopefully, this can serve as a guide if you were not able to attend or maybe a tool you can use to convince your boss to go next year. If you do, stop by our booth and talk to me, I will definitely be going back in April of next year!

Why Blazor Grid Templates Will Make You Question Everything

Progress Telerik — Thu, 18 Apr 2019 11:30:00 +0000

With native components, the Telerik UI for Blazor Grid templates can fully utilize the the best features of Blazor to highly customize the user experience.

Using a template in an application implies that you're creating a custom experience for your user by leveraging a component or framework you're working with. Because the Telerik UI for Blazor components are native, built from the ground up using the Blazor framework, it can tap directly in to Blazor's best features. Grid component templates can fully utilize the HTML, Razor, and components to completely customize the user experience.

In this article we'll see an overview of what templates are available and simple use cases. We'll use these as building blocks to see just how dynamic a Blazor grid can be when using templates for advanced ideas like custom editors and master-detail views.

Template Types

There are currently three types of templates available for the Blazor grid: column Template, Editor Template, and Row Template. Each has very specific uses and are powerful tools for adapting the grid to your specific needs. Let's start with a quick introduction to each template type.

Column Template

By default, the grid renders the value of the field in the column exactly as it's provided from the data source. We can override this behavior by using a column Template which allows us to take control over the rendering of the object within the column. The Template provides the entire object currently bound to the row in which the column exists, and this object is the template's context. Through the Template we can apply custom formatting, insert additional HTML and images, and display Razor Components using any value from the context.

<TelerikGridColumn Field="@(nameof(SampleData.Name))" Title="Employee Name">
    <Template>
       Employee name is: @((context as SampleData).Name)
    </Template>
</TelerikGridColumn>

The column Template is visible when the current row is not in edit mode. To customize the grid's editing experience we'll use the EditorTemplate.

Editor Template

The EditorTemplate is a template that bound to the editing context. The EditorTemplate defines the inline template or component that will be rendered when the user is editing the field. Although the EditorTemplate acts much like the column Template, it is only shown when the given row is in edit mode.

<TelerikGridColumn Field=@nameof(Employee.VacationDays) Title="Position">
    <EditorTemplate>
        @{
            var employeeToUpdate = context as Employee;
<KendoNumericTextBox Decimals="1" Format="#.0 days" Max="15" Min="0" Step="0.5m" Value="@employeeToUpdate.VacationDays" />
        }
    </EditorTemplate>
</TelerikGridColumn>

The column and editor templates give excellent control over column rendering in the grid. For even more control we can choose to use a row template and completely customize the grid.

Row Template

Unlike the previously mentioned templates, the RowTemplate spans the entire grid for all columns. The row template allows you to define custom rendering for the entire <tr> element for each record. It can be convenient if you want to use templates for most or all of the columns, as it requires less markup than setting individual templates for many columns.

Since the template isn't bound to a specific column, it can use the Context attribute of the RowTemplate to set the name of the context variable. Its type is the model type to which the grid is bound.

<RowTemplate Context="employee">
    <td>
        <span>@employee.Id</span>
    </td>
    <td>
        Hired on: @(String.Format("{0:dd MMM yyyy}", employee.HireDate))
    </td>
</RowTemplate>
<TelerikGridColumns>
    <TelerikGridColumn Field=@nameof(SampleData.Name) Title="Employee Name" />
    <TelerikGridColumn Field=@nameof(SampleData.HireDate) Title="Hire Date" />
</TelerikGridColumns>

Using the three template types we can tackle a wide variety of requirements. Let's look at how flexible the Telerik UI for Blazor Grid can be - what we can accomplish might just surprise you.

Image Template

We'll begin with a simple yet common scenario, embedding an image in a grid column. Let's assume we have a list of users that we need to manage a broad range of details for. It be nice to associate a face with a name, and with a column template we can do just that. Using a column template we can use one or many values from the currently bound item's properties to generate an image element and display an image directly in the column. In this example we'll assume that our product's images are stored on the server with a relative path of /images/, and each image file name corresponds to the productId.

Let's begin without a template to see how the grid is structured without customization.

<TelerikGrid Data=@GridData Height="500">
    <TelerikGridColumns>
        <TelerikGridColumn Field=@nameof(Product.ProductName) Title="Product Name"/>
        <TelerikGridColumn Field=@nameof(Product.UnitPrice) Title="Unit Price"/>
    </TelerikGridColumns>
</TelerikGrid> 

@functions {
    public IEnumerable<Product> GridData { get; set; }

    protected override void OnInit() => GridData = ... //fetch data;
}

Here we have a basic two column grid with just a text display of each Product Name and Unit Price. Using a template we can transform the Product Name column to display an image alongside the product name.

To access the template, the Product Name column needs to have a TelerikGridColumn component with matching begin/end tags. Inside the component we'll add a Template component which will define our custom rendering. Inside of the template we have access to the context object, this is the current Product in scope. A simple cast of context as Product will give us access to the proper type.

<TelerikGridColumn Field=@nameof(Product.ProductName) Title="Product Name">
    <Template>
        @{
            var product = context as Product;
        }
    </Template>
</TelerikGridColumn>

Now that we have our current Product we can render it how we see fit within the column. Let's add an HTML <img tag and create a path from the ProductId property. We can apply CSS to the image using standard HTML markup class="rounded-circle". Also, since this is Razor, C# string literals are a valid way of formating the path src="@($"/images/{product.ProductId}.jpg")". We'll also display the Product Name property along side the image using simple markup.

<TelerikGrid Data=@GridData Height="500">
    <TelerikGridColumns>
        <TelerikGridColumn Field=@nameof(Product.ProductName) Title="Product Name">
            <Template>
                @{
                    var product = context as Product;
                    <img class="rounded-circle" src="@($"/images/{product.ProductId}.jpg")" />
                    <span>@product.ProductName</span>
                }
            </Template>
        </TelerikGridColumn>
        <TelerikGridColumn Field=@nameof(Product.UnitPrice) Title="Unit Price"/>
    </TelerikGridColumns>
</TelerikGrid> 

@functions ...

Because the underlying Razor Components framework supports templates and the Telerik UI for Blazor Grid is built using the framework's native architecture, the grid is a fully capable solution to many problems.

Custom Form

With templates we can fully utilize Blazor's framework features. Inside the template we can add components, logic, and even trigger events. In addition, templates aren't just scoped to the component they're contained in - we can access events and values outside of the template as well. This opens up new possibilities for creating a custom experience.

Let's assume we want to create a custom edit experience versus using one of the built in grid editors. This will give us full control over every aspect of the form. The challenge is getting the form to interact with the grid. To make a custom editor we'll need to select an item, place its properties on a form, and save/cancel changes. On the surface this might seem like a complex task, however the framework has extremely flexible data binding mechanics.

Identifying the currently selected object would provide most of what we need to accomplish the task since we can bind its properties directly to form elements. The grid's template gives us access to items that are bound to a grid row, all we'll need is a method of selecting the value and creating a reference to the object. Let's start by creating a placeholder for our object reference using a field named selectedProduct. To create an easy way of selecting a product, a column template with a button will suffice. When the button is clicked, we'll invoke an in-line function to set selectedProduct to the current context.

<TelerikGridColumn Field=@nameof(Product.ProductId) Title="Id">
    <Template>
        <TelerikButton Icon="edit" OnClick="@(_=> selectedProduct = (Product)context)">Edit</TelerikButton>
    </Template>
</TelerikGridColumn>

With the data referenced we can now add a form to display the information and provide save and cancel actions. The form will exist outside of the grid, since the object reference is now scoped to the page we can place the form anywhere outside the grid. The form can be hidden or shown based on if an item is selected using a standard Razor @if block.

@if (selectedProduct != null) {
...form
}

Saving and canceling the edit are also straightforward tasks now. We just need to create buttons with corresponding OnClick events. To cancel the edit, the selectedProduct reference is simply reset to null.

<TelerikGrid Data=@GridData Height=@Height Pageable="true" PageSize=@PageSize>
    <TelerikGridColumns>
        <TelerikGridColumn Field=@nameof(Product.ProductId) Title="Id">
            <Template>
                <TelerikButton Icon="edit" OnClick="@(_=> selectedProduct = (Product)context)">Edit</TelerikButton>
            </Template>
        </TelerikGridColumn>
        <TelerikGridColumn Field=@nameof(Product.ProductName) Title="Product Name" />
        <TelerikGridColumn Field=@nameof(Product.UnitPrice) Title="Unit Price" />
    </TelerikGridColumns>
</TelerikGrid>
<hr />
@if (selectedProduct != null)
{
    <div class="form-group ">
        <label class="control-label" for="productName">
            Product Name
        </label>
        <input class="form-control" bind="@selectedProduct.ProductName" id="name" name="name" type="text" />
    </div>
    <div class="form-group ">
        <label class="control-label" for="unitPrice">
            Unit Price
        </label>
        <input class="form-control" bind="@selectedProduct.UnitPrice" id="unitPrice" name="unitPrice" type="number" />
    </div>
    <div class="form-group">
        <div>
            <TelerikButton Icon="save" Class="k-primary" OnClick="@Save">Save</TelerikButton>
            <TelerikButton Icon="cancel" OnClick="@(_=> selectedProduct = null)">Cancel</TelerikButton>
        </div>
    </div>
}
@functions {
    ...
    Product selectedProduct;

    void Save()
    {
// save logic
        selectedProduct = null;
    }
}

With the ability to share state with other components on the page, the opportunities for template driven experiences are unlimited.

Master-Detail View

Using templates we can completely transform an entire grid row with custom HTML, Razor, and even components. In this next example we'll look at just how advanced we can get with templates by adding a Master-Detail view to a grid.

A likely scenario for any application is one where a data point has many properties with varying importance. Some of those properties should always be front and center, while others might be helpful to have just within reach. This is where a master-detail view can be quite handy. This type of view helps keep extended data out of view until it is requested by the user, while keeping critical data up front all of the time.

Using the RowTemplate we can define two different states for our row which can easily be toggled by a simple button click. We'll start with the default state which only displays two columns of data. This view is nicely tucked away in a custom component called ProductMasterTemplate and takes a parameter of Product to be displayed in a two column format.

<ProductMasterTemplate Product="@product" />

In addition, we'll use a more complex view to reveal all of the data for a given product in a list view. Once again, we'll encapsulate the view in custom component called ProductDetailTemplate.

<ProductDetailTemplate Product="@product"/>

Within each of these custom components are table data cells <td> that contain Razor code for displaying the properties of a given Product. The contents of the row template must be <td> elements and their number (or total colspan) must match the number of columns defined in the grid. Internally both templates contain markup similar to the following example.

<td>@Product.property</td>
<td colspan="2">
... some view logic
</td>

With the two states clearly defined as components we can focus on switching between the two. Let's begin by defining which item is selected by creating a variable where we can hold a reference to the selected product. As such, we'll name it SelectedProduct. To enable the user to toggle between views, we'll need a set of buttons to display for the user. To show the details we'll simply check the SelectedProduct to see if it matches the current item in the row. Since we're using Blazor, we can easily set the state of SelectedProduct directly in the event handler with an in-line function, OnClick="@(_=> SelectedProduct = ...)".

    <RowTemplate Context="product">
        @if (SelectedProduct != product)
        {
            <td>
                <TelerikButton Icon="@IconName.Window" OnClick="@(_=> SelectedProduct = product)">Details</TelerikButton>
            </td>
            <ProductMasterTemplate Product="@product" />
        }
        else
        {
            <td>
                <TelerikButton Icon="@IconName.Close" OnClick="@(_=> SelectedProduct = null)">Close</TelerikButton>
            </td>
            <ProductDetailTemplate Product="@product"/>
        }
    </RowTemplate>

The completed code below is actually quite simple due to the combination of template and component architecture.

<TelerikGrid Data=@GridData Height="@Height">
    <RowTemplate Context="product">
        @if (SelectedProduct != product)
        {
            <td>
                <TelerikButton Icon="@IconName.Window" OnClick="@(_=> SelectedProduct = product)">Details</TelerikButton>
            </td>
            <ProductMasterTemplate Product="@product" />
        }
        else
        {
            <td>
                <TelerikButton Icon="@IconName.Close" OnClick="@(_=> SelectedProduct = null)">Close</TelerikButton>
            </td>
            <ProductDetailTemplate Product="@product"/>
        }
    </RowTemplate>
    <TelerikGridColumns>
        <TelerikGridColumn Width="100" Field=@nameof(Product.ProductName) Title="Product" />
        <TelerikGridColumn Field=@nameof(Product.ProductName) Title="Product Name" />
        <TelerikGridColumn Field=@nameof(Product.UnitsInStock) Title="Unit Price" />
    </TelerikGridColumns>
</TelerikGrid>

@functions {
    Product SelectedProduct;
}

Clicking the Details button gives us a slick UI that allows us to drill into grid data.

Conclusion

Because the Telerik UI for Blazor components are native, built from the ground up using the Blazor framework, it can tap directly in to Blazor's best features. Grid component templates can fully utilize the HTML, Razor, and components to completely customize the user experience. Simple templates are useful for formatting or displaying images, while more extensive templates can transform the user interface completely adding entirely new functionality to the grid.

In this post we focused on the grid, however other components like the DropDownList already feature template fields as well. Make sure you download the latest release and try the templates for yourself using our demo repository on GitHub.

Try Telerik UI for Blazor

Meet the KendoReact Team in Person: Amsterdam, Paris, Salt Lake City

Progress Telerik — Wed, 10 Apr 2019 16:43:49 +0000

Behind every person, there’s a story, and we want to know yours! That’s why the KendoReact team is going traveling this year to meet with the React community. You can see which events we’ll be attending at the end of this article, but before that, let me share some of our stories with you, to kick off the conversation.

You may have seen Carl’s unmistakably Nordic beard at previous events, on Twitter, or on the Telerik Blogs as he’s been with KendoReact since its inception. Don’t ask him where he’s from unless you’ve got a coffee in your hand and a place to sit comfortably. On the other hand, being the KendoReact Product Manager, Carl has a lot to say about the team, how we build our roadmap and all about staying fit while balancing a heap of work responsibilities.

If you’ve looked for more information about React hooks, Eric’s name has probably showed up in your google search results as he did a popular series of articles diving into their intricacies. Beyond hooks, there’s a lot more to know about this React developer who came to Progress from Tesla, landing his first Developer Advocate role (at which he’s a natural!) and is miraculously always present at calls with the Sofia, Bulgaria team despite the 10-hour difference (he's based in California).

Then I also encourage you to ask Kiril about rebuilding of the previous version of our KendoReact website with Gatsby and what this architecture change did to the build time in production. Hint: he managed to decrease both the development and production build times 10x and made the site blazing fast. Yes, he has stories to tell.

And definitely turn to Stefan if you have a question about how a KendoReact component works – he’s our master solution-finder. He is also the one person on the team whom you can ask about all and any of the KendoReact UI components and get a pro tip. Since he’s one of the most active team members when it comes to answering support tickets, you may even have exchanged emails with him already!

Then there’s also me, Nora. Ask me about my favorite joke about functions if you want to lighten up – I laugh every time I tell it. I also have a lot of funny developer stories. Other than that, I’ve been working as a marketing person in IT for more years than you can tell and have a passion for communication, so ask me anything. Don’t worry, there’ll be no marketing talk if you approach me as I find it hard to be anything but straightforward (just ask the team).

There’s nothing that can substitute for in-person communication when it comes to building relationships or learning what someone is all about. That’s why the KendoReact team, represented by these fine folks just introduced, is going places this summer!

Come meet us at our booths at the following conferences:

React Amsterdam on April 10-12 in (duh) Amsterdam. We’ll be right by the coffee spot, Booth 1, and will be wearing React blue! Carl, who rarely misses a workout, will probably go for a run between the Dutch bikers while we’re there. Ping him if you’d like to boost your sense of well-being with a runner’s high. Also, we'll be having some cool gifts from you, from a raffle for Bose headphones, to T-shirts and more KendoReact sweetness.

React Europe on May 21-24 in Paris. Every time I think of Paris, I think of Alison Gopnik’s hilarious comparison, “What's it like to be a baby? Being in love in Paris for the first time after you've had 3 double espressos." I hope I get some new associations as it will be my first time ever in Paris!
React Loop on June 21 in Chicago. While we won’t be exhibiting there, make sure you attend Eric’s talk, as he is one of the speakers at Chicago’s first React conference.
React Rally on Aug 22-23 in Salt Lake City, UT. There are still a few months to go, but mark your calendar if you’re planning to be there and come meet the KendoReact team!

Looking forward to meeting you in person! If you want to suggest other React events for us to visit, drop us a line and we’ll check them out.

The Journey of JavaScript: from Downloading Scripts to Execution - Part I

Progress Telerik — Sun, 24 Feb 2019 14:30:00 +0000

This article will help you understand the internals of JavaScript - even the weird parts. Every line of code that you write in JavaScript will make complete sense once you know how it has been interpreted by the underlying engine. You'll learn multiple ways of downloading scripts based on the use case, and how the parser generates an Abstract Syntax Tree and its heuristics while parsing the code. Let's dive deep into the internals of JavaScript engines - starting from downloading scripts.

JavaScript is one of the most popular languages today. Gone are the days when people would use JavaScript merely for handling DOM event listeners and for a few undemanding tasks. Today, you can build an entire application from the ground up using JavaScript. JavaScript has taken over the winds, lands and the seas. With Node.js invading the gamut of server-side technologies and the advent of rich and powerful client-side libraries and frameworks like React, Angular and Vue, JavaScript has conquered the web. Applications are shipping a lot of JavaScript over the wires. Almost all of the complicated tasks of an application are now implemented using JavaScript.

While this is all great, it is disheartening to see that most of these applications lack even the minimal user experience. We keep adding functionalities to our application without taking into effect its performance implications. It is important that we follow proper techniques to deliver optimized code.

In this series of tutorials, we’ll first understand what is wrong with the conventional techniques and then we’ll dig deeper to learn some of the techniques that’ll help us write optimized code. We’ll also understand how our code gets parsed, interpreted and compiled by the underlying JavaScript engine and what works best for our engines. While the syntax of JavaScript is pretty easy to grasp, understanding its internals is a more daunting task. We’ll start from the very basics and eventually take over the beast. Let’s get going.

Understanding the Script Tag

Let’s consider a simple HTML file:

<!DOCTYPE html>
<html>
    <head>
        <script src='./js/first.js'></script>
        <script src='./js/second.js'></script>
        <script src='./js/third.js'></script>
        <script src='./js/fourth.js'></script>
    </head>
    <body>
        <div>Understanding the script tag</div>
    </body>
</html>

first.js includes the following code:

console.log('first.js file')

second.js includes the following code:

console.log('second.js file')

I’ve set up an express server for demonstrating the concepts explained in the article. If you want to experiment along the way, please feel free to clone my GitHub repository.

Let’s see what happens when we open this HTML file in the browser:

The browser starts parsing the HTML code. When it comes across a script tag in the head section, the HTML parsing is paused. An HTTP request is sent to the server to fetch the script. The browser waits until the entire script is downloaded. It then does the work of parsing, interpreting and executing the downloaded script (we’ll get into the details of the entire process later in the article). This happens for each of the four scripts.

Once this is done, the browser resumes its work of parsing HTML and creating DOM nodes. The user, who is patiently staring at the screen waiting for something to load, doesn’t know most of his time is spent executing JavaScript code (even the code that may not be required during the startup). Script tags are blocking in nature. They block the rendering of the DOM. Your high school teacher might have told you, “Always put the script tags below body.” Now that you know script tags block rendering of the DOM, it makes sense to put them below the HTML. It is better to show non-interactive content (for a few milliseconds until the JavaScript code gets ready) than nothing at all.

Imagine you have a very big chain of DOM nodes — tens of thousands of them. According to what we’ve learned so far, in this case, the user would see a lot of content but he won’t be able to interact even with the tiniest piece. I’m sure you have visited websites that show you the entire content almost instantly but don’t let you scroll down or even click on any element. The page doesn’t seem to move for a few seconds. Isn’t that frustrating? The next obvious question is: when should we load the scripts — at the start before parsing of HTML or at the end after the HTML? Let’s analyze the problem a bit more.

Our end goal is clear — to load assets instantly during the startup. Our first approach of parsing scripts first and then the HTML renders a good user experience, but it eats up a lot of the user’s time by showing him blank screen while the content is getting executed. The problem with this approach is that it gets worse with an increase in the number of scripts since waiting time (load time) is directly proportional to the number of scripts. For every script, we make a ride to the server and wait until it gets downloaded.

Can we dump all of the JavaScript code in one file? This would reduce the number of rides we make to the server. That would mean dumping tens of thousands of lines of JavaScript into one file. I’m definitely not going for this. This would mean compromising with my code ethics.

Heard of Gulp, webpack? They are nothing but module bundlers in simple terms. Module bundlers, eh? You write your JavaScript code in any number of files (as many modules as you wish). Module bundlers bundle all of your JavaScript files and static assets in one big chunk, and you can simply add this one big file in your HTML.

Certainly, we reduced the number of HTTP requests to the server. Are we not still downloading, parsing and executing the entire content? Can we do something about it? There’s something called as code splitting. With webpack, you can split your code into different bundles. Dump all the common code in one bundle (like Vendor.js, which has all the common libraries to be used across the project) and others that are specific to modules.

For example, let’s say you are building an eCommerce website. You have different modules for Store, Transactions History and Payment. It doesn’t make sense to load your payment-specific code on the store-specific page. Bundlers have solved our problem by making fewer HTTP requests to the server.

Now, let’s consider one use case here. I’ve added Google Analytics to gain insights into how users are interacting with my eCommerce website. Google Analytics script is not required during the startup. We may want to load the app-specific stuff first and then other secondary scripts.

Downloading Scripts Asynchronously

When you add the async keyword in your script tag, the browser downloads that script asynchronously. The browser doesn’t pause the parsing of DOM when it comes across a script tag with async keyword. The script is downloaded in another thread without disturbing the main thread, and, once it is downloaded, the browser pauses the parsing of HTML and gets busy in parsing this script code. Once the parsing of this JavaScript code is completed, it is executed in another thread and the browser resumes its work of parsing HTML. We’ve saved the waiting time of the browser while the script is getting downloaded.

Let’s say we want to download two of our scripts asynchronously:

<!DOCTYPE html>
<html>
    <head>
        <script async src='./js/first.js'></script>
        <script async src='./js/second.js'></script>
        <script src='./js/third.js'></script>
        <script src='./js/fourth.js'></script>
    </head>
    <body>
        <div>Understanding the script tag</div>
    </body>
</html>

Deferring the Execution of Scripts

When you add defer keyword in your script tag, the browser doesn’t execute that script until the HTML parsing is completed. Defer simply means the execution of the file is deferred or delayed. The script is downloaded in another thread and is executed only after the HTML parsing is completed.

<!DOCTYPE html>
<html>
    <head>
        <script defer src='./js/first.js'></script>
        <script defer src='./js/second.js'></script>
        <script src='./js/third.js'></script>
        <script src='./js/fourth.js'></script>
    </head>
    <body>
        <div>Understanding the script tag</div>
    </body>
</html>

As we can see in the above screenshot, third.js and fourth.js were executed before first.js and second.js.

Here’s a brief overview of the three techniques of adding scripts:

Until now, we’ve understood how scripts are downloaded and what the most effective ways of downloading scripts are. Let’s understand what happens after a script is downloaded. (We’re considering Chrome browser, although almost all of the popular browsers follow similar steps.)

Chrome uses V8 as the underlying JavaScript Engine. It consists of the following components.

Parser - JavaScript is fed into a Parser, which generates an Abstract Syntax Tree
Interpreter - Abstract Syntax Tree is the input for the V8 Ignition Interpreter, which generates the ByteCode
Compiler - The Turbofan Compiler of the V8 Engine takes in the ByteCode and generates machine code
Optimizing Compiler - It takes ByteCode and some profiling data as the input and generates optimized machine code

We’ll get into the details of each of these components.

Parsing JavaScript Code

The JavaScript source code is first converted to tokens. Tokens represent the alphabet of a language. Every unit in the source code is identified by the grammar of the language that you’re using.

So, something like var a = 1 is a valid JavaScript statement. It can be broken down to tokens (‘var’, ‘a’, ‘=’, ‘1’) that match with the language grammar. However, something like variable a = 2 is not a valid JavaScript statement because its grammar doesn’t specify anything related to the variable keyword. Now, with the help of these tokens, the parser generates an Abstract Syntax Tree (AST) and scopes. AST, in simple terms, is a data structure that is used for representing the source code. Scopes are also data structures, used for identifying the scope of variables in their defined blocks. For example, a local variable would be accessible in the local scope and not in global scope. These constraints are defined in these scopes data structures.

Consider this simple JavaScript code snippet -

var a = 2

I refer AST Explorer to check the AST generated for my code. The AST for the above code would look something like this:

{
  "type": "Program",
  "start": 0,
  "end": 9,
  "body": [
    {
      "type": "VariableDeclaration",
      "start": 0,
      "end": 9,
      "declarations": [
        {
          "type": "VariableDeclarator",
          "start": 4,
          "end": 9,
          "id": {
            "type": "Identifier",
            "start": 4,
            "end": 5,
            "name": "a"
          },
          "init": {
            "type": "Literal",
            "start": 8,
            "end": 9,
            "value": 2,
            "raw": "2"
          }
        }
      ],
      "kind": "var"
    }
  ],
  "sourceType": "module"
}

Let’s try to make sense of the above AST. It’s a JavaScript object with properties as type, start, end, body and sourceType. start is the index of the first character, and end is the length of your code, which is var a = 2 in this case. body contains the definition of the code. It’s an array with a single object since there is only one statement of the type VariableDeclaration in our program. Inside VariableDeclaration, it specifies the identifier a and its initial value as 2. Check id and init objects. The kind of declaration is var. It can also be let or const.

Let’s consider one more example to get better understanding of ASTs:

function foo () {
    let bar = 2
    return bar
}

And its AST is as follows -

{
  "type": "Program",
  "start": 0,
  "end": 50,
  "body": [
    {
      "type": "FunctionDeclaration",
      "start": 0,
      "end": 50,
      "id": {
        "type": "Identifier",
        "start": 9,
        "end": 12,
        "name": "foo"
      },
      "expression": false,
      "generator": false,
      "params": [],
      "body": {
        "type": "BlockStatement",
        "start": 16,
        "end": 50,
        "body": [
          {
            "type": "VariableDeclaration",
            "start": 22,
            "end": 33,
            "declarations": [
{
                "type": "VariableDeclarator",
                "start": 26,
                "end": 33,
                "id": {
                  "type": "Identifier",
                  "start": 26,
                  "end": 29,
                  "name": "bar"
                },
                "init": {
                  "type": "Literal",
                  "start": 32,
                  "end": 33,
                  "value": 2,
                  "raw": "2"
                }
}
            ],
            "kind": "let"
          },
          {
            "type": "ReturnStatement",
            "start": 38,
            "end": 48,
            "argument": {
"type": "Identifier",
"start": 45,
"end": 48,
"name": "bar"
            }
          }
        ]
      }
    }
  ],
  "sourceType": "module"
}

Again, it has properties — type, start, end, body and sourceType. start is 0, which means the first character is at position 0, and end is 50, which means the length of the code is 50. body is an array with one object of the type FunctionDeclaration. The name of the function foo is specified in the id object. This function doesn’t take any arguments hence params is an empty array. The body of the FunctionDeclaration is of type BlockStatement. BlockStatement identifies the scope of the function. The body of the BlockStatement has two objects for VariableDeclaration and ReturnStatement. VariableDeclaration is same as we saw in the previous example. ReturnStatement contains an argument with name bar, as bar is being returned by the function foo.

This is it. This is how ASTs are generated. When I heard of ASTs the first time, I thought of them as big scary trees with complicated nodes. But now that we’ve got a good hold on what ASTs are, don’t you think they are just a group of nicely designed nodes representing the semantics of a program?

Parser also takes care of Scopes.

let globalVar = 2
function foo () {
    let globalVar = 3
    console.log('globalVar', globalVar)
}

Function foo would print 3 and not 2 because the value of globalVar in its scope is 3. While parsing the JavaScript code, the parser generates its corresponding scopes as well.

When a globalVar is referred in function foo, we first look for globalVar in the functional scope. If that variable is not found in the functional scope, we look up to its parent, which in this case is the global object. Let’s consider one more example:

let globalVar = 2
function foo () {
    let localVar = 3
    console.log('localVar', localVar)
    console.log('globalVar', globalVar)
}
console.log('localVar', localVar)
console.log('globalVar', globalVar)

The console statements inside function foo would print 3 and 2 while the console statements outside function foo would print undefined and 3. This is because localVar is not accessible outside function foo. It is defined in the scope of function foo and so a lookup for localVar outside of it results in undefined.

Parsing in V8

V8 uses two parsers for parsing JavaScript code, called as Parser and Pre-Parser. To understand the need of two parsers, let’s consider the code below:

function foo () {
    console.log('I\'m inside function foo')
}

function bar () {
    console.log('I\'m inside function bar')
}

/* Calling function foo */
foo()

When the above code gets parsed, the parser would generate an AST representing the function foo and function bar. However, the function bar is not called anywhere in the program. We’re spending time in parsing and compiling functions that are not used, at least during the startup. bar may be called at a later stage, maybe on click of a button. But it is clearly not needed during the startup. Can we save this time by not compiling function bar during the startup? Yes, we can!

Parser is what we’re doing till now. It parses all of your code, builds ASTs, scopes and finds all the syntax errors. The Pre-Parser is like a fast parser. It only compiles what is needed and skips over the functions that are not called. It builds scopes but doesn’t build an AST. It finds only a restricted set of errors and is approximately twice as fast as the Parser. V8 employs a heuristic approach to determine the parsing technique at runtime.

Let’s consider one example to understand how V8 parses JavaScript code:

(function foo () {
    console.log('I\'m an IIFE function')

    function bar () {
        console.log('I\'m an inner function inside IIFE')
    }

})()

When the parser comes across the opening parenthesis, it understands that this is an IIFE and it would be called immediately, so it parses the foo function using full parser or eager parser. Inside foo, when it comes across the function bar, it lazily parses or pre-parses the function bar because, based on its heuristics, it knows that the function bar won’t be called immediately. As the function foo is fully parsed, V8 builds its AST as well as scopes while it doesn’t build an AST for function bar. It builds only scopes for function bar.

Have you encountered this situation ever while writing JavaScript code:

The code throws an error only when you call the function fnClickListener. This is because V8 doesn’t parse this function on the first load. It parses the function fnClickListener only when you call it.

Let’s consider a few more examples to better understand the heuristics followed by V8.

function toBeCalled() {}
toBeCalled()

The function toBeCalled is lazily parsed by the V8 engine. When it encounters the call to function toBeCalled, it now uses a full parser to parse it completely. The time spent in lazily parsing the function toBeCalled is actually wasted time. While V8 is lazily parsing function toBeCalled, it doesn’t know that the immediate statement would be a call to this function. To avoid this, you can tell V8 which functions are to be eagerly-parsed (fully-parsed).

(function toBeCalled () {})
toBeCalled()

Wrapping a function in parentheses is an indicator to V8 that this function is to be eagerly-parsed. You can also add an exclamation mark before the function declaration to tell V8 to eagerly-parse that function.

!function toBeCalled () {}
toBeCalled()

Parsing of Inner Functions

function outer () {
    function inner () {}
}

In this case, V8 lazily parses both the functions, outer and inner. When we call outer, the outer function is eagerly/fully-parsed and inner function is again lazily parsed. This means inner function is lazily parsed twice. It gets even worse when functions are heavily nested.

function outer () {
    function inner () {
        function insideInner () {}
    }
    return inner
}

Initially, all the three functions outer, inner and insideInner are lazily parsed.

let innerFn = outer()
innerFn()

When we call function outer, it is fully-parsed and functions inner and insideInner are lazily parsed. Now, when we call inner, inner is fully parsed and insideInner is lazily parsed. That makes insideInner get parsed thrice. Don’t use nested functions when they are not required. Use nested functions appropriately!

Parsing of Closures

(function outer () {
    let a = 2
    let b = 3
    function inner () {
        return a
    }
    return inner
})

In the above code snippet, since the function outer is wrapped in parentheses, it is eagerly parsed. Function inner is lazily parsed. inner returns variable a, which is in the scope of its outer function. This is a valid case for closure.

let innerFn = outer()
innerFn()

innerFn very well returns a value of 2 since it has access to variable a of its parent scope. While parsing the function inner, when V8 comes across the variable a, it looks up for variable a in the context of inner function. Since a is not present in the scope of inner, it checks it in the scope of function outer. V8 understands that the variable a is to be saved in the function context and is to be preserved even after outer function has completed its execution. So, variable a is stored in the function context of outer and is preserved until its dependent function inner has completed execution. Please note, variable b is not preserved in this case as it is not used in any of the inner functions.

When we call function innerFn, the value of a is not found in the call stack, we then look up for its value in the function context. Lookups in function context are costly as compared to lookups in the call stack.

Let’s check the parsed code generated by V8.

function fnCalled () {
    console.log('Inside fnCalled')
}

function fnNotCalled () {
    console.log('Inside fnNotCalled')
}

fnCalled()

As per our understanding, both of these functions will be lazily parsed and when we make a function call to fnCalled, it would be fully parsed and print Inside fnCalled. Let’s see this in action. Run the file containing the above code as node --trace_parse parse.js. If you’ve cloned my GitHub repository, you’ll find this file under public/js folder. parse.js is the name of the file, and --trace_parse serves as an indicator to the runtime of nodejs to print the parsed output. This command would generate a dump of parsing logs. I’ll save the output of this command in a file parsedOutput.txt. For now, all that makes sense is the below screenshot of the dump.

Function fnCalled is parsed, but function fnNotCalled is not parsed. Try searching for fnNotCalled in the dump.

Script Streaming

Now that we know how parsing works in V8, let’s understand one concept related to Script Streaming. Script Streaming is effective from Chrome version 41.

From what we’ve learned till now, we know it’s the main thread that parses the JavaScript code (even with async and defer keywords). With Script Streaming in place, now the parsing can happen in another thread. While the script is still getting downloaded by the main thread, the parser thread can start parsing the script. This means that the parsing would be completed in line with the download. This technique proves very helpful for large scripts and slow network connections. Check out the below image to understand how the browser operates with Script Streaming and without Script Streaming.

In this tutorial, we learned multiple ways of downloading scripts based on the use case. We learned how the parser generates an Abstract Syntax Tree and its heuristics while parsing the code. Later in the article, we learned about Script Streaming. In the next article, we’ll learn how parsing code gets compiled by the V8 compiler.

For More on Building Apps with jQuery:

Want to learn more about creating great user interfaces with jQuery? Check out Kendo UI for jQuery - our complete UI component library that allows you to quickly build high-quality, responsive apps. It includes all the components you’ll need, from grids and charts to schedulers and dials.

Telerik UI for Blazor: Grid Component Basics

Progress Telerik — Tue, 19 Feb 2019 18:13:45 +0000

The Telerik UI for Blazor data grid features functionality like paging, sorting, templates, and themes out of the box. Learn how to get started with the grid's basic features today.

Telerik UI for Blazor is a brand new library of UI components for the Razor Components and Blazor frameworks. Even though Telerik UI for Blazor is in an "Early Preview" stage it ships with one of the most popular and versatile UI components, the data grid. The data grid features out-of-the-box functionality like paging, sorting, templates, and themes. In this article we will focus how to get started with the grid's basic features.

Prerequisites

Since the ASP.NET Preview's are moving at a rapid place, it's best to update your bits. Make sure you're on the current version of Razor Components (server-side) and Blazor (client-side) since we'll be working with both. Detailed installation instructions for both frameworks can be found on the Blazor getting started page.

Also be sure that you have enabled the Telerik UI for Blazor free early preview. Even if you have previously enrolled in the preview you may need to revisit this page for the latest version to appear in your feed. With this free account you'll be able to add the Telerik NuGet Package Source.

Before we begin, you may wonder why the Kendo namespace appears when using Telerik UI for Blazor. That's because the Telerik UI for Blazor shares web resources (HTML & CSS) with our Kendo UI brand of components.

Installation

Installing Telerik UI for Blazor requires just a few simple steps. First we'll need to install the package binaries. We'll be using the Telerik NuGet Package Source to install the package. If you don't have the Telerik Package Source already please see the Prerequisites section above.

If you have multiple solutions in your project, install the package to the project which contains the "Pages" folder. These are the views for your application.

We can use the Package Manager dialog, command line, or directly edit the .csproj file of the application.

NuGet

Command line

$ dotnet add package Telerik.UI.for.Blazor

Edit .csproj

<PackageReference Include="Telerik.UI.for.Blazor" Version="0.2.0" />

Once the Telerik UI for Blazor package has been installed, we'll need to make a reference to the components in the package. This will act as a global using statement for our application. Open the root _ViewImports file and add the @addTagHelper *, Kendo.Blazor directive.

_ViewImports.cshtml

@addTagHelper *,Kendo.Blazor

We also need to register the the library with dependency injection. This will resolve any dependencies needed by the components. In the same solution, open the Startup class and register the AddKendoBlazor service.

services.AddKendoBlazor();

Next we'll need to add the CSS theme files to the application. At the time of writing Telerik UI for Blazor supports three of the Kendo UI themes: Default, Bootstrap 4, and Material Design.

If you have multiple solutions in your project, find the project which contains the "wwwroot" folder. These are the static resources for your application. In the root of the project, add a file named libman.json. LibMan is a client-side library manager built into Visual Stuido (with CLI support) that will fetch static resources and save them to your project.

Add the following configuration to your libman.json file. Save the file and all three component themes will be copied to your wwwroot folder.

{
  "version": "1.0",
  "defaultProvider": "unpkg",
  "libraries": [
    {
      "library": "@progress/kendo-theme-default@3.0.0",
      "destination": "wwwroot/css/kendo-themes/default",
      "files": [
        "dist/all.css"
      ]
    },
    {
      "library": "@progress/kendo-theme-bootstrap@3.0.0",
      "destination": "wwwroot/css/kendo-themes/bootstrap",
      "files": [
        "dist/all.css"
      ]
    },
    {
      "library": "@progress/kendo-theme-material@2.0.0",
      "destination": "wwwroot/css/kendo-themes/material",
      "files": [
        "dist/all.css"
      ]
    }
  ]
}

With the themes installed, reference the desired theme from your application's index.html file.

wwwroot/Index.html

<head>
    ...
    <!-- <link rel="stylesheet" href="/css/kendo-themes/material/dist/all.css" />
    <link rel="stylesheet" href="/css/kendo-themes/default/dist/all.css" /> -->
    <link rel="stylesheet" href="/css/kendo-themes/bootstrap/dist/all.css" />
</head>

That's it! Now we're ready to begin building Razor Components or Blazor applications using Telerik UI for Blazor.

The Grid Component

The The Telerik UI for Blazor KendoGrid (Grid) is a data grid component that is compatible with both Razor Components and client-side Blazor. Thanks to these new breakthrough frameworks, the Grid does not require any JavaScript. The grid component is simple to implement, yet has a robust set of features like data binding, paging, sorting and templates. In addition, Razor Components and Blazor offer unique capabilities for bringing data into the grid. Depending on the mode of operation the data source can pull directly from Entity Framework (Razor Components), or via remote HTTP request (Blazor).

The basic Grid is made up of a few components that define the grid and its columns. The grid itself and its columns have parameters which are used to enable/disable functionality.

<KendoGrid parameters...>
    <RowTemplate/>
    <KendoGridColumns>
       <KendoGridColumn parameters.../>
    </KendoGridColumns>
</KendoGrid>

Let's start with the basic properties and then we'll learn about the different data sources we can use.

Properties

Height

When the height of the Grid is set, it calculates the appropriate height of its scrollable data area, so that the sum of the header rows, filter row, data, footer, and pager is equal to the expected height of the component. If the height of the Grid is changed through code after it's created the Grid it recalculates the height of its data area.

In some special scenarios it is possible to set a height style to the scrollable data area of the Grid by external CSS, which is a div.k-grid-content element.

<KendoGrid Height=@Height ... >

Data

The Grid's data plays a central role in practically all web applications built with Telerik UI for Blazor. The Data parameter accepts any data source that implements the IEnumerable interface. The data may be supplied from sources such as Entity Framework, local arrays and lists, and remote sources like HTTP requests via HttpClient.

@inject WeatherForecastService ForecastService
<KendoGrid Data=@GridData ... >
    <KendoGridColumns>
    ...
    </KendoGridColumns>
</KendoGrid>

@functions {
    public IEnumerable<WeatherForecast> GridData { get; set; }
    protected override async Task OnInitAsync()
    {
        GridData = await ForecastService.GetForecastAsync(DateTime.Now);
    }
}

Columns

The KendoGridColumns component is the root level configuration of the grid columns. Nested beneath KendoGridColumns are individual KendoGridColumn components. These components are interpreted as column configurations where the Field parameter is a string to which the column is bound. The column will use the property name as the column header by default, but this can be explicitly set using the Title parameter. In the example below, the nameof operator is used to get the string representation of the ProductName property. Since we're dealing with C#, the nameof operator provides better tooling support for refactoring.

<KendoGrid parameters...>
     <KendoGridColumns>
       <KendoGridColumn Field=@nameof(Product.ProductName) Title="Product Name"/>

Sortable

To enable sorting on all Grid columns, simply set the Sortable parameter. When the Sortable parameter is set to true, users can easily click the column headers to change how the data is sorted in the Grid.

<KendoGrid Sortable=bool parameters...>

Paging

With the Grid we have full control over the Pager. The pager can be enabled/disabled through the Pageable parameter. We can also define a PageSize and set the initial Page value.

<KendoGrid Pageable=bool PageSize=int Page=int parameters...>`

Templates

When we would like more flexibility in how our data is displayed, we can tap into the template features of the Grid. Within any column we can simply open a Template component and access an object reference to the current item bound to a given row. The Template content can contain HTML markup, Razor code, or even other Components.

<KendoGrid Data=@GridData>
    <KendoGridColumns>
        <KendoGridColumn Field=@nameof(Product.ProductId) Title="Id"/>
        <KendoGridColumn Field=@nameof(Product.ProductName) Title="Product Name"/>
        <KendoGridColumn Field=@nameof(Product.UnitPrice) Title="Unit Price">
            <Template>
                @(String.Format("{0:C2}", (context as Product).UnitPrice))
            </Template>
        </KendoGridColumn>
    </KendoGridColumns>
</KendoGrid>

@functions {
    public IEnumerable<Product> GridData { get; set; }

    protected override async Task OnInitAsync()
    {
        GridData = await nwContext.Products.ToListAsync();
    }
}

Getting Data

Because the Grid uses the IEnumerable interface for its data source, it has very flexible data binding. Depending on what context your application runs in, either Razor Components (server-side) or Blazor (client-side), you may have different requirements for connecting to data. Let's look at how dependency injection helps connect our Grid to a data source.

Razor Components (server-side operation)

Since Razor Components run in the context of the server, we can connect to directly to data through Entity Framework. One of the benefits to working with Razor Components is that our application doesn't need to create an HTTP request to connect to data.

We'll be using dependency injection to reference an instance of our database context, so we will need to register our service on startup. In the ConfigureServices method of the Startup class:

public void ConfigureServices(IServiceCollection services)
{
    var connection = "my-connection-string";
    var options = new DbContextOptionsBuilder<NorthwindContext>()
                        .UseSqlServer(connection)
                        .Options;
    services.AddSingleton(new NorthwindContext(options));
    ...
}

With our DbContext registered with dependency injection we can now inject the context on our page using the @inject directive. Inject will resolve a reference to an instance of the NorthwindContext and assign it to the nwContext variable. When the page initializes we call ToListAsync on the Products data set and update the GridData property with the results. Since the GridData property is bound to the Grid it will update when OnInitAsync completes.

@using TelerikBlazor.App.Models // Product is defined here
@inject NorthwindContext nwContext

<KendoGrid Data=@GridData>
    <KendoGridColumns>
        <KendoGridColumn Field=@nameof(Product.ProductId) Title="Id"/>
        <KendoGridColumn Field=@nameof(Product.ProductName) Title="Product Name"/>
        <KendoGridColumn Field=@nameof(Product.UnitPrice) Title="Unit Price">
            <Template>
                @(String.Format("{0:C2}", (context as Product).UnitPrice))
            </Template>
        </KendoGridColumn>
    </KendoGridColumns>
</KendoGrid>

@functions {
    public IEnumerable<Product> GridData { get; set; }
    int PageSize = 10;
    bool Pageable = false;
    bool Sortable = false;
    decimal Height = 400;

    protected override async Task OnInitAsync()
    {
        GridData = await nwContext.Products.ToListAsync();
    }
}

Now that we've seen how server-side operation works, let's take a look at using the Grid with Blazor.

Blazor (client-side operation)

Telerik UI for Blazor is compatible on the client, but currently has a known issue which requires disabling the Blazor IL Linker. Without digging into IL Linking too deep, the result of disabling it only results in a larger payload size. This is a temporary situation that will be resolved in later versions of the framework.

To disable IL Linker, open the .csproj file and add <BlazorLinkOnBuild>false</BlazorLinkOnBuild> to the top most property group.

  <PropertyGroup>
    ...
    <LangVersion>7.3</LangVersion>
    <!-- add the line below to disable IL Linker -->
    <BlazorLinkOnBuild>false</BlazorLinkOnBuild>
  </PropertyGroup>

Similar to server-side operation, we'll be using the @inject directive. On the client our app is disconnected from the database and we'll need to make an HTTP request for data. Instead of injecting our DbContext we will instead resolve an instance of HttpClient. When the page initializes we'll make an HTTP request using GetJsonAsync and update the GridData property with the results. Since the GridData property is bound to the Grid it will update when OnInitAsync completes.

@using WebApplication6.Shared // WeatherForecast is defined here
@inject HttpClient Http

<KendoGrid Data=@forecasts>
    <KendoGridColumns>
        <KendoGridColumn Field="@nameof(WeatherForecast.TemperatureC)" Title="Temp. ℃"/>
        <KendoGridColumn Field="@nameof(WeatherForecast.Summary)"/>
    </KendoGridColumns>
</KendoGrid>

@functions {
    WeatherForecast[] forecasts;

    protected override async Task OnInitAsync()
    {
        forecasts = await Http.GetJsonAsync<WeatherForecast[]>("api/SampleData/WeatherForecasts");
    }
}

The Grid works with both Razor Components and Blazor using the same markup. The only aspect of the code that changes is how the data is retrieved.

Wrapping Up

The Telerik UI for Blazor Early Preview kicked off with one of the most popular and powerful components, the Grid. We saw how the Grid can quickly make use of paging, sorting, templates, and themes. Leveraging the Razor Components or Blazor frameworks, we can fetch data directly from our database or HTTP and easily bind the data source.

We covered just the basic features of the Grid, but there's much more we can do with templates. In an upcoming article we'll take a closer look at row and column templates to see what is possible.

If you're ready to try Razor Components and Blazor then create an account for the Telerik UI for Blazor free early preview. Once you've signed up feel free to explore our extensive examples on GitHub, and happy coding.

Forem: Progress Telerik

Angular Basics: How To Get the Value of a Selected Dropdown Menu Item

Using the Change Event and Template Reference Variables

How Does It Work?

Using viewChild and Template Reference Variable

But How Does It Work?

Using NgModel Directive

How Does It Work?

Conclusion

Can We Make Open Source More Sustainable?

How did this happen?

Open source and economics

Solution 1: Foundations

Solution 2: Subscriptions

Solution 3: Paying for software

Wrapping up

How to Use the KendoReact Editor

Getting Started with the KendoReact Editor

How to Customize the React Text Editor's Built-In Tools

Using the Editor's Utility Functions for Generating Tools

Wrapping the Tool into a HOC

How to Implement Custom Tools into the KendoReact Editor

Why Sanitize Pasted Content?

Theming

Under the Hood

A Look Back at React Europe 2019 in Paris

Talks on YouTube

React Europe Conference Day One (May 23rd)

React Europe Conference Day Two (May 24th)

Hackathon

Web Accessibility for Developers: What It Is and Why It’s Important (Part I)

Introduction

Why Accessibility is Generally Neglected

Why Accessibility is Important

Ethics

Market

Legal

User Experience

Engineering

Reputation

SEO

Legislation

Conclusion

The Whole Series: What's to Come

Discovering React Hooks with KendoReact

Dealing with CORS in Create React App

The Problem

Automatic Proxying

Manual Proxying

Conclusion

Further Reading

A Look Back at React Amsterdam 2019

An Amazing Conference Location

Amazing Workshops Teaching Valuable Principles and Patterns

Conference Kickoff

Conference Talk Highlights

Requisite React (Kent C Dodds)

Refactoring React (Siddarth Kshetrapal)

A Common Design Language (Andrey Okonetchnikov)

Designing with React (Mark Dalgleish)

Server Side Rendering Talks

Lightning Round... One .. Start! (Read Rapidly and Fast)

Tech Regrets at Spectrum (Max Stoiber)

Scaling Applications with Microfrontends (Max Gallo)

Women of React Amsterdam

An SVG's Tale (Elizabet Oliveira)

The GraphQL Developer Experience (Peggy Rayzis)

Painting Pixels With WebGL And Hooks (Ashi Krishnan)

The React Native Track

Open Source Awards

Breakthrough of The Year

Most Exciting Technology

Fun Side Project of The Year

Most Impactful Contribution to The Community

Productivity Booster

React is Amsterdam

React 2020

Why Blazor Grid Templates Will Make You Question Everything

Template Types

Column Template