This is the first day of my participation in Gwen Challenge

preface

I have a small front end. Since the two companies in front of me are both FROM toB, their requirements for product interaction experience and code design and maintenance are not as high as those of C-end, which led to the ordeal of the first few months in the company.Copy the code

The problem

- Code review, hasty code, not properly checked, better way to write, robustness of code, etc. - UI detail, pixel level, and animation effects. -Compatibility, C side also need to take into account browser compatibility, device compatibility, etc... These are easy to ignore the problem, the past only focus on the implementation of the function, did not take into account so many details.Copy the code

Solution:

Before lifting the test, we must check ourselves, specifically from the following perspectives:

1. UI: I think self-checking is very important. When writing a page, the first thing to consider is the layout, whether it is fixed width or proportional scaling. This involves using an elastic layout or a fixed width layout to ensure consistency across large or small screens. 2. Compatibility: Know the browsers and devices required by the product in advance. You can use simulators to simulate these environments to test your own code. 3. Self-check the code logic: The average project today uses typescript, and as long as we don't use any, the code is more than 60% robust. The second is the logic of the code, considering the accuracy of JS calculation. - Naming conventions for variables and interfaces. - Can you write similar logic into a class to ensure the simplicity of the main process code. - Does not consider the interface network error, resulting in code error, so that the application crash. - When listening for an event, consider unloading it at a suitable time.Copy the code

eg1:

Before the code review:

export function updateProducts() {
    return Promise.all([getV1Products(), getV2Products(), getV3Products()])
    .then(results= > {
      store.dispatch.product.setV1Products(results[0])
      store.dispatch.product.setV2Products(results[1])
      store.dispatch.product.setV3Products(results[2])
    }).catch(logger.error(error))
}

Copy the code

There’s a Promise. A failure in all leads to a catch, and that’s not what we want, because we have to consider the possibility of failure.

After the code review:


export function updateProducts() {
  const p1 = getV1Products().then(products= > {
      store.dispatch.product.setV1Products(products);
    }).catch(error= > logger.error(error));

  const p2 = getV2Products().then(v2= > {
      store.dispatch.product.setV2Products(v2);
    }).catch(error= > logger.error(error));

  const p3 = getV3Products().then(v3= > {
      store.dispatch.product.setV3Products(v3);
    }).catch(error= > logger.error(error));

  return Promise.all([p1, p2, p3]);
}

Copy the code

Eg2: By abstracting the logic about a piece into a class and exposing some methods to the outside, we can do what we want, more in line with code design principles: high cohesion and low coupling


class Line {
  private _goodLineIndex: number | null = null;
  private _level: number | null = null;
  private _currentIndex: number | null = null;
  
  constructor(){... }get exist() {
    return this._goodLineIndex ! = =null;
  }

  get level() {
    return this._level;
  }

  get currentIndex() {
    return this._currentIndex;
  }
  
  init() {}
  
  async getLines() {}
  
  async getCurrentLine() {}
  
  optimizedLines() {}
  
  clean() {}
  
  apply(){}}const lineInstance = new Line();

export default lineInstance;

Copy the code
Experience: remember the back-end big guy's words, on the basis of a lot of users, front-end performance optimization a little, can greatly save server bandwidth resources.Copy the code