DEV Community: 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.

New FREE Ebook: A Quick Guide to Expert .NET Reporting Tools

Progress Telerik — Tue, 30 Jun 2020 03:59:49 +0000

Visualizations have been helping people understand data for centuries. Clear and accurate reporting tools play a pivotal role in any business decision today and help companies digitize and streamline their reporting process.

Today’s data visualization tools, also called reporting tools, go beyond the standard charts and graphs used in the earlier periods. They can display data in more sophisticated ways such as infographics, dials and gauges, geographical maps, heat maps, and detailed bar, pie, and other charts. This is due to the advancement of digital information in today’s business environment.

Business processes and people are moving information at incredible speeds thanks to the adoption of digital information. This has forced businesses to adopt digital workflows to exchange information quickly. An example of this might be stock brokerage or bank transactions are done all digitally with the only bottleneck being data transfer rates.

An organization like a bank or an accounting firm or any other company which uses data for business decisions requires reporting tools that meet specific criteria to operate these high-end digital workflows. A proper reporting solution is of the utmost importance to ensure streamlined processes and accurate information is delivered.

Our guide to expert .NET reporting tools was just published and it is ready for FREE download.

In this ebook, Eric Rohler, Senior Technical Engineer at Progress, offers a six-step framework to help you choose the best reporting tool for your organization. He reviews the main functionalities of reporting solutions and shares best practices for everything you need to know to deliver beautiful, powerful, interactive and reusable reports.

Learn how to apply the top six criteria when assessing a reporting tool:

Presentation
Powerful
Productive
Pliable
Performant
Price

Deep dive in different stages of reporting—from report creation to styling to data sources to integration to rendering and accessibility. Take advantage of expert advice on successful integration between Reporting tools and web (Blazor, ASP.NET Core, ASP.NET MVC, ASP.NET WebForms, Angular, React and more) or desktop applications (WPF, WinForms, UWP) and many practical examples and use cases.

Download FREE Reporting Ebook

If you download the ebook, we’ll soon follow up with an invitation to a dedicated reporting webinar and more materials on the topic. Stay tuned!

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.

Web Accessibility Guidebook for Developers

Progress Telerik — Tue, 09 Jul 2019 18:24:37 +0000

Introduction to Accessibility

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 about both fundamental and advanced accessibility topics. With this article, our goal is to introduce fellow engineers, regardless of level, to web accessibility and share our practical knowledge and best practices.

By the W3C definition, 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.

One good example for accessibility is if you can use your site without looking at it. How would all the features and details you spent hours on developing work if you couldn’t use your eyesight to consume the content or use the mouse to interact with it? Imagine instead that you would need to listen to a screen reader that describes the UI and that navigation may not be through the traditional mouse or keyboard input.

Why Accessibility is Often Neglected

While there are many reasons why accessibility is not omnipresent, although ideally it should be, there are three reasons that stick out.

First, it’s hard to accommodate for something that you don’t understand well. Most of the time, it is not motivation that we lack, but rather education on how disabilities prevent people from interacting with our site. This includes lack of knowledge around what disability types exist and how to accommodate them. We just do not know the ins and outs of the problem.

Second, making your application accessible requires a lot of work. Starting from understanding the premises of the standards you need to follow all the way to designing the needed features and functionalities into your app. 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 article 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 minority 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. It’s far easier for a business to justify focusing effort on something that benefits the majority rather than serving a smaller subset of users with improvements that may feel like the application did not actually move forward.

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 1 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. We will come back to this as the next section focuses on this exact 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. It can also help create goodwill towards 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 across the globe 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 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 ensure that you accommodate any individuals with disabilities. This means your internal web tools will have to be accessible as well.

Additionally, 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. Progress has a detailed article on the topic for further reading, called “Accessibility and the Law.”

Types of Disabilities and Accessibility Best Practices

There are four major disability types - hearing , sight , motor and cognitive disabilities. Each type includes a multitude of conditions. They cause different challenges when interacting with the web and require different approaches to solve these challenges. Let’s explore some best practices addressing each separate type of disability. You will notice that most of these practices are not about the underlying technology we use but about how we design our software. This means that everyone involved in the development process can contribute to better accessibility.

Hearing (Auditory) Disabilities

Hearing disabilities range from mild hearing loss to deafness. The best way to help these users is to avoid relying only on sound to convey critical information. Instead, add another media in parallel for support. For example, if you use video, make sure it supports subtitles with full captions. If you use audio, provide a transcript. Subtitles and transcripts should be full and not miss critical lines. In a later paragraph, we will list guidelines for readability. They strongly apply to subtitles and transcripts. In addition to this, for both video and audio, make sure background noise is minimized, so that the conveyed information is as audible as possible.

Visual Disabilities - Low Vision

The primary way to accommodate for low vision is to have a readable interface. UI elements need to be big and clear. Text is more complex, though, and in a later paragraph, we will list guidelines for readability. They are designed to assist people with low vision.

Contrast is another important aspect. High contrast between elements and colors in the UI will help people with low vision. There are tools available that examine if contrast is sufficient for people with this condition. Here you can find the tools recommended by the Web Accessibility Initiative (WAI). In most page designs used nowadays, contrast is indeed problematic. Below is an example of a high contrast theme that complies with WCAG. Such high contrast will not work well with regular themes and you would probably prefer not to sacrifice the visual appeal of your site. A good compromise is to include a high-contrast theme as an option on your website, much like the option to change the language.

Visual Disabilities - Blindness

Blind people use screen readers. These applications parse the HTML and describe it to the user using natural language. Developing for screen readers has its specifics, so a later section in the article will focus exclusively on them. Additionally, the input device a user with blindness will work with will be different. Using a mouse requires sight. A blind person will need full keyboard support instead.

Visual Disabilities - Colorblindness

Colorblindness, too, is not a single condition - there are different types of colorblindness. Keep in mind that the following explanations are quite simplified. Deuteranomaly is the difficulty to perceive green light and is the most common. Having difficulty perceiving red light is called protanomaly and is a bit less common. The visible specters of these two conditions are somewhat similar and the conditions are more commonly known as red-green colorblindness. Tritanomaly is a problem with perception of blue colors and is very rare.

The severity of each condition also varies - they can range from a slight perception problem to full inability to perceive that color. We use the prefix -nomaly when the color perception is partially affected and – nopia when a color cannot be perceived at all. Achromatopsia is the condition of seeing everything in greyscale and is very rare. Changes in color perception do not affect a single color but the whole visible spectrum.

Your initial idea may be to pick colors that most people with colorblindness can see. This is not ideal because of the numerous variations of the disability, but orange and blue work ok in most cases. This is one of the reasons why the internet loves blue so much.

There are tools that simulate how your site looks when seen by colorblind people. You can use them to detect if there is a problem and then design and add optional themes for problematic types of the condition. This still requires your user to be able to find and switch to the respective theme.

Your most efficient solution is to not rely on color alone to convey critical information. You can design around the problem by using shapes, symbols, animation, and other creative means.

Motor Disabilities

Fast and/or repetitive actions, actions that require holding a button, actions with time limits - all of these are hard for people with motor disabilities and can cause physical pain. You need to avoid them, but it is not so simple. The following example illustrates why: imagine you have a slider that requires you to hold a button to move. Your solution may be to allow the slider to move by tapping a key, but if the step is too small, the result will be a repetitive action that is not much of an improvement. The general rule is that you need to design a website so a user would be able to conveniently use it both with a keyboard only and with a mouse only.

Cognitive Disabilities Related to Motion Sickness and Sensory Overload (Example - Epilepsy)

There are several patterns that can cause motion sickness or sensory overload. Usually these are rapid effects such as shaking, bright lights, quickly flashed (three times/second or faster). Repeating movement patterns, rapid or not, can cause the same issues. A good example for a repetitive but slow movement on a page is an animation of falling snowflakes, which we often see around the winter holidays. Sharp changes using flashy transitions in the contents on a page are also problematic; we need to use smooth transitions instead. A good practice is to avoid problematic effects, but if you want to use them, allow users to disable them as a compromise.

Cognitive Disabilities - Learning Difficulties

Simplicity is key. Make your scenarios simple, make your interface simple and free of clutter. Use simple language, avoid fancy words. Always provide clear instructions with concise information. The amount of information should follow the Goldilocks principle – too little will not be enough, but add too much and some users will get distracted. Avoid time limits that can put unnecessary pressure on the user.

Cognitive Disabilities - Dyslexia

Dyslexia is a type of disability that makes it difficult for some people to read: dyslexic people may confuse letters or see them rotated or crowded together. In the following paragraphs, we will list guidelines for readability. They strongly apply to addressing the challenges of dyslexia.

Tips on Readability

Good readability ensures your website will be accessible for a number of people with disabilities: readable subtitles and transcripts will be of help to people with hearing problems and readable text in general will be of help to people with low vision or dyslexia. A rule of thumb is to use simple and clean sans-serif font in a large font size.

Space matters. For example, long lines are hard to read, so apply a limit of 70 characters per line. For subtitles, the recommended limit is 35 characters. Provide enough space for characters to breathe - 1.5x line spacing is ok. On the topic of space, text in all capital letters is hard to read, so use mixed case. Reading speed also matters, so do not advance text automatically or in the case of subtitles - keep them on the screen for at least 0.3 seconds per word.

A key part of the puzzle is contrast. Background images usually obscure text. Good fonts have a border around the letters to enhance contrast, but it is even better to avoid background images altogether and provide a solid background that contrasts well with the text.

The IT industry has created awesome and free specialized fonts that are optimized for readability. You may consider some of them. Opendyslexic and Inter are good examples.

Introduction to Assistive Technology

Assistive technology is the industry term that includes all software and hardware designed to help people with disabilities. Input devices include mouth sticks, head wands, big trackballs, specialized keyboards, voice recognition software. Output devices include screen magnifiers, screen readers, braille displays, hearing aids, software with natural language interfaces and more. Some of these enhance an existing technology, others provide an alternative way to interact with a computer.

Most assistive technologies work on the level of the operating system and web developers do not need to do anything additional to enable them to function properly. However, with screen readers things tend to be a little more complicated. What screen readers do, in essence, is parse the HTML, then describe and explain it using natural language. The quality of that voice description depends directly on the quality of the code. So, naturally, screen readers are a primary concern for web developers working on making their websites more accessible. In the following paragraphs we will look at some of the best practices when optimizing our web assets for screen readers.

Optimizing for Screen Readers

Write Semantic HTML

The best practice to help screen readers do their job properly is to write semantic HTML – that is, to write valid HTML, follow best practices and use elements according to their intended purpose. For example, if something looks and behaves like a button, make it a button, not a

. If it is a heading, use the tags and not some inline CSS.

The formal definition of the semantics of html elements can be found in the living standard of HTML.

In real life, this is not so simple, of course. This brings us to the next sections.

Follow the Spec

As with any fundamental technology, the Internet has multiple standardizing bodies. The World Wide Web Consortium (W3C) is one of them and the Web Accessibility Initiative (WAI)) is part of it. We as developers need to follow the Web Content Accessibility Guidelines (WCAG), developed by WAI, which is the general standard for web accessibility.

The design practices we went over earlier when discussing the different types of disabilities are described in greater detail in WCAG. It’s important to note that WCAG is a living standard that is actively being improved. The most recent version as of the time of writing this resource is 2.1.

WAI developed the Web Accessibility Initiative - Accessible Rich Internet Applications Suite (WAI-ARIA),) the technical standard for how to write our code. We as developers need to follow this spec for screen readers to work properly. For brevity, in the next paragraphs I will refer to WCAG and WAI-ARIA as “the spec.”

Automated Testing

There are a variety of scanners that can automatically do checks covering many of the compliance rules that we are required to follow. For example, most automation software can easily scan for missing attributes and elements, check color contrasts or validate the HTML. A good practice is to do at least a quarterly scan of your site. And if you are really dedicated, you can include this step in your CI and CD process. Here is a list of good-quality scanners in no particular order:

Manual Testing

Unfortunately, automation can take just a small part of the big picture. If you want to achieve meaningful results, you have to manually test your site. The most practical way to perform such a test is to close your eyes and use only a keyboard and a screen reader to perform a variety of tasks on the website you’re reviewing.

Side-note: Personally, this is the point when I discovered how difficult accessibility testing really is.

Navigation

With your eyes closed, you cannot use a mouse. Keyboard navigation in the dark is much harder than with visual input. A lot of your solutions may not work as well as you had hoped once you stop seeing the screen. You will probably discover scenarios that you’ve missed accounting for. In short, offering good, working, keyboard navigation is very hard.

Auditory Complexity

The market provides multiple screen readers and they are usually very hard to understand. You may struggle to make sense of what you hear. The reason is that screen readers do not just read the screen using text-to-speech. Their task is harder: they need to describe the UI in enough detail so you understand its structure. Screen readers can be understood well only when you provide them with simple constructs in simple scenarios. So you need to work very hard to simplify the information architecture of your site.

Inconsistencies

Each screen reader has its own subtle interpretation of the spec and behaves slightly differently on each browser. You will encounter a lot of grey areas where following the spec is just not enough to make all screen readers provide meaningful output. In those cases, your implementation needs to make a compromise that works ok in most combinations of readers and browsers.

In our practice, we’ve discovered a few combinations that work well for testing purposes:

Jaws

Jaws is one of the oldest screen readers on the market. This means that it is one of the most popular tools out there. It has numerous users, so you need to make sure that your applications support it. But its age also means that Jaws needs to support a lot of legacy use cases. As a result, it is often not very compliant with the spec and difficult to work with. In our practice, we’ve found that Jaws works best with IE.

ChromeVox

ChromeVox is the newest reader (as of the time of writing this article) and, consequently, most compliant with the spec. Its young age means it is still not very popular. It works best on Chrome.

NVDA

NVDA is another new reader with good compliance with the spec. It is very popular and works best on Firefox.

Conclusion on Manual Testing

When a reader works well with a browser, this gives you some confidence that its users will use it primarily on that browser, though there are no rules and the possible scenarios are many. However, given that we usually work with limited resources, a good practice is to focus only on the popular combinations above and test often, instead of covering all possible combinations of readers and browsers, but doing it less often.

To back up our statements with data, here is a link to a reputable screen reader user survey that sheds light on user adoption of screen readers.

Third Party Testing is Last

It is advisable that you test with people with disabilities or get accessibility feedback from clients. The best practice is to do this only after you have done your homework with in-house manual and automated testing. It is our responsibility to first make sure their user experience is not completely broken. Only then will you be able to get meaningful feedback from your users.

Best Work Practices in Your Organization

Education

The first step in addressing any problem, is first to become aware of it. That’s why it is recommended that you invest in educating your team on the topic. Regardless of our motivation to do the right thing, unless we know what needs to be done to make a website more accessible, we won’t achieve progress in this area.

Additionally, accessibility is not a single person’s responsibility – everyone working on a web app, from engineers and designers to management, need to have it as a consideration. Educating and sharing knowledge with fellow engineers is also the primary motivation behind this article.

Documentation

As already discussed in previous parts, accessibility is not an exact science. You will often find yourself in a grey area without a clear solution in sight. The best practice in these situations is to document your approach. In that document, you may include the reasoning behind your current implementation and quote the WCAG rule(s) you’ve chosen to follow. This documentation will help your team to share knowledge and improve the consistency of your site and reduce the number of grey areas. Should you ever need to defend your decisions in court, having documentation can help defend your case.

KendoReact is one of a suite of JavaScript UI libraries called Kendo UI. At Progress, we share code and knowledge across teams to make sure when one team excels in something, the others will quickly get to the same level. Documentation is a very important part of how we share knowledge across teams when it comes to accessibility.

Usability and Accessibility are not the Same

Usability and accessibility have a lot in common. Most accessibility practices discussed in this article will benefit all users. But usability and accessibility are not the same. You may have invested heavily in usability, but that does not mean that you have automatically covered accessibility as well. Be aware that accessibility needs its own attention.

This is our recommended reading on usability:

The US government provides research-based web design and usability guidelines
“Humane Interface” by Jeff Raskin is considered a fundamental work on the topic
“Don't Make Me Think” by Steve Krug is a wonderful short book

As we have previously discussed, accessibility has multiple grey areas. Sometimes accessibility solutions may contradict usability solutions. The best practice in those cases is to not sacrifice usability, as it usually targets a larger number of users. Instead, we need to be creative and work around the problem.

Use Accessible Tools

Web accessibility is hard. A key way to achieve good results is to use accessible tools. For example, if you want a simple blog or website, WordPress will take care of accessibility for you. With our work on KendoReact library of UI components, we aim to help you in the same way. Our UI components are designed and built from the ground up with accessibility in mind, so you do not have to do most of the heavy lifting.

Recommended Resources

Below, you can find relevant and authoritative resources I recommend for further reading on the topic

Mozilla's explanation of WCAG
The a11y Project – a major community-driven hub with resources and tools
Free Accessibility course by Google
Testing tools suggested by WAI
AccessU is a reputed accessibility-focused summit
WebAIM (web accessibility in mind) – an organization that provides accessibility services such as training, evaluation and certification

Additionally, Progress has a whitepaper on accessibility that explores the domain in great detail, called Accessibility for Web Developers, which is free to download.

Conclusion

This is the finale of our article on web accessibility, summarizing the experience of the KendoReact team while working on the accessibility of our library of UI components for React. Our primary goal with this resource is to help build awareness on the topic. We hope that we have managed to convey how important accessibility is and have given you useful and practical ideas to efficiently tackle some of the challenges in building an accessible website. Please tell us about your experience with the topic in the comments below.

May the Force of Accessibility be with you.

Unleash the Power of the KendoReact DatePicker Component

Progress Telerik — Thu, 20 Jun 2019 16:04:28 +0000

The KendoReact DatePicker is a flexible React UI component that lets you customize every aspect of it with a custom renderer. In this blog post we cover how to customize the Calendar component of the DatePicker to highlight the US federal holiday schedule.

Let’s chat about dates in our React applications. Specifically, let’s chat about letting users select dates through a date picker. While there are a few choices out there, today we will be focusing on what is available in KendoReact, a set of UI components designed and built from the ground up for React. In the demo we will use in this blog, we'll explore what a React DatePicker component can do using the KendoReact DatePicker as an example.

Normally this component displays some sort of an input element, and when a user interacts with it, a calendar appears through a popup in order to help the user select a particular date. As a quick side-note, if you need to include a time selection, there exists the DateTimePicker component and for working with a range of dates, you have the DateRangePicker.

Beyond just selecting dates, a DatePicker can also be a great way to showcase available and unavailable days. It also can highlight certain dates so your users are aware that something special might be going on that day. I don’t know about you, but I constantly have to look up if a particular day is a US holiday or not, so why not create a React DatePicker that showcases the 2019 US holiday schedule? Since everyone loves emoji, why not replace the rendered dates with an applicable one ( )?

#1 - Understand the Flexibility of the KendoReact DatePicker

The KendoReact DatePicker is a React UI component that is extremely customizable. It allows the React developer to take full control over the look and feel of the component. It’s important to understand how this may differ from traditional configuration option customization. What is unique about this component is that it is composed of three parts and each of these parts can be completely overridden and passed custom a custom renderer, meaning a developer has full control over the component while still maintaining underlying functionality.

These parts are:

DateInput - the actual text box and input responsible for showcasing the date that was picked, or for displaying a mask when no input has been provided.
Popup - the part of the UI component that allows for a calendar to appear when clicking in the DateInput or on the DatePicker icon.
Calendar - the actual calendar that is displayed within the above-mentioned popup.

This means that every single element of the KendoReact DatePicker can be tailor-made while still retaining the great underlying functionality of the component!

Today, we’ll be focusing on the Calendar portion of the DatePicker, but what we learn can also be used to work with, and customize, the DateInput and Popup pieces of the DatePicker.

#2 - Creating our Custom Calendar

Defining our Data

First, let’s think about the data that we want to use. A simple search around the web will give us a list of all federal holidays (in the US) and the days they fall upon during the 2019 calendar year. With that in mind, it makes sense to create an array of these days, with the name of the holiday, the actual date , as well as our emoji of course!

const usHolidays = [
  { name: "New Year's Day", date: new Date("2019-01-01"), emoji: "" },
  { name: "Martin Luther King Day", date: new Date("2019-01-21"), emoji: "" },
  { name: "President's Day", date: new Date("2019-02-18"), emoji: "" },
  { name: "Memorial Day", date: new Date("2019-05-27"), emoji: "" },
  { name: "Independence Day", date: new Date("2019-07-04"), emoji: "" },
  { name: "Labor Day", date: new Date("2019-09-02"), emoji: "️" },
  { name: "Columbus Day", date: new Date("2019-10-14"), emoji: "" },
  { name: "Veterans Day", date: new Date("2019-11-11"), emoji: "️" },
  { name: "Thanksgiving Day", date: new Date("2019-11-28"), emoji: "" },
  { name: "Christmas Day", date: new Date("2019-12-25"), emoji: "" }
];

Working with the KendoReact Calendar

The KendoReact Calendar is a part of the KendoReact DateInputs npm package, which is the package that we will use to add the DatePicker to our app. For those of you worried about overall package size (since multiple components are in a single package sometimes): don’t worry, that’s where tree shaking comes in!

For these examples we are using the KendoReact Default theme, but the KendoReact Bootstrap theme and the KendoReact Material theme can also be used. In this scenario we are including a link to the compiled CSS file in the head tag of our index.html file, but following the documentation articles for any of the themes highlights how to include this as a part of our overall application bundle process if you prefer that instead.

The KendoReact Calendar documentation page provides the installation instructions for the Calendar component. Going through this we can then create our first React component that we will be building on top of for the this demo application.

import * as React from 'react';
import { Calendar } from '@progress/kendo-react-dateinputs';

export class CustomCalendar extends React.Component {
  render() {
    return (
      <Calendar />
    );
  }
}

Which will render the following on the page:

Creating Custom Cells in the KendoReact Calendar

It may be helpful to understand that the HTML for the KendoReact Calendar is a table element filled with td elements that represent each cell.

There are various ways to customize cells in the KendoReact Calendar, ranging from just adding additional information for each cell to completely taking over what is rendered in each cell. The latter is what we will be doing today. This means that in order to maintain the structure of the calendar whatever we return will need to be wrapped in a <td></td> element.

For this we should create a new React component, CustomCalendarCell and to make our life a little easier let’s start out with some boilerplate code:

export class CustomCalendarCell extends React.Component {
  handleClick = () => {
    this.props.onClick(this.props.value);
  }

  render() {
    // make weekends a bit opaque since a holiday calendar mostly focuses on what ADDITIONAL days we have off during the year (weekends are already off!)
    let style = {
        cursor: 'pointer',
        opacity: this.props.isWeekend ? .6 : 1
    };

    const className = classNames({
        'k-state-selected': this.props.isSelected,
        'k-state-focused': this.props.isFocused
    });

    return (
      <td
        onClick={this.handleClick}
        className={className}
        style={style}
      >
        <span className="k-link" title={this.props.isWeekend && this.title}>
          {this.props.children}
        </span>
      </td>
    );
  }
}

We can safely ignore style and className variables as they are only there to help with some styling options for our cells. style just makes weekend days a bit more faded (since we have those days off anyways) and className applies some KendoReact-specific CSS classes to the cells.

This piece of code may have stuck out:

handleClick = () => {
  this.props.onClick(this.props.value);
}

What we are doing here is working with the onClick() event that will be passed down from the Calendar component itself. This ensures that selecting our cell will properly highlight said cell in our Calendar and set the value of the Calendar to the selected day.

Everything else should be easy to follow. This will not change how the calendar renders normally (with the exceptions of the weekend days) so this is an excellent base to start from.

Let’s start making this calendar our own!

We already know the name and format of our data. So, let’s figure out how we can take this and check if the current date of the calendar cell is one of the holidays that we want to highlight. Something like this would work perfectly:

let emoji;

// find our holidays and assign the proper emoji - a simple for loop should do!
for (let i = 0; i < usHolidays.length; i++) {
  if (usHolidays[i].date.getUTCFullYear() == this.props.value.getUTCFullYear() && 
      usHolidays[i].date.getUTCMonth() == this.props.value.getUTCMonth() && 
      usHolidays[i].date.getUTCDate() == this.props.value.getUTCDate()) {
    emoji = usHolidays[i].emoji;
    style.backgroundColor = "rgba(255, 50, 85, 0.3)";
    this.title = usHolidays[i].name;
    break;
  };
}

What is happening here is that we create an emoji variable, which will be undefined if we are not on a holiday and will be assigned something if we have struck gold and have fallen on a holiday.

When it comes to comparing dates we’ll keep it simple and just compare the current year, month, and day for each date. The current day of our cell comes from this.props.value and is already in a date object, so we can just call getUTCFullYear(), getUTCMonth, and getUTCDate() to compare our two dates. We use the UTC variants here to avoid issues around time zones for our sample.

Once we have a match, we assign the holiday emoji to our emoji variable, update the style variable to have a background color (with 0.3 as opacity), and define the title of the day equal to the name of the holiday. On a regular day this would be written out like “Monday, June 10th, 2019” and will appear both when hovering over an item and be used for accessibility purposes.

We do have one last piece that we need to address, and that is how to use this match to update the cell content itself. This is done in the render() function when we call return. Right now we assume that we just have one type of cell, but what if we want to extend this to include a type for our emojis? Well, the easiest way would probably be to define a variable to represent our JSX outside of the return, which changes based on whether we have a normal day or one of our holidays.

let renderSpan;

if(emoji) {
  renderSpan = <span className="k-link" title={this.title}>{emoji}</span>;
}
else {
  renderSpan = <span className="k-link" title={this.props.title}>{this.props.children}</span>;
}
return (
  <td
    onClick={this.handleClick}
    className={className}
    style={style}
  >
    {renderSpan}
   </td>
);

As we see above, renderSpan becomes an important variable to ensure that we are rendering the correct content while still retaining many of the common props needed in the <td></td> element.

To take advantage of CustomCalendarCell we need to import it to our first component where we defined the calendar and define it as the cell renderer:

import * as React from 'react';
import { Calendar } from '@progress/kendo-react-dateinputs';
import { CustomCalendarCell } from './customCalendarCell.jsx';

export class CustomCalendar extends React.Component {
  render() {
    return (
      <Calendar
        cell={CustomCalendarCell}
        value={this.props.value}
        onChange={this.props.onChange}
      />
    );
  }
}

With all of this put together we can now navigate to any month with a holiday and see the fruits of our labor! Here’s January 2019 for example:

Note how hovering over the champagne bottle emoji gives us the “New Year’s Day” title!

Here is everything put together so far in a project on StackBlitz.

#3 - Adding our Custom Calendar to our React DatePicker

With the Calendar being customized the hard part is over. At this point we can take advantage of the KendoReact DatePicker customization options and simply pass in our CustomCalendar component.

Let’s update our main.jsx to import the DatePicker component and update the render() function to include the DatePicker.

import * as React from 'react';
import * as ReactDOM from 'react-dom';

import { DatePicker } from '@progress/kendo-react-dateinputs';
import { CustomCalendar } from './customCalendar.jsx';

class App extends React.Component {

  render() {
    return (
      <DatePicker
        onBlur={this.handleBlur}
        calendar={CustomCalendar}
      />
    );
  }
}
ReactDOM.render(
  <App />,
  document.querySelector('my-app')
);

It really is that simple: define the calendar prop of the DatePicker equal to our new CustomCalendar and we are already done!

A note here is that the usage of onBlur ensures that the proper propagation of the value changing will occur. So it’s just there to make the component works correctly even with our custom parts.

Like before, here’s the full project on StackBlitz.

#4 - Make Things Prettier with Tooltips

While the current titles that pop up is a nice feature, it doesn’t really fit with the rest of the look-and-feel of our application. This is where something like the KendoReact Tooltip comes to the rescue! We can use this to take the same titles but make them appear in a Tooltip that fits our overall theme instead.

As the KendoReact Tooltip demos showcases, normally this is done by just wrapping the element we want to tooltipify with the <Tooltip></Tooltip> tags, but because we’re dealing with a form of popup on top of a popup we need to do some slight tweaks to the way we add the component.

import * as React from 'react';
import * as ReactDOM from 'react-dom';

import { DatePicker } from '@progress/kendo-react-dateinputs';
import { Tooltip } from '@progress/kendo-react-tooltip';

import { CustomCalendar } from './customCalendar.jsx';

class App extends React.Component {
  tooltip = null;

  //we need to handle the blur event to ensure that mouseout causes tooltips to disappear
  handleBlur = (e) => {
    this.tooltip.handleMouseOut({clientX: 0, clientY: 0})
  }

  render() {
    return (
      <div
        onMouseOver={event => this.tooltip && this.tooltip.handleMouseOver(event)}
        onMouseOut={event => this.tooltip && this.tooltip.handleMouseOut(event)}
      >
        <DatePicker
          onBlur={this.handleBlur}
          calendar={CustomCalendar}
        />
        <Tooltip ref={(tooltip) => this.tooltip = tooltip} anchorElement="target" position="top" openDelay={300} />
      </div>
    );
  }
}
ReactDOM.render(
  <App />,
  document.querySelector('my-app')
);

Without getting in to specific detail here, the extra code that we have around onMouseOver and onMouseOut is there to help in scenarios where a Tooltip may linger when interacting with the Calendar and covers scenarios where it may not disappear upon selecting the date.

With a simple inclusion of the Tooltip and a couple of lines of code we now get the following view when highlighting a date in our custom date picker component.

The full project in action can be found right here.

This is Just the Beginning

As we highlighted in the beginning of the article, this is just a single part of the KendoReact DatePicker component that can be customized. We also stuck to the KendoReact family of UI components instead of adding in any other custom components or other 3rd party libraries, which is certainly possible. If you found the above deep-dive useful, or if you have a customization to a DatePicker somewhere in your application, feel free to comment and share your experiences in the comment section below!

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

Engineering

Reputation

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

SEO

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