Implement a paging with native JavaScript, but don't know what possible flaws and what can be improved?

recently, I have been trying to develop my own wheels with native js. The first project is paging, but because I am not familiar with the encapsulation mode of native js plug-ins, I would like to ask you to see if my writing rules are not standard? There is paging logic encapsulation, on the existing basis can be optimized?
https://github.com/csd7583715.


the biggest problem with native paging is that you have to load all the data locally and page it. The time cost and server cost are high, so it is not very practical.


  1. it is better to put the paging proposal on the backend, at least it will not cause any difference in user experience due to the amount of data. In addition, there are also some data security considerations. Overall loading means spitting out all the data. Is it easy to be a crawler?
  2. encapsulation can be written in UMD, such as in the project elf-preloader.js , which can be referenced.

1, will there be only one page in the id you use?
2, you render every time although it is more native. But there are times when you don't need render.
3, I have not done any open source libraries, what is the advantage of this open source? A lot of them are big packages. The mvvm framework is easy to implement.


A brief look at it shows that my seniority is still low, so I can only talk about some personal opinions

  1. npm install will be introduced with tags after that, which doesn't feel quite in line with some modern build development methods. In the end, it is impossible to introduce all the components of this snippet way through the cdn link way. Although HTTP2 is not a problem, it still needs to be considered at this stage. Some modular work needs to be done to support direct import. It can be packaged with webpack, which can support both direct link src and modern modular solutions.
  2. The organizational structure at the code level of
  3. may not have much code now and does not need to be divided into several files. But this doesn't seem very clear. In page.js, some tools such as util and some logic of page can be extracted into a single js and then introduced into it, without hindering the logic that your page.js should have
  4. .
  5. in terms of code content, general ui components are not recommended to use id to tag, and it is not recommended to use too common names to define class, because carelessly, css-style overrides may occur, resulting in bug. Secondly, I don't know if it doesn't feel good to write html strings directly. I still think it's better to use dom api and fragment so that I can encapsulate some of the routine operations I need instead of writing a bunch of html strings
  6. every time.

for example, there are 30 pieces of data, 10 pieces per page, exactly 3 pages. But when you add a piece of data that needs to be displayed on page 4, the page number is not necessarily updated.

Menu