Embed a new framework into the old JQ project for iterative development

problem description

has taken over an old e-commerce project that has been four or five years old, and the front-end project built by JQ+easy-ui has been iterated all the time. Now it is very difficult to develop
the goal is to embed the angular6 framework into the project. On the basis of not changing the function of the old project, the new version needs to be embedded after the completion of angular6.

the environmental background of the problems and what methods you have tried

the background is that the background interface server is large and complex, the front-end code is chaotic, and the old code is gradually migrated when you are ready to start a new stove to quickly complete the new requirements.
the current method is to use iframe embedding, but the risk assessment is insufficient. (including packaging problems, iframe path problems, etc., how to adapt to multi-environment change / development / testing / online)

Please give us advice on better embedding methods or assess the risk and outline the solution. Thank you very much!


it is reasonable that 45 years of technical debt cannot be repaid in one or two days. Since the project is online and constantly iterating at the same time, the lowest risk and most stable way is to develop according to the old technology stack.

does not recommend a gradual transition, if nothing else, if a project uses the transition from angularjs, to angular, it will take you a year and a half, not to mention such an old project. If you do, I will see the transition process as much as rewriting.

if it is not limited to angular, the introduction of vue is a good solution, because vue can be introduced directly through script without the need for a complicated front-end engineering system. On this basis, you can also enjoy the convenience of two-way binding and component-based development, which can be regarded as a compromise.

another way is to start a new project directly, slowly starting from scratch, and each module completed can be redirected to the new project in the old project, but some state persistence may be involved.


you angular bring your own route, which is different from your original jq way. It is better to directly develop a new set based on angular frontend


feel that it is not good to use iframe embedding. Use ng to write the new functions in the new page, and use jq to finish the new functions in the old page.
if you have time, restructure simple and disgusting pages, then complex ones, and then
guess you don't have time for refactoring


refactoring. Call your boss to hire people and make a new version while maintaining updates. Isn't this a general operation?


it is suggested to start afresh, put the new function into the new system, link it to the past and migrate gradually. That's what I've done before.


your plan looks like digging a deep hole for yourself.
this kind of deep jQ project, it is best to have a light back-end voice (such as php,nodejs). First, use the template to see what can be reused (header and footer), or you can use template logic to render (such as judging the logic of the client), and then separate the original logic bit by bit, and then you can also do similar processing with the backend interface. Some page rendering logic is shown directly to the layer. The logic of the feature class can retain the original request method, or use the php/nodejs proxy request (I prefer the latter because it is more flexible to write the interface to the front end, as well as the back-end to the back-end request). If you are more familiar with
or Ag, you can just reconstruct it and don't add iframe, otherwise you'll have to step on it, even less cost-effective.

Menu