The React Newsletter

In the early days of the internet, HTML forms were the first way of interacting with websites. The internet has come a long way since, but forms are still an essential component of any web application.

In React, you can validate forms in many different ways. There are some libraries out there that intend to make this task easier for you.

However, doing it yourself has a few advantages: You have control over the API layout, and since you probably don't need all the features that these libraries come with, you also save some bandwidth. More importantly, though, you get a deeper understanding of the mechanics behind some of these libraries.

In this tutorial, I want to show you how you can create a custom hook that you can use to validate all of your forms. The code for this doesn't need to be huge; in fact, the TypeScript version counts less than 100 lines.

The way I designed this hook fits my personal needs, but your mileage may vary. If you use a different implementation or have suggestions, please leave a comment, as I'm always looking for improvements.

While building taggr, I got deeper into TypeScript, and so far I am loving the added capabilities for annotating types and catching errors at compile time, instead off at runtime.

It can feel daunting and extra work to annotate each component and function at first, but as the codebase grows in size and complexity, the benefits start to shine.

Having the components and business-logic code properly typed, keeps a unique source of truth for the entities of a domain, minimizing the human errors across the application layers.

Plus, TypeScript definitions can be automatically generated from OpenAPI, GraphQL schemas… A total win-win 🎉

Meet the latest Gatsby

Ever since the very first version of Gatsby we’ve simplified the building of performant React sites for web developers. Optimized loading, prefetching, responsive images, accessible routing, webpack configuration – we made hard problems easier so you can focus on delivering the unique requirements of your website.

Then Gatsby v1.0 brought a unified data layer that simplified working with content from multiple CMS’s. Suddenly you were launching fast sites that could charm website users as well win over content editors. But we knew there was so much more speed to be captured. We did what we could with incremental improvements throughout v2, but achieving the speed we aimed for required a bigger, bolder move. It was time for Gatsby v3.

We believe that you should have a fast development experience, whether you’re working on your personal blog or a 10,000 page client site. And we believe it’s critical that your content editors and website visitors should have an equally great experience, too. A modern website framework should solve your team’s problems, not force you into unnecessary tradeoffs.

That’s why we focused on making Gatsby v3 faster in every way that matters, for everybody – web developers, content editors, and site visitors! Read more about our new features below.

Hello, everyone! A lot of e-ink has already been spilt on the relatively easier pickings of “Doing X in React” or “Using React with technology X”.

So instead, I want to talk about the experiences I've had building frontends from scratch at DelightChat and at my previous companies.

These projects require a deeper understanding of React and extended usage in a production setting.

Amazon Web Services has released AWS UI, which the cloud services biz describes as "the first step in a larger process of creating a new open source design system."

The context for this is the open-sourcing of the user interface code for the .NET Porting Assistant, a tool to scan Windows-only .NET Framework applications to discover what needs fixing in order to port them to .NET Core, the open-source version of .NET that runs on Linux.

AWS seems keen to persuade customers to move away from Windows, and referred in its post to the "performance, cost savings, and robust ecosystem of Linux."

Although the Porting Assistant for .NET was already open source, the code for the tool's user interface, which is built using React and Electron, was previously not available. React is a popular JavaScript framework originally developed by Facebook, and Electron is a project for building cross-platform desktop applications with JavaScript, HTML, and CSS.

Why not build a .NET porting tool with .NET? Since .NET Framework applications only run on Windows, you might wonder why AWS would not take advantage of the ability to run .NET Core code on the desktop using Windows Forms, Windows Presentation Foundation, or UWP. Although this is possible, AWS appears to be standardising on JavaScript/TypeScript and to some extent React for its cross-platform user interface components, getting the benefit of being able to share libraries between web and desktop.

• Redux & React For Everyone
• FullStack React with NextJS
• How To Make A GraphQL API
• Level 2 Meteor + React
• Pro Gatsby
• React For Everyone