Web components is a term that encompasses three new W3C standards. These three standards give us the ability to create custom elements.
The custom elements spec allows you to create new HTML tags that you can add to your page. They behave like any existing HTML Tag. To use this spec, you create a new ES6 class that inherits from an existing element. Then you can define what’s in that custom element and add it to your application as a new tag.
This term used to describe the virtual DOM used in React. Now it referrers to the ability to create an encapsulated DOM tree. This is used in conjunction with the custom elements spec to create components.
HTML templates allow you to create snippets of HTML with slots where you can add your own custom markup. This makes it easier to encapsulate boilerplate html and DRY up your code.
If you want to learn how to make a native web component, my favorite set of tutorials is on the Mozilla Developer Network.
I also built a few simple native web components that you can check out:
There are two popular ones out there. The first, and most popular, is Polymer. Polymer’s goal is to add a layer of syntactic sugar to the existing web components spec. Polymer also includes polyfills that allow you use your components across different web browsers. If you want to learn more, check out the Polymer Project.
The other library is Stencil.js. Stencil was built by the folks at Ionic. Ionic builds a popular mobile and Progressive Web Application (PWA) framework. Their existing method of using Angular was too slow for a modern PWA. To alleviate this problem, they moved to web components. They also built a library to help them along the way. Stencil makes use of TypeScript and TSX (TypeScript JSX) to build components in a way that feels familiar to folks using React or Angular. It takes the best concepts of Angular and React and combines them together.
I also have some Stencil demos available. I have a component library and I consume that library from a React application.
There are a couple of situations where web components are really helpful. The first is when you’re building component library for use in lots of different projects. This can include your own personal library of components, a core library of components for your company, or set public set of components. Companies that make component libraries, like Ionic or Telerik, have much to gain from web components.
The second situation is if you want to build a progressive web application. PWAs are rated on their “time to paint”, ie. how fast you can get content to show when you load the application. Applications that rely on frameworks can take up to several seconds to load. Web components load instantaneously. Even in my trivial demo code, there’s a noticeable different in a page built with web components and one built in React.
As we learn how to do more with web technologies, web standards evolve. Component based frameworks have become the dominant paradigm for building modern web apps. While component based frameworks like React and Angular are great, sometimes you don’t want or need the bulk. Web components combine several standards to build components using native browser technology. To make things easier, you can use libraries like Polymer and Stencil to help you out. Break free of framework churn by using the platform and building web components.
One of the great things about modern development is how easy you can leverage code written by others. Package managers like NPM and NuGet make this process even easier. The only problem is that there’s so much available code to choose from. For example, there’s over 100,000 packages on NuGet. In my travels as a .NET developer, I’ve found a few packages that made my life a little easier. Here’s a list of 10 handy packages you use in your next project:
Refit is a library that helps you automate calls to REST APIs. To use it, you first define your APIs as an annotated interface. Then you use Refit to turn that interface into a class. I love this package because it allows you to create incredibly terse API callers.
This package should be installed by default on any .NET API project. It automatically adds swagger documentation to your API. In addition to that, Swashbuckle creates a handy web page you can use to document and explore your API. I’m a big fan of this package because it links your docs with your actual code. It becomes even more important in a microservices environment where you have lots of services to keep track of.
Polly is a fault handling library that allows you to write more resilient code. To do this, you create policies. These policies define what happens when a particular operation fails. These policies include things like Retry, Circuit Breaker, and Fallback. It’s great for operations where there’s a chance of failure, like a REST call over a flaky network connection.
LINQ is my preferred way to deal with enumerable objects. MoreLINQ adds lots of useful operators to traditional LINQ.
Dapper is a Micro OR/M made by the same folks that gave us Stack Overflow. If you hate fiddling with Entity Framework configurations and just want to write some damn SQL, Dapper is for you. It’s been around for a while, but I’ve only recently gotten a chance to use on a project. After trying it, I’m a huge fan of this approach. I’ve spent way more hours than I’d care to admit trying to shoehorn Entity Framework’s API to get the data I want. I’ve also spent countless hours trying to figure out why my five lines of C# produced 3000+ lines of sketchy looking SQL. Sometimes it’s easier to do things yourself.
Generally, when you want to unit test an operation that interacts with the file system, you would need to write a separate interface and class to abstract away the IO operations. With Filesystem Abstractions, you no longer need to do that. Filesystem Abstractions wraps System.IO in a useful interface. Instead of making your own file system access class, you can inject an IFileSystem and get access to all of the IO methods you know and love. Filesystem Abstractions also includes classes to mock the file system, so testing IO operations becomes really easy.
Moq is a handy library for mocking interfaces in unit tests. You’re probably already using this one.
Xunit is a unit testing framework for testing .NET code. It’s like MSTest and NUnit, but it has a few interesting features. One of those is the use of theories. A theory allows you to run the same test with several different parameters. It’s a handy way to test multiple values without having to write multiple tests.
MiniProfiler injects a small unobtrusive profiler into your MVC application. As you complete operations, Miniprofiler will display the time it took to complete each step. Tools like this make it easy to diagnose performance bottlenecks.
The CSV helper makes it easy to create and read delimited files. If you work in an environment where you have to create or process lots of CSVs, this package is a good one to employ.
Like fashion, computing works in cycles. Things that were once looked at as passe come back with retro vengeance. For .NET development, the console is back. Consoles combined with lightweight editors like Visual Studio Code are becoming increasingly popular. Call me a hipster, but I’m all for this change. I hate waiting around for my editor and I never have to do that in a console or Visual Studio Code.
Unfortunately, if you’re living in the world of Windows, the default command line options are lacking. Not only are CMD and Powershell ugly, they lack basic usability features found in Linux and OSX. There is a better way. Cmder is a Windows console emulator that bundles several command line tools together into one fantastic package. It’s the Cadillac of Windows consoles.
Here’s what it looks like:
Cmder has a nice tabbed interface. You can run multiple consoles without having to deal with a bunch of windows. It also supports several different types of consoles including: CMD (enhanced with Clink), Powershell, and Bash.
You also get full control of the appearance of the shells including the font, color, etc… Cmder has many themes, but the default Monokai theme is good enough for me.
More importantly, you can create custom tasks. A custom task is a specific command window that you can define. You can specify the shell, what parameters it’s called with, and what directory is opened. You can have a command line setup for each application you work on. You no longer need to open a command line and manually navigate to your app folder each time you open up the console.
To make a custom task, do the following:
From Cmder, type Win + Alt + T. This takes you the tasks windows. You can also click the arrow next to the plus sign and click “Setup Tasks”.
This window allows you to reorder and reorganize the different defaults in Cmder. Hit the plus sign to add your own.
In this case, this is a console task that opens a specific project I’m working on.
After you setup your new task, click “Save Settings”. You should see your new shell in the list of available presets. Then you can open that exact shell whenever you want.
If you want to supercharge your Windows console, check out Cmder.