Preface package.json is an important file for describing and configuring a project, which contains a number of fields and options that can affect project construction, dependency management, script execution, and so on. Understanding these fields can help developers better understand and control the behavior of the project. package.json for most front-end developers, knowing dependencies and devDependencies is enough. However, for library developers or developers with more advanced needs, it is necessary to understand the other fields of package.json. the fields introduced in this article are divided into official fields and unofficial fields. Unofficial fields are supported by mainstream packaging tools (webpack,Rollup) and are designed to provide more advanced configuration and functionality to meet specific build needs and may not be universal. current version: v7.24.2 I. required attribute 1. name defines the name of the project, not with "." Start with "_" and cannot contain uppercase letters 2. version defines the version number of the project in the format of large version number. The second edition number. Revision number II. Description information 1. description Project description 2. keywords Project keywords 3. author Project author "author": "name (http://barnyrubble.tumblr.com/)" 4. contributors Project contributor "contributors": [ "name <[email protected]> (http://barnyrubble.tumblr.com/)" ] 5. homepage Project home page address 6. repository Project Code Warehouse address 7. bugs address of project submission question // address for submitting questions and email address for feedback. Url is usually the issues page in Github. "bugs": { "url" : "https://github.com/facebook/react/issues", "email" : "[email protected]" } 8. funding specify the financial support method and link for the project "funding": { "type": "patreon", "url": "https://www.patreon.com/my-module"…

there have been various disputes over front-end framework for a long time. The most controversial items are the following two: performance dispute dispute over API design for example, emerging frameworks come up with benchmark to prove their excellent runtime performance, and React is usually at the bottom of these benchmark . in the API design, Vue enthusiasts believe that "more API constrains developers and will not cause significant differences in code quality due to differences in the level of team members." and React enthusiasts think: " Vue a large number of API limits flexibility, JSX yyds". the above discussion boils down to the trade-off between framework performance and flexibility. this article introduces a state management library called legendapp , which is very different from other state management libraries in terms of design philosophy. rational use of legendapp in React can greatly improve the runtime performance of the application. but the purpose of this article is not just to introduce a state management library, but to share with you changes in framework flexibility as performance improves. performance optimization of React It is an indisputable fact that the performance of React is really not very good. The reason is the top-down update mechanism of React . with each status update, React traverses the entire component tree first, starting from the root component. since the traversal mode is fixed, how do you optimize performance? The answer is looking for subtrees that can be skipped when traversing . what kind of subtree can skip traversal? Obviously a subtree of that hasn't changed. in React…