Summary of the fifty-third week - a summary of the cloud document development week

Cloud document development notes - first week summary

The cloud document has been developed for a week, and the entire document is basically developed. Rather than saying that the development is completed, it is better to say that the entire demo has been written, and many functions will definitely be added in the future. I would like to talk about the difficulties and solutions I encountered during development. and what I learned.

Difficulty one - use array storage, use useState to change the value every time, delete the value, find the value, and almost traverse the array once.
I initially stored the list of files in useState in the form of an array, and the form of the object is as follows.

export type defaultFiles = {
    
    
  id:string
  title: string
  body?: string
  isNew?: boolean
  path?: string
  isLoaded?: boolean
}[]

So I made a bold decision to change the array storage to object storage, and changed it to the following structure.

export type defaultFiles = {
    
    
  [key:string]: {
    
    
    id:string
    title: string
    body?: string
    isNew?: boolean
    path?: string
    isLoaded?: boolean
  }
}

Among them, the property of the object key值is id值. In this way, the use of finding the id can be direct defaultFiles.id, and it can be used when deleting delete defaultFiles[id], which saves the problem of traversing the array for each operation. At present, I store it like this. If I want to add a server, it is estimated that it will still be in the form of an array returned. For this reason, I wrote a function to convert the array into an object form, and the object parameter key值is id值.

type defaultFilesType = {
    
    
  id:string
  title: string
  body?: string
  isNew?: boolean
  path?: string
  isLoaded?: boolean
}[]
export const flattenArr = (arr:defaultFilesType):Object => {
    
    
  return arr.reduce((map:map,item) => {
    
    
    map[item.id] = item;
    return map;
  }, {
    
    })
}

Difficulty 2 - What should I do if the software is not opened or opened, and the files in the local directory are deleted, modified, or added?
What I thought at the time was that I can create files in the software, but what if the local files are intentionally modified by the user?
Look at the logic I solved.

  1. Enter the software for the first time, check whether the local directory is deleted, and recreate it if deleted.
  2. Whenever you open the software, pay attention to opening the software, not including refreshing the software. At this time, read the directory of the document, and then generate an object to return. For this reason, I encapsulated a hook, because the software code has not been made public, so the main code will not be shown here.
  3. Use node to monitor the changes of files in the directory. For example, when the software is opened and the local files are maliciously deleted by the user, then node will return the user's operation after monitoring, adding or deleting. There is no modification here, because modification is equivalent to deletion created a file and modified a file.
  4. At this time, I encountered a problem that when I manipulate files in the software, node can also monitor the changes of the directory, so I wrote a useState to store the name of the file. For example: there is a.md file in the file name list. When the user deletes this file locally, I will judge whether a.md exists in my useState. If it exists, it means that it is deleted locally. If it does not exist It means that I deleted it through software.

I also encapsulated a hook for the node listening to the directory.

Summarize

  1. I have some understanding of some operations on arrays, such as reduce.
  2. Learned to encapsulate hooks.
  3. Understand the props communication between React components.
  4. The most important thing I understand is that when writing a React project, you have to dare to write, and you can’t consider optimizing here and there from the beginning, which will lead to not dare to write anywhere, and the writing will not be good. Write it down first, and then refactor where it doesn’t work, and you can’t stand still.

Guess you like

Origin blog.csdn.net/qq_51965698/article/details/127815877