Whistle is a cross-platform Web debugging tool based on Node.js. Recently, with Nohost open source, many students have asked whistle-related questions. This article introduces how to use Whistle in local front-end project development with several common business scenarios.

A project using WebPack devServer

Project preparation

Today, most front-end projects are developed using WebPack as a development and build tool. We’ll show you how to use Whistle in combination with such a front-end project in the most common scenario, where a webpack starts up local devServer for development and debugging.

Let’s take a create-React-app project as an example. First, assume a new front-end project named my-app created with create-react-app:

create-react-app my-app
cd my-app
npm run start
Copy the code

A localhost:3000 TAB opens in the browser, which is a common scenario for local front-end development.

Disadvantages of local host

In general, we can do local debugging and development directly under localhost. However, local development based on localhost has a number of limitations:

  • Some functions related to user identity, such as login function, cookie reading, and so on, have restrictions on the domain name of the client. Using localhost may encounter restrictions.

  • For local development using localhost, some additional logical decisions may be required in the business code, such as behavior distinction between local and online domain names.

Configuration whistle

In order to solve the above problems, based on our practical experience, it seems to be a more efficient way to develop local front-end projects through online real domain names.

Assuming that the real online domain name of our local project is QQ.ketang.com, our goal is to access and debug the local my-APP front-end project through QQ.ketang.com.

We’ll show you how to use Whistle to do this.

1. Configure the whistle rule

Open the whsitle rule to configure the address 127.0.0.1:8899 and do the following in sequence:

-> Select the Rules TAB

-> Double-click to enable the Default configuration (if a green check box appears behind it, the Default configuration is successfully enabled)

-> Enter the following rules in the rule edit panel on the right

Qq.ketang.com/ http://127.0.0.1:3000/Copy the code

– > select Save

2. Enable proxy

Select the Proxy mode of the SwitchyOmega plug-in

Then, visit https://qq.ketang.com in your browser and successfully access our local my-app project.

Instead of using a local address like 127.0.0.1:3000, we can now debug our local project using the online address of the project.

What did Whislte do

This is where the configuration rules in Whislte come in

Qq.ketang.com/ http://127.0.0.1:3000/Copy the code

This rule forwards all requests from qq.ketang.com/ and its subpaths to http://127.0.0.1:3000/.

One of the great things about Whistle is that it provides rule matching of various patterns for different scenarios in front-end development. This is just the simplest rule.

If you want to get a fuller and clearer picture of whistle’s configuration rules now, check out the following links:

Whistle configuration mode

Pattern matching for the Whistle rule

Even if you haven’t read or understood whistle’s configuration rules properly, we’ll continue with this project and show you how to configure common Whislte rules in combination with a few common development scenarios.

Cgi interface forwarding under subpaths is ignored

In our my-app project, if the project involves the back-end interface of the sub-path of the same domain, such as qq.ketang.com/cgi-proxy/xxxxx, our original intention is that the CGI interface does not need to forward, but can still go online.

However, with the current configuration, the CGI interface will also be forwarded to the appropriate local path, which is obviously not what we want.

# bad, Isn't what we want # qq.ketang.com/cgi-proxy/xxxxx will be forwarded to http://127.0.0.1:3000/cgi-proxy/xxxx qq.ketang.com/ http://127.0.0.1:3000/Copy the code

Here the excludeFilter rule is required:

# good. Using the excludeFilter rule, Under the path matching # qq.ketang.com/cgi-proxy/ subpaths request will not be forwarded to http://127.0.0.1:3000/cgi-proxy/ qq.ketang.com/ http://127.0.0.1:3000/ excludeFilter://qq.ketang.com/cgi-proxy/Copy the code

In excludeFilter, we use path matching. In addition, we can use wildcard matching or regular matching to achieve this function:

# also good, using excludeFilter rule, wildcard matching # qq.ketang.com/cgi-proxy/, qq.ketang.com/cgi-bin/... Such requests are not forwarded qq.ketang.com/ http://127.0.0.1:3000/ excludeFilter://^qq.ketang.com/cgi-*Copy the code
# also good, using excludeFilter rules, matches with # qq.ketang.com/cgi-proxy/, qq.ketang.com/cgi-bin/... Qq.ketang.com/ http://127.0.0.1:3000/ excludeFilter:///^\ W + //qq\.ketang\.com/cgi-/ will not be forwardedCopy the code

The reason why // for qq is not escaped is that the whistle uses new RegExp to construct the whistle regular. If you are not sure, you can just write //qq.

Specific rules for pattern matching can be found in the official documentation:

Pattern matching for the Whistle rule

Mock for a specific CGI interface

A common scenario is that we need to modify the data returned from a CGI interface to simulate multiple cases on the front end, and Whistle can help developers do that in a number of ways.

Mock = /cgi-proxy/getMyName; mock = /cgi-proxy/getMyName

  • Respond with a local file
# qq.ketang.com/cgi-proxy/getMyName to local / / User/dug/test/getMyName json file as a response, qq.ketang.com/cgi-proxy/getMyName file:///User/dug/data/getMyName.jsonCopy the code
  • Edit the online file in response

If you don’t want to use a local file, you can also use the online text functionality provided by Whistle. On the Whislte configuration page:

– > select “Values”

-> Click “Create” and enter the custom file name (in this case ans.json)

-> Select the new file and enter the response content in the edit bar on the right

# qq.ketang.com/cgi-proxy/getMyName in response to ans.json in the Values panel qq.ketang.com/cgi-proxy/getMyName file://{ans.json}Copy the code
  • Use xfile mode

Xfile mode and file mode function is basically the same, the only difference between xfile and file is that file cannot find the corresponding file, return 404, while xfile continues to request online resources.

qq.ketang.com/cgi-proxy/getMyName xfile://{ans. Json}Copy the code

Traditional front-end projects with no build tools

Many old projects do not use build tools to build front-end JS, CSS and other front-end resources for various reasons. For this kind of project, we want to develop and debug with local corresponding resources.

For example, we need to iterate on an old project, whose online domain name is QQ.ketang.com. This modification mainly involves the following two files:

<! -- index.html --> ... <link rel="stylesheet" href="/assets/css/main.css" type="text/css"> ... <script src='assets/js/module/my.js'>Copy the code

In Whislte, we need to configure the rules:

# respectively online CSS and js access point to the native project path qq.ketang.com/assets/css/ xfile: / / / User/dug/myWork/ketang_pro/assets/CSS / qq.ketang.com/assets/js/ xfile:///User/dug/myWork/ketang_pro/assets/js/Copy the code

After that, we visit qq.ketang.com in the browser, where the requests under /assets/ CSS/and /assets/js/ will be responded with the corresponding files in the local project directory, and then we can modify and debug the project code locally.

3. Support special requirement scenarios with plug-ins

There are specific scenarios where whistle’s basic functionality might not be possible.

However, Whistle supports custom plugins to extend its functionality, and the community has an accumulation of plugins.

For example, suppose you have a COMBO URL request for http://i.cdn.com/??x.js,y.js,z.js in your project. Combo urls can be sliced into arrays [x.js, y.js, z.js] and grouped into http://i.cdn.com/x.js, http://i.cdn.com/y.js, http://i.cdn.com/z.js

See more about the plugin whistle.combo

whisle.combo

In addition, there’s a collection of Whistles plugins to find out if there’s one that meets your needs.

List of Whislte plug-ins


Scan code to pay attention to IMWeb front-end community public number, get the latest front-end good articles

Micro blog, nuggets, Github, Zhihu can search IMWeb or IMWeb team to follow us.