Simple suggestions on front-end framework upgrade and full-site style replacement, front-end framework full-site Style
JQuery on mobileZepto was first introduced in the mobile dom operating library, which implemented most interfaces of jQuery and was successfully supported by the mobile client. The main reason for discontinuing jQuery is the size considerations, and jQuery has developed several times, I finally announced that I will not ignore IE8, but the size of the latest version is still more than 80 KB. However, the core framework of my mobile client does not add up to a large DOM library, and it is hard to give up on it, it is difficult to return because it must be compatible with old interfaces and take care of old users. Some codes cannot be deleted.AngularJS updatesAngularJS corresponds to jQuery, but the version of the framework changes to the framework. 2. X and 1. X is completely two things, from the template to the Business Code is greatly changed, not backward compatible, I can only say: doing well! At the same time, it also makes a lot of buzz. Programmers need to spend their learning, and they have to learn it again after they finish learning, and the previous business code has to be updated. This is indeed a pain. AngularJS is not compatible with the old writing method. It is not because of changes in the underlying mechanism or disruptive attraction. The benefits of this change may be: the framework performance is improved by 50%, or the template may be parsed by the server at the same time, and a set of code solves the SEO problem. Or other things. Weigh the pros and cons, so he does it. This also raises an inevitable question: How should the front-end framework be upgraded, how should it be iterated, and how should the full-site style be updated? Framework upgrade and style upgrade are a headache for a large site. These two problems have just put me in the trap recently.Front-end framework upgradeOur framework consists of 1. X has evolved to 2.X, 2. there was a disruptive change at the time of X, which would require various business teams to make changes simultaneously. Its value is: ① A set of Business Code simultaneously solves the three major requirements of H5 site, Hybrid and SEO ② the number of framework code is reduced by 30-40%, and the size is reduced to Improve the Performance ③ the cost of increasing the maintainability and clear structure of the Framework is: ① some of the inevitable business teams do not pay the bill. The main point is: "the framework upgrade should be transparent", but it is transparent. ② the business team needs to learn about the framework usage again, in addition, you need to change the old business code, increase the workload, and test costs. ③ the app (apk) package is 2 more. the size of X's framework file goes up to the conclusion: the framework is refreshing and the business team is uncomfortable. Therefore, you need to pay attention to the following points during framework upgrade: ① interfaces cannot be unified and cannot be implemented. It is better to be compatible with old interfaces. The old interface may not be named well, or even the interface may be misspelled, or the passing of old interface parameters may be unreasonable, or the interface may be meaningless, but the compatible interface is still compatible because it is already used by others, interface incompatibility is difficult to promote, and it is easy to cause a war of speech ② the document is well-developed, including instructions and demo examples. js documents can be directly generated through standard annotations; however, the demo must be written by experts, because in the future, each team is very likely to copy your demo directly, so the demo is a standard and must be coded with a refined and complete attitude, the entire document may take more time than the framework. Many teams do not pay much attention to document writing because of insufficient framework users, or insufficient time and manpower. The reality is that the business team consulted repeatedly every day, most of the time, developers get bored, so the framework documentation and demo examples are very important. ③ from the business perspective, it is best for framework writers to do business first so that they can think about problems from the perspective of framework users, the actual situation is that the framework has been written, but the compiler has never used it. Therefore, it is a good process to write a demo. ④ the attitude is friendly. The framework has a major version upgrade, changes to the Business Code are inevitable, and some teams can access the framework. If you have to take care of the emotions of the old team, you can hold back your skills, there are sufficient documentation for poorly-developed and inclusive framework upgrades, and it does benefit various business teams and is easy to promote. I plant from no framework to third-party framework, to independent framework, and then to change the underlying dom operation library, change the AMD module loader, to UI separation ...... every change requires the support and cooperation of the business team, but everyone wants a better experience and a better tomorrow! Another thing to note about the framework update is that the performance data of the framework must be compared before each major framework update. Once this type of data is lost, it cannot be found again.Reconstruction of Html and CssThe framework update is basically in your own hands, but the style replacement of the whole site is completely confusing. The hacker is totally two sets of things, and no one knows anyone. There are several selectors in the parser written in this way: header {......} h1 {...... however, the headertag of the entire framework is useless, and the new main_v2.css and the new structure are not in the hands of the framework, and the operations are more complicated. The updates of General UI components are also used in combination with main_v2, think about the entire incident and make a mess. Then we found that Hybrid is used to store the Style File locally, and the whole person is fainted. The above chaotic summary is as follows: ① It is difficult to uniformly publish dozens of service lines using main.css ② the business line ③ main_v2.css cannot ensure that the old program is normal. In fact, it is not guaranteed that ④ the new domstructure cannot run on main.css, however, there are apps and the release time is not uniform. The H5 site and app are two sets of things, and the release has to be incremental. the operation here is: ① release tags with identifiers such as class = "old-header" added to header tags, and prohibit various business teams from occupying tag elements in css for a major version of iteration, confirm that all header labels have the old-header, and you can perform the next step. ② release the business class label sample, remove the header label selector in main.css, add the class of the old-header, and ensure that all sites are running properly. ③ success, delete unnecessary styles. ④ After the latest version of the framework corresponds to the new style, you can ensure that the framework is up-to-date in the latest version, the style structure is up to date, and the actual operation may be complicated. You need to help the business team modify the code, however, the old dom structure and class may be associated with the js business logic and need to be investigated slowly.ConclusionI would like to give you some simple suggestions on the Framework upgrade and full-site style replacement that you have experienced today. If you have a better solution, leave a message.