Web前端项目处理方法、装置、电子设备及存储介质

技术领域

本申请涉及计算机技术领域，具体涉及软件开发技术领域，尤其涉及一种Web前端项目处理方法、装置、电子设备及存储介质。

背景技术

在企业的日常管理中，一条业务线或者一条产品线往往包括多个工程，每个工程不仅在业务层面会有所关联，在代码层面上也紧密相关。通常，各工程之间会存在一些公用模块。针对这些共用模块，若根据业务需求需要修改，则需要多个工程的相同模块做相同的改动，维护成本高，此外改动后的多个工程都需要分别进行部署，部署成本较高。

发明内容

本申请提供了一种Web前端项目处理方法、装置、电子设备及存储介质。

根据本申请的第一方面，提供了一种Web前端项目处理方法，所述Web前端项目包括业务工程和公共工程，所述业务工程包括多个子工程，所述公共工程包括所述多个子工程中的至少一个公共业务组件模块，所述方法包括：

响应于针对所述业务组件模块的第一变更请求，根据所述第一变更请求获取与所述公共业务组件模块对应的代码更新文件；

将对应的代码更新文件进行打包以得到所述公共业务组件模块的更新文件，并将所述公共业务组件模块的更新文件分别存储至所述公共工程下的存储路径中；

根据存储至所述公共工程下的存储路径中的所述更新文件，对包含有所述公共业务组件模块的Web前端页面进行页面内容更新。

在本申请的一些实施例中，所述根据存储至所述公共工程下的存储路径中的所述更新文件，对包含有所述公共业务组件模块的Web前端页面进行页面内容更新，包括：

响应于打开所述Web前端页面的操作，确定与所述操作对应的目标页面中是否存在所述公共业务组件模块；

响应于所述目标页面中存在所述公共业务组件模块，从所述目标页面之中的代码信息中确定所述公共业务组件模块对应的目标存储地址；

根据所述目标存储地址，从所述公共工程下的存储路径中读取对应的更新文件，并基于读取到的更新文件进行渲染。

在本申请的一些实施例中，所述将对应的代码更新文件进行打包，得到所述公共业务组件模块的更新文件，并将所述公共业务组件模块的更新文件分别存储至所述公共工程下的存储路径中，包括：

将与所述公共业务组件模块代码更新文件分别打包成与所述公共业务组件模块对应的单文件；

将所述单文件存储至所述公共工程下的存储路径中。

在本申请的一些实施例中，至少一个所述子工程包括非公共业务组件模块，所述方法还包括：

响应于针对目标子工程之中所述非公共业务组件模块的第二变更请求，根据所述第二变更请求获取对应的代码更新文件，并将所述对应的代码更新文件进行打包并存储至所述目标子工程下的存储路径中；

响应于打开针对所述目标子工程的页面的操作，从与所述页面的代码信息中确定出所述非公共业务组件模块对应的存储地址；

根据所述非公共业务组件模块对应的存储地址，从所述目标子工程下的存储路径中读取对应的打包文件，并基于读取到的打包文件进行渲染。

此外，在本申请实施例中，所述子工程的Web页面中的所述公共业务组件模块是以微件Widget的形式构建的，通过软件开发工具包SDK承接所述公共业务组件模块。

根据本申请的第二方面，提供了一种Web前端项目处理装置，所述Web前端项目包括业务工程和公共工程，所述业务工程包括多个子工程，所述公共工程包括所述多个子工程中的至少一个公共业务组件模块，所述装置包括：

第一获取模块，用于响应于针对所述公共业务组件模块的第一变更请求，根据所述第一变更请求获取与所述公共业务组件模块对应的代码更新文件；

第一处理模块，用于将对应的代码更新文件进行打包以得到所述公共业务组件模块的更新文件，并将所述公共业务组件模块的更新文件分别存储至所述公共工程下的存储路径中；

页面更新模块，用于根据存储至所述公共工程下的存储路径中的所述更新文件，对包含有所述公共业务组件模块的Web前端页面进行页面内容更新。

在本申请的一些实施例中，所述页面更新模块具体用于：

响应于打开所述Web前端页面的操作，确定与所述操作对应的目标页面中是否存在所述公共业务组件模块；

响应于所述目标页面中存在所述公共业务组件模块，从所述目标页面之中的代码信息中确定所述公共业务组件模块对应的目标存储地址；

根据所述目标存储地址，从所述公共工程下的存储路径中读取对应的更新文件，并基于读取到的更新文件进行渲染。

在本申请的一些实施例中，所述第一处理模块具体用于：

将与所述公共业务组件模块代码更新文件分别打包成与所述公共业务组件模块对应的单文件；

将所述单文件存储至所述公共工程下的存储路径中。

在本申请实施例中，至少一个所述子工程包括非公共业务组件模块，所述装置还包括：

第二获取模块，用于响应于针对目标子工程之中所述非公共业务组件模块的第二变更请求，根据所述第二变更请求获取对应的代码更新文件；

第二处理模块，用于将所述对应的代码更新文件进行打包并存储至所述目标子工程下的存储路径中；

确定模块，用于响应于打开针对所述目标子工程的页面的操作，从与所述页面的代码信息中确定出所述非公共业务组件模块对应的存储地址；

其中，所述页面更新模块还用于根据所述非公共业务组件模块对应的存储地址，从所述目标子工程下的存储路径中读取对应的打包文件，并基于读取到的打包文件进行渲染。

此外，在本申请实施例中，所述子工程的Web页面中的所述公共业务组件模块是以微件Widget的形式构建的，通过软件开发工具包SDK承接所述公共业务组件模块。

根据本申请的第三方面，提供了一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述第一方面所述的方法。

根据本申请的第四方面，提供了一种存储有计算机指令的非瞬时的计算机可读存储介质，所述计算机指令用于使所述计算机执行上述第一方面所述的方法。

根据本申请的技术方案，将Web前端项目分为业务工程和公共工程，并将公共业务组件模块在公共工程中进行管理，业务工程根据需求直接引用公共工程中的公共业务组件模块来实现对应功能的开发，从而降低了开发成本及维护成本，提高了开发效率。针对每个公共业务组件模块的变更请求，只需要将公共工程中对应代码进行更新及打包，就可以实现Web前端页面在打开时的同步更新，避免了由于重复部署及重复修改造成的成本浪费，也避免了由于更新遗漏或不及时造成Web前端页面显示不一致的情况发生。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本申请的限定。其中：

图1是现有的某业务线中每个系统的结构图；

图2是根据本申请实施例提出的一种Web前端项目处理方法的流程图；

图3是根据本申请实施例提出的A业务工程中各子工程与公共工程的关系图；

图4是根据本申请实施例提出Web页面内容更新的流程图；

图5是根据本申请实施例提出的一种Web前端项目处理方法的架构图；

图6是根据本申请实施例提处的另一种Web前端项目处理方法的流程图；

图7是根据本申请实施例提处的一种Web前端项目处理装置的结构框图；

图8是根据本申请实施例提处的另一种Web前端项目处理装置的结构框图；

图9是用来实现本申请实施例的Web前端项目处理的方法的电子设备的框图。

具体实施方式

以下结合附图对本申请的示范性实施例做出说明，其中包括本申请实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本申请的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

需要说明的是，在不同的Web前端项目中，同一业务线或同一产品线下包括多个工程，由于每个工程在业务层面的相关性，使不同工程在代码层面也密切相关。图1为某业务线中每个系统的结构图，如图1所示，在系统1、系统3、系统5及系统6中均存包括功能2，且各系统的功能2代码均相同。目前，各系统针对功能2会分别进行开发及部署，造成了开发成本的浪费，且影响代码的规范性。此外，若功能2的需求进行变更，需要各系统针对功能2分别进行更改及部署，一方面不能保证各系统功能2的一致性，另一方面由于重复性地修改及部署严重地浪费了开发成本。

基于上述问题，本申请提出了一种Web前端项目处理方法、装置、电子设备及存储介质，实现了多工程公共模块一次开发、一次部署、多次应用，从而提高了开发效率。

图2为本申请实施例提出的一种Web前端项目处理方法的流程图。需要说明的是，本申请实施例提出的Web前端项目处理方法可应用于Web前端项目处理装置。其中该Web前端项目处理装置可被配置于电子设备。

需要说明的是，该Web前端项目包括业务工程和公共工程。其中，业务工程包括多个子工程，且公共工程包括多个子工程中的至少一个公共业务组件模块。也就是说，在Web前端项目中的业务工程中，每个业务工程会包括多个子工程，不同子工程对应的前端页面中会存在相同的功能。所以，在本申请实施例中，将前端项目分为业务工程和公共工程，其中，公共工程中的公共业务组件模块对应不同子工程中的相同功能，这样，各子工程可以直接引用公共业务组件模块来实现相关的功能，从而不需要重复性开发。此外，若涉及到各子工程中相同功能的需求变更时，由于各子工程直接引用的公共工程中的公共业务组件模块，所以只需要将公共工程中的对应公共业务组件模块进行代码修改及部署上线，无需重复性的开发及部署。

作为一种示例，图3为A业务工程中各子工程与公共工程的关系图。如图3所示，A业务工程中多个子工程中均需要公共业务组件模块B，所以在A公共工程中创建了公共业务组件模块B，需要此功能的子工程可直接引用A公共工程中的公共业务组件模块B，从而各子工程无需针对此功能进行重复性开发。此外，若公共业务组件模块B发生了需求变更，此处开发人员针对变更需求只针对A公共工程中的公共业务组件模块B进行修改及部署，对应的子工程即可同步更新，无需再进程重复开发及部署。

接下来，将针对本申请实施例提出的Web前端项目处理方法的实现方式进行详细说明，如图2所示，该方法包括以下步骤：

步骤201，响应于针对公共业务组件模块的第一变更请求，根据第一变更请求获取与公共业务组件模块对应的代码更新文件。

可以理解，公共工程中包括至少一个公共业务组件模块，若业务需求有变化，则对应的公共业务组件模块的代码也需要进行对应的修改。其中，第一变更请求是指，关于相关公共业务组件模块的变更请求。

在本申请实施例中，若收到关于公共业务组件模块的变更请求时，相关代码维护人员会针对公共工程中对应的公共业务组件模块，根据变更请求进行代码的修改。若第一变更请求有多个，或者第一变更请求涉及多个公共业务组件模块，则相关代码人员根据每个变更请求，对涉及的每个公共业务组件模块均进行代码修改。从而基于代码修改，得到与公共业务组件模块对应代码更新文件。

步骤202，将对应的代码更新文件进行打包，以得到公共业务组件模块的更新文件，并将公共业务组件模块的更新文件分别存储至公共工程下的存储路径中。

也就是说，与公共业务组件模块对应的代码更新文件需要分别进行打包，并上传到公共工程下对应的存储路径中，以实现公共工程中对应公共业务组件模块的功能更新。需要说明的是，在公共工程中，每个公共业务组件模块对应一个唯一的存储路径。所以公共业务组件模块对应代码更新文件打包后，需要分别存储在公共工程下与其对应的存储路径中。

为了保证公共工程中各公共业务组件模块每次更新的完整性，在实际操作时，可以将公共业务组件模块代码更新文件分别打包成与该公共业务组件模块对应的单文件；然后，将该单文件存储至公共工程下的存储路径中。其中，将代码更新文件打包成对应的单文件，一方面保证了公共业务组件模块对应的打包文件分别进行存储时不会遗漏，避免出错。另一方面使公共业务组件模块对应的单文件在公共工程中存储完成后，即可完成对应公共业务组件模块的更新，避免出现由于多个打包文件进行存储时的存储完成时间不同，造成的只更新部分功能的情况的发生。

步骤203，根据存储至公共工程下的存储路径中的更新文件，对包含有公共业务组件模块的Web前端页面进行页面内容更新。

也就是说，若Web前端页面中存在有变更请求的公共业务组件模块，则在打开对应Web前端页面时，直接根据存储至公共工程下的存储路径中的更新文件加载对应的更新内容，从而完成对应Web前端页面内容的更新。

根据本申请实施例的Web前端项目处理方法，将Web前端项目分为业务工程和公共工程，并将公共业务组件模块在公共工程中进行管理，业务工程根据需求直接引用公共工程中的公共业务组件模块来实现对应功能的开发，从而降低了开发成本及维护成本，提高了开发效率。针对每个公共业务组件模块的变更需求，只需要将公共工程中对应代码进行更新及打包，就可以实现Web前端页面在打开时的同步更新，避免了由于重复部署及重复修改造成的成本浪费，也避免了由于更新遗漏或不及时造成Web前端页面显示不一致的情况发生。

针对上述实施例提出的Web前端项目处理方法，针对公共业务组件模块有变更请求时，对应的Web前端页面内容的更新可以通过以下方式实现。图4为本申请实施例中Web前端页面内容更新的流程图。如图4所示，基于上述实施例，其中Web前端页面内容更新可以包括以下步骤：

步骤401，响应于打开Web前端页面的操作，确定与所述操作对应的目标页面中是否存在公共业务组件模块。

可以理解，若业务工程的多个子工程中存在公用功能，则该公用功能会被创建为公共工程中的公共业务组件模块，需要该功能的子工程对应的代码会引用其对应公共业务组件模块，从而实现相关功能的开发。所以，在打开Web前端页面时，需要确定当前需要打开的页面对应的代码中，是否引用了公共业务组件模块。若引用了公共业务组件模块，需要获取公共业务组件模块对应的代码文件，来保证当前打开的Web页面中对应功能的实现。

步骤402，响应于目标页面中存在公共业务组件模块，从目标页面之中的代码信息中确定公共业务组件模块对应的目标存储地址。

由于每个公共业务组件模块在公共工程中均有一个唯一存储路径，所以业务子工程需要引用公共业务组件模块时，会在业务子工程对应的代码中，写入需要引用的公共业务组件模块在公共工程中的存储位置，以便于相关功能的实现。其中，存储位置可以包括公共工程对应的前缀及域名，和引用的公共业务组件模块在公共工程中的存储路径。

在本申请实施例中，若目标页面中存在公共业务组件模块，为了保证目标页面中公共业务组件模块的功能实现，需要找到该公共业务组件模块对应的更新文件。也就是说，需要在目标页面对应的代码信息中确定公共业务组件模块对应的目标存储地址，从而找到该公共业务组件模块的更新文件。

步骤403，根据目标存储地址，从公共工程下的存储路径中读取对应的更新文件，并基于读取到的更新文件进行渲染。

可以理解，由于目标存储地址包括公共工程的前缀及域名，和对应公共业务组件模块的存储路径，所以根据目标存储地址可以在公共工程的存储路径找到对应的更新文件。此时，读取打包文件中的代码进行渲染，Web前端页面中对应的功能即可实现。

在本申请实施例中，若公共业务组件模块根据需求变更请求进行了更新，则读取到的对应打包文件均为已更新后的打包文件，也就是说，公共业务组件模块在公共工程中进行更新后，其他引用该公共业务组件模块的Web前端页面，在执行打开操作时，显示的关于公共业务组件模块的功能也是更新后的。由此，无需对Web前端页面代码进行更新，通过更新公共工程下公共业务组件模块的打包文件，即可实现对所有引用了该公共业务组件模块的Web前端页面中对应功能内容的更新。

根据本申请实施例的Web前端项目处理方法，每个公共业务组件模块在公共工程中对应唯一的一个存储路径，Web前端页面代码中直接引用对应公共业务组件模块的存储地址，在打开Web前端页面时，直接根据页面代码中引用的存储地址读取对应的文件。所以，针对公共业务组件模块存在变更请求时，将公共业务组件模块更新后，在打开Web前端页面时，可以直接根据页面代码中引用的存储地址读取对应的更新文件，完成Web页面内容的更新，从而实现了Web前端页面的同步更新，避免了由于重复部署及重复修改造成的成本浪费，提高了开发效率。

为了进一步地对上述Web前端项目处理方法进行说明，接下来将基于上述实施例，针对公共业务组件模块的构建及应用进行介绍。

图5为本申请实施例提出的一种Web前端项目处理方法的架构图。如图5所示，为了实现更友好的体验及便于管理，各子工程的Web页面中的公共业务组件模块可以是以微件Widget的形式构建的，通过软件开发工具包SDK承接公共业务组件模块。

微件Widget是一种小型的Web应用程序，与普通网页一样使用现有的标准Web技术开发，包括HTML(HyperText Mark-up Language，超文本标记语言)、CSS(cadingStyleSheet，级联样式表，是一组格式设置规则)、JavaScript(一种客户端脚本语言)、XML(Extensible Markup Language，可扩展标记语言)和Ajax(Asynchronous JavaScript andXML，异步JavaScript和XML)等。与普通网页的最显著区别就是，它不依赖于浏览器显示框架，且被设计为具有特定的功能，如股票、天气预报、时钟、游戏等。由于Widget具备小巧轻便、功能完整、可更新性，目前在软件开发领域得到了广泛的应用，以增强用户体验，提升开发效率。

针对采用Widget的形式构建公共业务组件模块的实现方式，可以使用具有工程创建、页面创建、Widget创建、构建及业务开发相关的本地服务等功能的CLI(command-lineinterface，命令行界面)来实现。如图4所示，本申请基于上述功能的CLI形成了公共业务组件模块脚手架，以此实现公共工程及各公共业务组件模块的创建、管理及维护。

此外，为了以更友好的方式管理不同子工程中公共功能，通过SDK承接公共业务组件模块，并根据各子工程中引入的公共业务组件模块的存储地址，实现公共业务组件模块的使用。

根据本申请实施例提出的Web前端项目处理方法，将公共业务组件模块以微件Widget的形式构建，提高了Web页面的交互体验，也不会影响页面内容的SEO(SearchEngine Optimization，搜索引擎优化)。此外，各子工程通过软件开发工具包SDK承接公共业务组件模块，一方面能有效地实现了公共业务组件模块的管理，另一方面也便于各公共业务组件模块与业务工程的对应，使各子工程对公共业务组件模块的引用更加规范，提升了开发效率。

此外，由于各业务工程的子工程中可能还会包括非公共业务组件模块，也就是说，各子工程中除了公共功能之外，可能还会存在一些当前子工程特有的功能。这些子工程特有的功能可以直接在对应的子工程中进行开发及部署。接下来将针对上述非公共业务组件模块，提出了另一种Web前端项目处理方法。

图6为本申请实施例提出的另一种Web前端项目处理方法的流程图。如图6所示，基于上述实施例，该方法还包括：

步骤601，响应于针对目标子工程之中非公共业务组件模块的第二变更请求，根据第二变更请求获取对应的代码更新文件，并将对应的代码更新文件进行打包并存储至目标子工程下的存储路径中。

可以理解，若子工程中存在非公共业务组件模块，则该非公共组件模块的代码文件可以直接存储在当前子工程下的存储路径中。若其中的非公共业务组件模块需要进行需求变更，也就是说非公共业务组件模块的功能需要修改时，对应的开发人员会针对变更需求对相关的非公共业务组件模块的代码进行修改，以得到代码更新文件。

在本申请实施例中，若目标子工程之中的非公共业务组件模块有变更需求，此时针对开发人员对代码的修改，获取代码更新文件，并将其打包存储至目标子工程下的存储路径中，从而实现对应非公共业务组件模块的部署上线。需要说明的是，为了便于子工程之中非公共业务组件模块的管理，每个非公共业务组件模块可以在对应的子工程中有一个唯一的存储路径，若某个非公共业务组件模块需要更新时，将其更新代码文件打包存储在对应的存储路径中。

步骤602，响应于打开针对目标子工程的页面的操作，从与页面的代码信息中确定出非公共业务组件模块对应的存储地址。

可以理解，当打开目标子工程页面时，需要根据请求内容来加载页面。为了提高页面的加载速度，在页面开发时，可以将页面中的非公用性功能分为不同的非公共业务组件模块，从而将前端开发拆成可控的小块。同时，将子工程中的非公共业务组件模块存储在该子工程下对应的存储路径中。这样，在子工程的页面代码中，将每个相关的非公用性功能处附上对应非公共业务组件模块的存储地址，在页面加载时，根据存储地址去获取读取对应文件的代码，实现页面内容的获取。

步骤603，根据非公共业务组件模块对应的存储地址，从目标子工程下的存储路径中读取对应的打包文件，并基于读取到的打包文件进行渲染。

需要说明的是，若目标子工程页面中的非公共业务组件模块根据需求变更进行了更新，在打开目标子工程的页面时，通过非公共业务组件模块对应的存储地址获取打包文件进行渲染，显示的关于非公共业务组件模块的功能也是更新后的。

根据本申请实施例的Web前端项目处理方法，针对目标子工程中的非公用功能划分为非公共业务组件模块，并将非公共业务组件模块的代码文件存储在目标子工程下的存储路径中，从而使前端开发轻量化，降低了代码的维护成本。当目标子工程的页面打开时，根据子工程代码中非公共业务组件模块的存储地址获取对应代码文件，实现页面加载，从而提高了前端页面的加载速度。此外，针对非公共业务组件模块的变更需求，将修改代码后的代码更新文件打包并存储至对应子工程下的存储路径中，完成对应非公共业务组件模块变更的部署，从而使对应页面在打开时可根据存储路径获取更新后的非公共业务组件模块，提高了前端项目的开发效率。

为了实现上述方法，本申请提出了一种Web前端项目处理装置。

图7为本申请实施例提出的一种Web前端项目处理装置的结构框图。需要说明的是，Web前端项目包括业务工程和公共工程，业务工程包括多个子工程，公共工程包括多个子工程中的至少一个公共业务组件模块。如图7所示，该Web前端项目处理装置包括：

第一获取模块701，用于响应于针对公共业务组件模块的第一变更请求，根据第一变更请求获取与公共业务组件模块对应的代码更新文件；

第一处理模块702，用于将对应的代码更新文件进行打包以得到公共业务组件模块的更新文件，并将公共业务组件模块的更新文件分别存储至公共工程下的存储路径中；

页面更新模块703，用于根据存储至公共工程下的存储路径中的更新文件，对包含有公共业务组件模块的Web前端页面进行页面内容更新。

在本申请的一些实施例中，页面更新模块703具体用于：

响应于打开Web前端页面的操作，确定与操作对应的目标页面中是否存在公共业务组件模块；

响应于目标页面中存在公共业务组件模块，从目标页面之中的代码信息中确定公共业务组件模块对应的目标存储地址；

根据目标存储地址，从公共工程下的存储路径中读取对应的更新文件，并基于读取到的更新文件进行渲染。

在本申请的一些实施例中，第一处理模块702具体用于：

将与每个公共业务组件模块代码更新文件分别打包成与每个公共业务组件模块对应的单文件；

将与每个公共业务组件模块对应的单文件存储至公共工程下的存储路径中。

此外，在本申请实施例中，子工程的Web页面中的公共业务组件模块是以微件Widget的形式构建的，通过软件开发工具包SDK承接公共业务组件模块。

根据本申请实施例提出的Web前端项目处理装置，将Web前端项目分为业务工程和公共工程，并将公共业务组件模块在公共工程中进行管理，业务工程根据需求直接引用公共工程中的公共业务组件模块来实现对应功能的开发，从而降低了开发成本及维护成本，提高了开发效率。针对每个公共业务组件模块的变更需求，只需要将公共工程中对应代码进行更新及打包，就可以实现Web前端页面在打开时的同步更新，避免了由于重复部署及重复修改造成的成本浪费，也避免了由于更新遗漏或不及时造成Web前端页面显示不一致的情况发生。

由于各子工程中，除了公用功能外，还会存在一些各子工程特有的功能，也就是说，各子工程中除了公共业务组件模块外，还会存在非公共业务组件模块。针对非公共业务组件模块，本申请提出了另一种Web前端项目处理装置。

图8为本申请实施例提出的另一种Web前端项目处理装置的结构框图。在本申请实施例中，至少一个所示子工程包括非公共业务组件模块。如图8所示，在上述实施例的基础上，该装置还包括：

第二获取模块804，用于响应于针对目标子工程之中非公共业务组件模块的第二变更请求，根据第二变更请求获取对应的代码更新文件；

第二处理模块805，用于将对应的代码更新文件进行打包并存储至目标子工程下的存储路径中；

确定模块806，用于响应于打开针对目标子工程的页面的操作，从与页面的代码信息中确定出非公共业务组件模块对应的存储地址；

其中，页面更新模块803还用于根据非公共业务组件模块对应的存储地址，从目标子工程下的存储路径中读取对应的打包文件，并基于读取到的打包文件进行渲染。

需要说明的是，图8中的801～803与图7中的701～703具有相同的功能结构，此处不再赘述。

根据本申请实施例的Web前端项目处理装置，针对目标子工程中的非公用功能划分为非公共业务组件模块，并将非公共业务组件模块的代码文件存储在目标子工程下的存储路径中，从而使前端开发轻量化，降低了代码的维护成本。当目标子工程的页面打开时，根据子工程代码中非公共业务组件模块的存储地址获取对应代码文件，实现页面加载，从而提高了前端页面的加载速度。此外，针对非公共业务组件模块的变更需求，将修改代码后的代码更新文件打包并存储至对应子工程下的存储路径中，完成对应非公共业务组件模块变更的部署，从而使对应页面在打开时可根据存储路径获取更新后的非公共业务组件模块，提高了前端项目的开发效率。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

根据本申请的实施例，本申请还提供了一种电子设备和一种可读存储介质。

如图9所示，是根据本申请实施例的Web前端项目处理方法的电子设备的框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本申请的实现。

如图9所示，该电子设备包括：一个或多个处理器901、存储器902，以及用于连接各部件的接口，包括高速接口和低速接口。各个部件利用不同的总线互相连接，并且可以被安装在公共主板上或者根据需要以其它方式安装。处理器可以对在电子设备内执行的指令进行处理，包括存储在存储器中或者存储器上以在外部输入/输出装置(诸如，耦合至接口的显示设备)上显示GUI的图形信息的指令。在其它实施方式中，若需要，可以将多个处理器和/或多条总线与多个存储器和多个存储器一起使用。同样，可以连接多个电子设备，各个设备提供部分必要的操作(例如，作为服务器阵列、一组刀片式服务器、或者多处理器系统)。图9中以一个处理器901为例。

存储器902即为本申请所提供的非瞬时计算机可读存储介质。其中，所述存储器存储有可由至少一个处理器执行的指令，以使所述至少一个处理器执行本申请所提供的Web前端项目处理的方法。本申请的非瞬时计算机可读存储介质存储计算机指令，该计算机指令用于使计算机执行本申请所提供的Web前端项目处理的方法。

存储器902作为一种非瞬时计算机可读存储介质，可用于存储非瞬时软件程序、非瞬时计算机可执行程序以及模块，如本申请实施例中的Web前端项目处理的方法对应的程序指令/模块(例如，附图7所示的第一获取模块701、第一处理模块702、页面更新模块703)。处理器901通过运行存储在存储器902中的非瞬时软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例中的Web前端项目处理的方法。

存储器902可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据Web前端项目处理的电子设备的使用所创建的数据等。此外，存储器902可以包括高速随机存取存储器，还可以包括非瞬时存储器，例如至少一个磁盘存储器件、闪存器件、或其他非瞬时固态存储器件。在一些实施例中，存储器902可选包括相对于处理器901远程设置的存储器，这些远程存储器可以通过网络连接至用于Web前端项目处理的电子设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

Web前端项目处理的方法的电子设备还可以包括：输入装置903和输出装置904。处理器901、存储器902、输入装置903和输出装置904可以通过总线或者其他方式连接，图9中以通过总线连接为例。

输入装置903可接收输入的数字或字符信息，以及产生与Web前端项目处理的电子设备的用户设置以及功能控制有关的键信号输入，例如触摸屏、小键盘、鼠标、轨迹板、触摸板、指示杆、一个或者多个鼠标按钮、轨迹球、操纵杆等输入装置。输出装置904可以包括显示设备、辅助照明装置(例如，LED)和触觉反馈装置(例如，振动电机)等。该显示设备可以包括但不限于，液晶显示器(LCD)、发光二极管(LED)显示器和等离子体显示器。在一些实施方式中，显示设备可以是触摸屏。

此处描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、专用ASIC(专用集成电路)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

这些计算程序(也称作程序、软件、软件应用、或者代码)包括可编程处理器的机器指令，并且可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。如本文使用的，术语“机器可读介质”和“计算机可读介质”指的是用于将机器指令和/或数据提供给可编程处理器的任何计算机程序产品、设备、和/或装置(例如，磁盘、光盘、存储器、可编程逻辑装置(PLD))，包括，接收作为机器可读信号的机器指令的机器可读介质。术语“机器可读信号”指的是用于将机器指令和/或数据提供给可编程处理器的任何信号。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)、互联网和区块链网络。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决了传统物理主机与VPS服务("Virtual Private Server"，或简称"VPS")中，存在的管理难度大，业务扩展性弱的缺陷。服务器也可以为分布式系统的服务器，或者是结合了区块链的服务器。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发申请中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本申请公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本申请保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本申请的精神和原则之内所作的修改、等同替换和改进等，均应包含在本申请保护范围之内。