Details affect success or failure-thoughts on a front-end debugging

Question-when the product completes 99%, the remaining 1% should not be ignored. The final success or failure may depend on the 1%. Some people say that the victory is in the last five minutes.

Whether it's a long-distance race, a startup, or a product, there's always a middle, there's always a sprint, there's always a peak and a low point. At each stage, we should do what we should do at this stage. In this sprint and the pursuit of perfection, we need courage and perseverance to complete these tasks. If we do the right thing, the chances of success will be greatly increased.

Recently, I helped developers complete a front-end framework usage optimization, with a deeper feeling. A product we recently developed is about to be released. the main framework of the product uses a set of tab labels based on jquery plug-ins. The specific function is to open a feature page from the left-side navigation bar, which can be displayed in the form of tags. Similar to the tab mode provided by the browser, the details are as follows:

This method supports multi-task processing, which is similar to the browser's multi-page tag.

However, there is an obvious problem with the previous framework, that is, when the left navigation bar is hidden, the DIV in the tab does not automatically calculate the width. The problem is that when the navigation bar is hidden, A blank line is displayed on the left of the entire interface framework. I have said this question several times with the relevant developers. His answer is "yes". This is because a third-party plug-in is used. I don't know how to modify it. I may not be able to modify it. I feel like he thinks it's okay. The navigation bar will be displayed sooner or later. Will the problem disappear when it is displayed?

I have been using multiple languages for N years.ProgramI don't want to explain the truth anymore. Although I haven't touched the front-end program in a few days, it should not be a problem to change it.

Soon, I found that this plug-in was well written. The label's container (DIV) is encapsulated as an object. You only need to find the container object of the main framework in The onclick event displayed/hidden in the navigation bar, and then resize it, so I added the following in the onclick event:Code:

VaR bodyframe = jquery (callback parent.doc ument). Find ("# contentframe"). ATTR ("contentWindow ");

Jquery (bodyframe.doc ument. getelementbyid ("tabpanel"). tabs ('resize ');

 

After testing, the problem was solved. But I soon found that there was another problem with IE, right. That's right, it's the nightmare of IE, a front-end programmer. Although this interface is normal in chrome, Firefox, and Safari, It is found in IE that when the navigation bar is hidden, the main framework can be expanded normally. When the navigation bar is displayed, the width of the main frame remains unchanged and extends out of the screen to form a desired scroll bar, rather than re-calculating the expected size.

After some adjustments, a bug was quickly found. The plug-in uses jquery ("# divid") in IE "). width (), cannot get the DIV dynamic change value, so modify to get its container offsetwidth, you can get the authenticity degree. The Code is as follows:

Jquery ("# divid"). Parent (). ATTR ("offsetwidth ");

 

All the problems have been solved. This is an unremarkable feature, and it has no technical difficulty and few changes, but this is a problem that must be solved. That's all.

Before modification, the main framework of this function should be available: Multi-page signatures, switchover, and scalability, but this is only in the eyes of developers. As software developers, at least make your users usable and available. Your users include many roles, such as other developers, testers, product managers, and end users. When using the frameworks, APIs, plugin, product UI, and functions that you provide, every modification comments they propose are very valuable. We need to carefully analyze and judge and improve our products. This is a long-term process and a place for developers to cultivate. I have seen countless programmers. When others put forward improvement suggestions without any consideration, their reply is: I think this is also acceptable!

 

No one likes others to say that they are not doing well and everyone wants to be praised. However, sometimes we have to face the reality and admit that others' suggestions are reasonable. This requires cultivation!

Although luck occupies a certain part in a person's life, in general, character determines fate. Looking back and looking at the path you have taken, and then looking at the trajectory of others' lives, you will find that at every important moment, your personality is always at your choice and decision. Therefore, cultivating your character and improving your mind are the most important tasks in your life. Whether you are a programmer or other practitioners.

Now, in this complicated world, there are many factors for success or failure. Sometimes you still need some luck. Can the Details determine success or failure? At least, let's say that details affect success or failure!