Product | technology drops

The author | ays



Introduction: With the development of front-end technology, Web applications become complex. To solve the complexity of development, front-end development also has a modular concept. The use of Webpack to complete modular package build solutions is well known. But you can do much more with Webpack. This article takes advantage of Webpack’s characteristics to achieve customization requirements from a unique point of view, and hopefully gives you some inspiration.

▍background

When the project is delivered to the customer, customize the LOGO and login background of the product.

▍Simple analysis

Manually replacing image files for recompilation is definitely unacceptable.

I don’t think it’s realistic if you say you need to branch out. After all, this is not the use scenario for branching.

The project needs to avoid delivering code that contains resources and information from other customers at the time of delivery. This means that loading at run time through configuration files and so on is not feasible.

After all, the essence of the problem is that CSS can use the image files we specify when compiling the output of the project, and we need to automate this process.

▍The first option

Let’s start with a simple and straightforward solution: direct substitution. The steps are as follows:

  • Put the image resources into the specified directory, separated by project (client).

  • Executes the script to replace the image resource with the specified resource.

  • Execute the compile command for the project.



    Execute the script



It looks like our problem has been solved. However, if you think about it carefully, you will find that this scheme has several shortcomings:

  • It’s very invasive. Image resources in the directory are modified after each custom build, and these changes can be easily synchronized to the remote end.

  • Poor extensibility. Custom picture resources must be strictly in accordance with the source code of the convention, such as picture format, picture size. Each image needs to provide a corresponding slot in the code.

  • Single function. Only references to images can be modified, not when other styles need to be modified.

  • Poor experience. Split the build process into preparing static resources and compiling.

    ▍Second option

    Is there a better solution? Now we come back to the question: how to achieve the same project for different customers to customize the interface Logo and login background?

    What do we need to fix? CSS!

    If you want to modify CSS styles without modifying the source code, the only way to do that is to use the override rules that CSS styles have. The default styles are set in the source file, the CSS selector used by convention, the new style file is merged with the source file through compilation, and all styles are packaged for output.

    This approach has many benefits:

    • Weak invasiveness. Only the corresponding resources need to be maintained in the project repository, the source code is not affected, and the delivery does not contain redundant resources.

    • Strong expansibility. Custom image resources do not rely on source code, can use any image format.

    • Feature rich. Additional custom styles can be added, not limited to logos and backgrounds as required.

    • Experience is good. Load the specified style at compile time in one step.

      When it comes to front-end build packaging, Webpack comes to mind. You can start with Webpack Loader to implement the above process.

    ▍Webpack Loader

    In the Webpack ecosystem, Loader is used to convert the source code of a module. Loader allows you to preprocess files when importing or “loading” modules. As such, Loader is similar to “tasks” in other build tools and provides a powerful way to handle the front-end build steps. Loader can convert files from different languages (such as TypeScript) to JavaScript, or convert inline images to data urls.

    The preparation of Webpack Loader can refer to the official documentation, there is a very detailed description.

    Take a common Webpack configuration as an example:

    During the configuration, less files are compiled in the following order (the order of Webpack Loader) :



    Throughout the compilation process, we can merge our custom styles before and after each Loader, as shown below:



    It’s a good time to add custom CSS styles before less-loader, why? There are two things:

    • CSS and Less files are supported.

    • It is added before the entire compilation has started and has no effect on the entire compilation process. The new styles also enjoy the full compilation process.

    The compilation process is modified to look like the following figure:



    ▍Develop a merge-loader

    In the current scenario, merge-loader requires only one parameter: a custom style file path. So the Webpack configuration file can be modified to:

    You think this is the end of it? No, there are two problems with this logic that need to be optimized:

    • Concatenation of strings in source styles suffers from image path errors when there is a reference to an image in the style.

    • As soon as the file passes the match of the /\.less&/ rule, a merge operation is performed. Vue files with <style lang=”less”></style> will also trigger this rule (although repeated references do not add code).

    The solutions to these two problems are as follows:

    • Merge style files using @import “path/of/style”. Other processing is handed over to later loaders to ensure that the file and image paths are referenced correctly.

    • Add a target parameter that specifies a file as the object of the merge.

    Thus, the merge-loader logic is modified as follows:

    ▍Optimize the Loader

    Finally, the Loader tool library is used to optimize the code



    ▍The end of the

    The customization of the project has been completed with the help of the Webpack Loader. Several features of this scheme:

    • Weak invasiveness. Only the corresponding resources need to be maintained in the project repository, the source code is not affected, and the delivery does not contain redundant resources.

    • Strong expansibility. Custom image resources do not rely on source code, can use any image format.

    • Feature rich. Additional custom styles can be added, not limited to logos and backgrounds as required.

    • Experience is good. Load the specified style at compile time in one step.

    ▍ END



    Zhang lun drops | senior software development engineer

    She started her career in 2015 and joined Didi in 2017. Love programming, pseudo full cycle engineer. He’s an idea junkie, and he likes to use technology to solve problems. Dream of being a big tree, watching the passage of time.