Sign in

Embedding new framework in old JQ projects for iterative development

oeoqr edited in Sun, 27 Mar 2022

Problem description

I have taken over an old e-commerce project for four or five years. The front-end project built by JQ + easy UI has been iterating again. Now the development is very difficult. The goal is to embed angular6 framework into the project. On the basis of not changing the functions of the old project, the new version of requirements will be embedded and used after the completion of angular6.

The background of the problem and what methods have you tried

The background is that the back-end interface server is huge and complex, and the front-end code is chaotic. When we are ready to start a new stove and quickly complete the new requirements, we gradually migrate the old code. At present, the method we want to use iframe to embed, but the risk assessment is insufficient. (including packaging problem, iframe path problem, etc. How to adapt to multi environment change / development / testing / online)

Please teach us a better way to embed or assess the risk and roughly explain the solution. Thank you very much!

6 Replies
commented on Sun, 27 Mar 2022

Your plan seems to dig a hole for yourself For this deep JQ project, it's best to lighten the back-end voice (such as PHP and nodejs). First, use the template to see what can be reused (page headers and footers), or use the template logic to render (such as judging the client's logic), and separate the original logic a little bit. Then you can do similar processing for the back-end interface, some page rendering logic The logic of the function class can keep the original request mode, or use PHP / nodejs proxy to request (I prefer the latter one, because it is more flexible to write the interface to the front end, and the back end is also more flexible to the back end request). Or if AG is more mature, it's OK to refactor directly. Don't add iframe. Otherwise, it's not cost-effective.

commented on Sun, 27 Mar 2022

To be reasonable, it's not a matter of two days to pay the technical debt in four or five years. Since the project is online and iterative at the same time, the lowest risk and most stable way is to develop according to the old technology stack.

Gradual transition is not recommended. If a project uses angularjs, the transition to angular will be enough for you for a year and a half, not to mention the old project. If it does, I can see that the transition process is no less than rewriting.

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

Another way is to start a new project directly and start from scratch slowly. Each completed module can be directed to the new project through redirection in the old project. However, some state persistence problems may be involved.

commented on Sun, 27 Mar 2022

Your own routing is different from your original JQ mode. It's better to develop a new front end based on angular

commented on Mon, 28 Mar 2022

I don't think it's good to embed with iframe. The new functions in the new page are written in ng; the new functions in the old page are written in JQ. If you have time, refactor simple and disgusting pages, then complex and disgusting pages, and then... I don't think you have time to refactor

commented on Mon, 28 Mar 2022

Refactoring, calling the boss to recruit people, while maintaining the update, while doing the new version. Isn't this a general operation

commented on Mon, 28 Mar 2022

It is suggested to start a new business, put new functions into new systems, link the past and gradually migrate. That's what I did before.

lock This question has been locked and the reply function has been disabled.