background

For front-end developers, scaffolding workflows are something they work with every day. That means that a stable, efficient, reliable workflow is critical to productivity.

Workflow migration within departmental groups has changed a lot over the years with the industry, so browse this article in detail.

LegoFlow is the closest thing we have to an ideal form of existing workflow exploration.

In June last year, the 1.0 version was released to the public. Although there was no open source, it also received a lot of feedback. Thank you very much for your support and affirmation.

2.0 making

Since then, we have been preparing for version 2.0. In fact, the biggest driving force has been the release of two big module updates, Webpack & Babel.

So 2.0 has built-in integration with relatively cutting-edge build tool modules like Webpack 4, Gulp 4, Babel 7, etc.

Today, version 2.0 is coming, and it’s very different from version 1.0:

1. The whole project is open source

We rewrote the entire structure of the project. Since Electron 1.8.4 integrates with node.js 8.x, some complex callbacks are nested and refactoring with async/await makes a lot of code easier to read.

In addition, with the increase of Electron usage, more modules and loaders try to expose dependencies and avoid the built-in require fixed path. Thanks to this, compared with 1.0, 2.0 reduces the behavior of hack rewriting dependent modules and rewriting dependent paths. Added to facilitate user understanding of the source code.

2. Webpack 4.5 & Babel 7

Updated the built-in Version of WebPack 4.5 to support a number of new features.

The upgrade also uses Babel 7, which is still in Beta, but some new features are really surprising, such as:

optional-chaining 

const obj = { x: 1 }; console.log( obj.x ); // 1 console.log( obj.y ); // undefined console.log( obj.x? .y ); // undefined console.log( obj.y? .x ); // undefinedCopy the code

Usage scenarios, client-side embedded page development often uses some client-side injected SDK methods, such as

window.SDK.alert( );
Copy the code

But in the debugging, away from the client environment, the SDK object should be injected can not be found, often occurs an error ‘SDK undefined’ interrupted the execution of the code.

This is definitely a bad experience, and it can be perfectly avoided for optional chaining by simply replacing the logic code with

window.SDK? .alert( );Copy the code

pipeline-operator 

function add ( x ) { return x + x; }
function double ( x ) { return x * 2; }

let x = 2
 |> add
 |> double
Copy the code

Other languages like Elm, OCaml, etc. can also support await to make “pipe” operations more semantic.

3. Provide CLI tools

Catching errors on the client side has always been a headache because it is roughly equivalent to a black box.

Once unexpected errors occur, it is difficult for the client to express complete error information, providing users with troubleshooting, and for users with strong power, the CLI is more suitable for use and expansion.

For one reason or another, we provide CLI tools.

When you find that the client can not meet the requirements, please try to use it, you will find a different use.

4. Better scalability

At the beginning of the refactoring, for better scalability, we isolated the core “workflow engine” as a common module for the client and CLI.

In other words, both the client and the CLI are “shells” of the upper layer, just sorting out the parameters and passing them on to the core workflow module.

This means that as long as you refer to the “engine”, the startup key is in your hand. If you don’t like the client or CLI provided, you can implement your own ideal appearance, and then simply introduce the startup of the core “engine”.

In addition, projects created by either the client or the CLI will run well on each other, i.e. projects created in version 2.0, regardless of which tool is created, will run on other tools.

This is why the “Project” module is separated out.

For the same reason, we have separated the “Config” module so that clients and the CLI can share the same common global Settings without having to re-configure them.

The fundamental reason for decoupling these modules is to enable the LegoFlow project to run generically across multiple tools and multiple ends.

So if you have a better idea, just include and use a tool built from the same three modules as above, and get the same effect as any other tool.

This not only unified the standard of the common form of the project, to achieve the standardization of the project within the group, and at the same time to give developers more free play space, to create their own ideal development tools.

The last

In the exploration of workflow this thing, spend a lot of effort to make the ideal and reality closer.

If you have a better idea or question, please submit PRs or Issues, thank you.