This article introduces a new front-end development tool that will hopefully make your front-end development experience look the same but not quite the same.

You might say, we’re all bald, mature front-end programmers, and every computer has a couple of buckets that we’ve worked so hard to build, so why do we need a new development tool?

Yeah, blind kid. You might have found the wah Point.

Count how many widgets and add-ons are currently installed on your computer for front-end local development. Just for the code development phase, there might be local servers, remote debugging tools, proxy tools, browser plug-ins, and so on. They may be you try countless the same model after the final decision to install, may also be a variety of “shocked! Super use front-end development tools daqo” Amway, and there are many global installation, global configuration of the “heavy tool”.

Imagine now that you need a new computer or new system, and you have to reinstall them one by one. Moreover, most of these tools cannot be configured independently from project to project, which means you will have to manually modify your development tool configuration as you switch from project to project. These are things that people with OBSessive-compulsive disorder, such as the author himself, cannot tolerate.

To summarize some common but troublesome scenarios in development at ordinary times:

  • You must manually install various tools to enrich your local development environment
  • Such native development environments are impossible to copy or difficult to copy and share
  • Each tool needs to be configured separately, and the configuration is not isolated by project. The configuration often needs to be modified when switching projects
  • Sometimes you don’t have the right tools to meet your needs, and writing your own is too cumbersome
  • Writing a project involves having N tools open at once: local servers, mock servers, and so on
  • It is often necessary to restart these tools repeatedly to refresh the configuration
  • …

Based on these and a few other pain points, you have server-X, which I’ll cover below.

What is a server – x

As the first half of its name, Server, you can simply say that Server-X (SVRX for short) is a local server, and it is a lightweight server that is feature-rich and easy to use.

Let’s start with the simplest usage scenario:

First you need to install the SVRX CLI tool,

npm install -g @svrx/cli
Copy the code

Then create a new simple page and start SVRX in the project root directory,

mkdir example && cd example
echo 'Hello svrx! ' > index.html
svrx
Copy the code

Visit http://localhost:8000 to see your front-end page.

Easy to install, quick to start, standalone, independent of any environment other than Node. Of course, this is the most essential feature that any standalone, basic Dev Server can do.

What else? SVRX also comes with very practical functions such as automatic browser opening, automatic refresh (livereload) for code changes, and proxy. Yes, you can also say that some Dev Servers can do this.

The biggest difference between SVRX and other local servers is the second half of its name server-x: x. As we all know, X stands for “unknown and infinite”, meaning that SVRX is a server with infinite possibilities. Why does it have infinite possibilities? Because the best thing about SVRX is that it’s a plug-in platform.

With plug-ins, your SVRX can theoretically have any functionality you want. Each small feature is a separate plug-in here, and you just need to declare it to use it, like this:

svrx --webpack --qrcode --markdown
Copy the code

It is very clear and intuitive, no redundant configuration, after you declare the plug-in, SVRX will automatically download and install the plug-in for you, and then directly boot.

So you could say that SVRX is a platform with so many plugins that it’s a bucket in itself. The difference is that you don’t need to care about the installation process. You don’t need to install anything other than the SVRX CLI.

In addition, all plug-ins are not installed globally, but directly into the node_modules directory of your project. So engineering development is really isolated, you can customize your development environment for each project, you don’t have to worry about installation and unloading, you don’t have to worry about environmental pollution, and you can keep the system clean.

In fact, there are many native Dev Servers currently available in the industry, but few are as lightweight and easy to use as SVRX, complete with plug-in mechanisms, and completely independent of the engineering environment. Next, we’ll explore the new experience of developing with SVRX by creating a simple front end project, taking you deep into some of the advanced uses and dark technologies that are really interesting about SVRX.

Create project and start

For convenience, we chose the Create React App that is commonly used on the front end to Create the sample project. (As mentioned earlier, SVRX does not depend on any engineering environment, so WE chose CRA for example convenience only.)

npm init react-app svrx-example
cd svrx-example
Copy the code

Since the new project uses webpack packaging by default, to start such a project we need to use the plugin svrx-plugin-webpack. This plugin reads the project configuration and calls Webpack-dev-Middleware so your WebPack project can be seamlessly plugged into the SVRX service.

However, since the new project does not expose webpack configuration items, we need to create a webpack.config.js in the root directory first:

// webpack.config.js
module.exports = require('react-scripts/config/webpack.config') ('development');
Copy the code

Then we can get the project off the ground:

svrx --webpack
Copy the code

The browser automatically displays http://localhost:8000/ :

Try editing SRC/app.css to see if the page changes in real time.

Step 1: Add configuration items

By default, SVRX automatically starts with built-in basic plug-ins such as Static server (serve), Proxy, and page refresh (livereload). They all have some default behavior to ensure that users can start SVRX quickly, of course, if you need to make some custom changes to these built-in configuration items, SVRX also provides two ways.

You can configure SVRX from the command line by passing in parameters:

svrx --port 3000 --https --no-livereload
Copy the code

You can also create a.svrxrc.js or svrx.config.js file in your project directory to persist the above command line arguments:

// .svrxrc.js
module.exports = {
  port: 3000.https: true.livereload: false
};
Copy the code

You can view all configuration items and descriptions of the SVRX in the official documentation – Built-in Items.

Step 2: Start experimenting with other plug-ins

In addition to the built-in plug-ins, SVRX also has a number of independent plug-ins, such as the aforementioned SVRX-plugin-webpack. When you need other development features (such as remote debugging, mocks, etc.), simply declare the name of these independent feature plug-ins in the SVRX configuration. It is these independent plug-ins that provide a rich functional experience for the SVRX project. Here are a few interesting plug-ins to use:

localtunnel- Exposing local services

Imagine you’re in the middle of an intense, orderly page development process when a message from your boss pops up:

Let me see what’s going on with your page

What do you do at this time? Do you have to check your progress, submit the working code, and then, on a whim, deploy a local service ready to dump your boss with a bunch of native IP’s? But then you remember, isn’t the leader on a business trip? (too dedicated, still checking your development progress) The leader can’t access the Intranet. At this time you can only hurriedly find a server to deploy a test environment to the leadership, deployment is also slow, the leadership of the plane to take off!

At this point, you need SVRX localTunnel plugin! It exposes your local services to localtunnel.me, making it easy to test and share native code. No longer do you need to deploy a test service to test a single change in your code.

To start localTunnel, simply add a declaration after the previous start command:

svrx --webpack --localtunnel
Copy the code

The command above will automatically install the localTunnel plugin and start SVRX, and other people (yes, you don’t even need to be on the same Intranet) will also see your local service when accessing the terminal printed https://*.localtunnel.me:

In addition, every change to your local page can be seen by others in real time, no longer have to worry about the boss suddenly check homework!

weinre- Remote debugging of mobile code

How do you debug mobile code these days? You might say, “I know this one!” It’s very simple, first open Developer mode on the phone (maybe look for it), allow USB connection, find a USB cable, connect the phone to the computer, then you open browser Developer tools on your computer, open something, go to the remote device, and Inspect…

What if there’s an easier way? Try SVRX’s Weinre plugin, which is “wireless” for easy remote debugging of mobile pages.

Let’s go back to the example project, this time adding two new plug-ins after the start command:

svrx --open=external --webpack --weinre --qrcode 
Copy the code

First, quickly install weinre and qrcode plug-in and start SVRX through the above command. At this time, try to access the launched project page with a mobile phone. It is recommended to use qrcode qrcode plug-in to easily scan the code to access the page address:

The computer then opens weinre’s debugger page http://${your_ip}:8001 (the default), finds the phone’s access history, and can debug the phone’s page remotely from the debugger.

Customize your plugin

In addition to the above, SVRX also has a lot of interesting plug-ins, you can check out all the current plug-ins on the SVRX website and choose from them. By combining different plug-ins, you can customize your development environment.

Of course, if you don’t find the feature you want, you can always try writing your own.

What can you do with plug-ins? Take the previous Qrcode TWO-DIMENSIONAL code plug-in for example, in order to display the two-dimensional code on the page, you can inject some JS scripts, CSS styles into the front page; You can also inject some KOA-style middleware into the back-end logic, like webPack plug-ins, to intercept requests for data processing, such as Webpack-dev-middleware.

With powerful front-end and back-end injection capabilities, almost any local development requirement can be solved by creating an SVRX plug-in. And plug-in development is surprisingly easy! Some of the plug-ins I’ve just introduced have only about 50 lines of core code! In addition, SVRX also provides scaffolding tools for quick plug-in creation. You can go to the official documentation – How to Write a Plug-in to see more details about plug-in development, which will not be covered here.

Step 3: Fast routes that can be hot updated

In development scenarios where the front end is separated from the back end, there are often situations where the front end needs to mock data. So you might experience:

  • Modify mock data and restart the mock server
  • Interface forwarding was enabled or disabled, and the interface was restarted
  • Modify the project code and restart
  • …

Even if you say that mock services are smart and don’t need to be restarted, you still need to manually start a mock service outside of the local service, or be more aggressive and write the mock data into the project code. It’s so inelegant!

This is where SVRX dynamic routing comes in. Yes, in addition to the rich plugin system, SVRX also has a powerful and easy to use dynamic routing function. Back to our example project, you can start a quick trial with the following command:

touch route.js # create empty routing file
svrx --webpack --route route.js
Copy the code

Js: in the route.

get('/blog').to.json({ title: 'svrx' });
Copy the code

Open /blog at this point and you’ll see json output for {title: ‘SVRX’}.

With this routing feature, you’ll be able to quickly and intuitively create your mock data without intruding into your project code. And it supports Hot Reload, that is, every time route.js is edited, the routing data is automatically updated without restarting the SVRX service.

Of course, SVRX routing can do a lot more than just develop data mocks locally. Here are some examples of routes:

get('/index.html').to.sendFile('./index.html');
get('/blog').to.redirect('/user');
get('/old/rewrite:path(.*)').to.rewrite('/svrx/{path}');
get('/api(.*)').to.proxy('http://mock.server.com/');
get('/blog')
  .to.header({ 'X-Engine': 'svrx' })
  .json({ code: 200 });
Copy the code

As you can see, SVRX’s routing syntax is very simple and you can read each rule clearly and intuitively, such as send file, redirect, route rewrite, proxy, and so on. In addition to the official routing operations, you can also extend routing operations through plug-ins. For details on SVRX routing syntax rules, extensions, etc., please refer to the official documentation – Use of Routing.

Write in the last

A progressive and easy to use, plug-in front-end development platform.

This is the SLOGAN of the SVRX, which also very accurately describes the SVRX’s positioning:

  • SVRX is a powerful local Dev Server for front-end developers. It consists of local services, proxies, livereload and other plug-ins
  • SVRX has a rich and powerful plugin system that you can use freely or customize as you want

While providing front-end developers with a more elegant and convenient native development experience, SVRX also provides a platform for rapid development of custom features. As a user, you can choose the right combination of plug-ins to meet your local service needs. One-click startup saves time and effort, easy to plug and plug function design, and do not worry about environmental pollution. If you can’t find the right plugin, you can become a self-sustaining developer and quickly implement the features you want. As a developer, you can also use your imagination to improve the local development experience of more people with the plug-ins you write.

After that, SVRX will continue to release more quality features or plug-ins to continue to serve the front-end development.

Links

  • SVRX official website official use documents, API, plug-in query
  • Github – SVRX core source code, discussion and exchange, bug report