Project requirement 1: Build a customer service center, one customer corresponds to multiple customers, there will be multiple chat rooms.

Original solution: 1. Websocket requests are consolidated into a common method/class, which is a reasonable idea. 2. 4. Since each chat room in the project requires a WebSocket connection, we built an object to store webSocket instances of different rooms: when switching rooms, the page does not change, but only changes the data. So, when you switch rooms, you need to find this information in multiple objects. When you close a room, you delete and modify information in multiple objects. This is obviously not a good fit, and it will become more so as the project expands. A more appropriate solution would be to build an object to store all the information in different rooms. The logical data structure would look like this

let rooms = {
  no_1:{
    member:{},
    msg:[],
    websocke: null
  },
  no_2:{
    member:{},
    msg:[],
    websocke: null
  },
}
Copy the code

Project requirement 2: Drag and drop the configuration list page to generate an Element-UI based list page

Drag function solution: 1. Use HTML5 drag property, a drag class wrapped independently. Advantages: using native will be more flexible, you can configure a variety of functions; The downside: it might take a long time to package this class, and you won’t be able to write it any better than the VueDraggable library. On the other hand, the reason for this attempt is that the vue-Draggable document is not easily understood, so it is a bit lazy. 2. Use the Vue-Draggable library. This is obviously the right choice. Although it takes longer to view the library’s documentation, including the English documentation, the overall time cost is less than that of scenario 1. Is the list used to configure the display written as a dummy/dummy with native Html elements, or is it operated directly on element-UI? 1. We started working directly on the element-UI table, but ran into a problem: table-column columns couldn’t be dragged and sorted. Instead, I tried native Html to solve the column sorting problem. But later on, it raises an additional question: Do I need to implement all of the EL-table apis one by one in native Html? Re-create a simple DOM in the sidebar, then drag and drop the sort, change the data and map it to the table.

Of these two requirements, the criteria for judging the solution are time cost and follow-up expansion. In fact, the subsequent expansion will eventually be calculated as the time cost, so the main standard is the final time cost.

Of course, the main standard of some requirements will be performance, and THE two solutions are AB. The time cost of PLAN A is slightly higher, so plan A should also be selected.