The current Web shop only has one set of code, which is generic logic, without any hard coding like Nike Adi. The instance of the web Shop that is currently launched, whether for Nike or Adi, is specified by the parameter passed at startup time. I said command line, and you asked if you could use urls, and I said yes.
But in the current code, we have made a UI for Nike and Adi respectively. Imagine the CSO colleagues want to open 10 Web shops at the same time in order to highlight the demo effect. In addition to Nike and Adi, we will have to copy and paste 8 times.
If you want to follow a QDPR or something like that, you can’t have the real customer’s name in the demo, but you can use ABCDEFGHIJ. If you make 10 xx.vue files, don’t you have to manually change the real customer’s name to ABCDEFGHIJ when every.vue file goes in?
A best practice: Try to abstract the immutable, solidify it into code, and extract the mutable and put it in configuration files. Ideally, no matter what the bosses’ needs change, Developer can respond by modifying the configuration file, without changing the code or recompiling the program.
You’re doing one for each site. Vue’s approach is ok for the current demo, but I worry that when the number of Web shops that will be displayed in the demo exceeds 3, each requirement change will introduce some extra work that could have been avoided with better programming skills.
Now adi this Web shop: support for these fields is hard coded.
Ideally, on the right, you use API #3 to ask the background, what fields does ADI support? The background then tells you that you dynamically draw the VUE page based on the results.
If you find it difficult to achieve this dynamic drawing effect with VUE, you can do it in the current programming way. However, the disadvantages mentioned in the previous email may bring some physical work in the later period as the demand changes.
For more of Jerry’s original articles, please follow the public account “Wang Zixi “:
