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

Under the hood, Visual Studio Code is a TypeScript application, which runs in the Electron runtime. This means that it is built on the open source Chromium browser engine that Microsoft’s Edge browser uses. Most importantly, it’s the same Webview UI control engine that’s a core component of the Windows App SDK, which allows you to run JavaScript and TypeScript code inside traditional Windows apps along with HTML and CSS (Cascading Style Sheets) markup. Confusing the two approaches is logical, and Microsoft is working on the Webview UI Toolkit To help bring Webview-based user experiences into VS Code.

Webview UI is an increasingly important tool, blending web tools with familiar Windows development environments. For example, you could write a management tool for a service that uses a Windows-style user interface, while serving the service’s web user interface output in the same framework. So, it’s not hard to see how a tool using Webview UI can work with VS Code, providing a Chromium-compliant environment for web-based interfaces and dashboards, at the same time that the hosting controls use the same design language as the rest of the editor without being constrained Windows system.

Although Microsoft recommends avoiding webviews in Visual Studio Code extensions unless you “absolutely need them,” they are becoming increasingly important. Visual Studio Code may have started as a tool for .NET systems software development and for general-purpose code editing, but it has grown into a near full IDE, with support for tools like Flutter that need a user interface design surface alongside code. We’ve seen Microsoft’s Browser Tools team extend the F12 developer tools into VS code, and use them to deliver debugging information.

What is in the Webview UI Toolkit?

Perhaps you can think of the Webview UI Toolkit as the Visual Studio code equivalent to the Windows App SDK’s WinUI 3 Component Library. WinUI 3 provides the same controls across different user interface frameworks, from the web to the PC. The Webview UI Toolkit takes a similar approach, offering a set of customizable controls that can give your extensions the same look and feel as the rest of VS Code. This way, if you’re providing information from another app, you won’t add cognitive deficits for users, ensuring that they stay in the same context as their code.

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

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

Offline Toolkit Available as a public preview on GitHub, with some significant issues that make it not quite ready for production. A release of 1.0 is planned for late 2022, so it’s worth starting to look at it even if you haven’t been ready to ship the code for quite some time.

Building a VS Code Extension based on Webview

Microsoft provides a range of Instructions for creating an extension based on Webview, along with a pre-generated sample code. It’s a lot like creating any other Visual Studio Code extension, at least during the initial setup. Here you can use Yeoman-based Extension Generator to prepare scaffolding for your extension. Don’t forget to install both Node.js and Git before using the generator, which then prompts you to answer some basic questions to define your TypeScript code scaffolding.

Once the extension scaffolding has been created by Yeoman, edit the code in the default extension to add a panel class, using the view that will be called by the extension’s activation function. The Panel class is where your Webview code will be written, using VS Code APIs to manage the layout of panels within the VS Code framework. Your class will also need to clean up resources when users reject the Webview panel.

You can now start integrating Webview content into your addon, using the . extension _getWebViewContent A way to host your HTML. This is where you load any JavaScript or CSS libraries your extension will need. Once you have a basic framework to run a Webview based extension, you can download and use the Webview UI Toolkit, and install it from npm in your extension’s directory. You can then add it to your extension by adding a set of new parameters to a file _getWebViewContent method, adding a call to the Visual Studio Code Webview libraries and extension URI. Remember to add these to any existing constructors or views if you are updating your existing extension code.

Consistent design for productivity and accessibility

Now that you have an extension with the WebView framework, you are ready to add references to the URIs toolkit in your HTML Webview, and load them as JavaScript modules. next one, Add Toolkit web components to your HTML. Although most of your code will be traditional like JavaScript and HTML, the Visual Studio Code Toolkit allows you to replace common HTML elements with components that are designed to take on the look and feel of the main VS Code application.

It’s important to note that Microsoft designed its components to be ARIA compatible, 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 areas, as well as check boxes and radio buttons. The other components are replacements for the familiar layout objects, the addition of a custom grid view for working with data, and new progress loops and dropdowns. The current version offers what you should see as only an initial set of components, with the potential to appear over the next few months. However, they will allow you to “Codify”, if desired, the web user interfaces of the current application ready for use within Visual Studio Code.

Using the Webview UI Toolkit will not change how extensions are written for Visual Studio Code. In fact, it may make it more difficult, as the architecture associated with its components may not be the same as you use elsewhere. But by giving VS Code extensions a consistent, objective set of accessible UI components, it will make your extensions more acceptable to users and help make them more productive. This is a win for all of us.

Copyright © 2021 IDG Communications, Inc.

Source link

Leave a Reply

Your email address will not be published.