Using the Webview UI Toolkit for Visual Studio Code

0

Microsoft’s Visual Studio Code has become one of the most popular development tools. Blending proprietary Microsoft features with an extensible open source kernel, this is a quick install that can be configured to handle most languages ​​and most platforms. It is especially useful when working on multiple platforms, as its remote development extensions allow you to use it on another device from your desktop, be it macOS, Windows, or Linux.

Under the hood, Visual Studio Code is a TypeScript application, running in an Electron runtime environment. This means that it is built on the open source Chromium browser engine used by Microsoft’s own Edge browser. More importantly, it’s the same engine as the Webview UI control which is a key part of the Windows Application SDK, which allows you to run JavaScript and TypeScript code in your traditional Windows applications alongside HTML and CSS markup (cascading style sheets). Mixing the two approaches makes sense, and Microsoft is working on a Webview UI Toolkit to help integrate Webview-based user experiences into VS Code.

The Webview user interface is an increasingly important tool, as it mixes web tools with familiar Windows development environments. For example, you can write a management tool for a service that uses a Windows-style user interface, while rendering the service’s Web user interface output in the same frame. Thus, it is not difficult to see how a tool using the Webview user interface could work with VS Code, providing a Chromium-compatible environment for existing web interfaces and dashboards, while also hosting controls that use the same design language as the rest. from the editor without being linked to Windows.

Although Microsoft recommends avoiding web views in Visual Studio Code extensions, unless you “absolutely need them”, they are increasingly important. Visual Studio Code may have started out as a tool for developing .NET system programs and for editing general-purpose code, but it has grown close to a full-fledged IDE, with support for tools like that Flutter that need a UI design surface next to the code. We’ve even seen Microsoft’s own browser tools team extend the F12 developer tools into VS Code, using it to render debug information.

What does the Webview user interface toolkit contain?

Perhaps you can think of Webview UI Toolkit as the Visual Studio Code equivalent of the WinUI 3 component library of the Windows App SDK. WinUI 3 offers the same controls on different UI frameworks, from web to PC. The Webview UI Toolkit takes a similar approach, offering a set of customizable controls that can make your plugins look and feel the same as the rest of VS Code. That way, if you’re rendering information from another app, you won’t add cognitive deficit to users, ensuring they stay in the same context as their code.

The controls support the same theme model as the rest of the editor. If your user chooses a theme for the editor, your extension will automatically support it. As these are web components, you are not limited to a single set of development tools and can continue to develop extensions in your choice of web development frameworks.

With Visual Studio Code being used to host extensions from many different developers, supporting as many different languages, services, and servers as possible, it is essential that they all have a common design. Developers should ensure that the extensions they install work in and with VS Code, not loosely associate with them, and then apply their own standards. We need to know that the same editor shortcuts work on all extensions we have installed and that these extensions all behave consistently.

The toolkit is currently available as a public preview on GitHub, with a few significant issues that make it not quite production ready. A 1.0 version is slated for late 2022, so it’s worth starting to review it even if you won’t be ready to send code for some time.

Building a VS code extension based on Webview

Microsoft provides a set of instructions for creating an extension based on Webview, as well as sample pre-built code. It’s a bit like creating any other Visual Studio Code extension, at least during the initial setup. Here you use the Yeoman based extension builder to configure the scaffolding for your extension. Remember to install both Node.js and Git before using the generator, which then prompts you to answer a few basic questions to define your TypeScript code scaffolding.

Once the extension scaffolding is created by Yeoman, modify the code in the default extension to add a panel class, with a render method that will be called by the activate function of the extension. The panel class is where your Webview code will be written, using the VS Code APIs to manage the layout of the panels within the VS Code framework. Your class will also need to clean up resources when users close the Webview panel.

You can now start to embed the Webview content in your extension, using the _getWebViewContent method to host your HTML. This is where you load any JavaScript or CSS libraries that your extension will need. Once you have a basic framework for running a Webview-based extension, you can load and use the Webview UI Toolkit, installing it from npm into your extension’s directory. You can then add it to your extension by adding a set of new parameters to the _getWebViewContent method, adding a call to the Visual Studio Code Webview libraries and an extension URI. Remember to add them to any existing constructor or rendering method if you are updating the existing extension code.

Coherent design for productivity and accessibility

Now that you have an extension with a Webview framework, you are ready to add references to Toolbox URIs in your HTML Webview, loading them as JavaScript modules. Next, add the Toolbox web components to your HTML code. Although most of your code is traditional JavaScript and HTML, the Visual Studio Code Toolkit allows you to replace common HTML elements with components designed to match the appearance of the main VS Code application.

It’s important to note that Microsoft has designed its components to be ARIA compliant, with built-in keyboard navigation, giving you additional accessibility features without the need for additional code. These include common form elements, such as buttons and input boxes, as well as check boxes and radio buttons. Other components are alternatives to familiar layout objects, adding a custom grid view for working with data and new progress rings and drop-downs. The current version offers what you should see as an initial set of components, with more chances to come in the next few months. However, they will allow you to “codify”, if you want, your existing application web UIs ready for use in Visual Studio Code.

Using the Webview UI Toolkit will not change the way you write extensions for Visual Studio Code. In fact, it might make things more difficult, as the syntax associated with its components may not be the same as you use elsewhere. But giving VS Code extensions a cohesive and thematic set of accessible user interface components will make your extensions more acceptable to users and make them more productive. It is a victory for all of us.

Copyright © 2021 IDG Communications, Inc.


Source link

Share.

Comments are closed.