Home  >  Q&A  >  body text

javascript - iview select routing jumps very slowly when the data items are greater than 500

Version:
"vue": "^2.2.2"
"iview": "^2.0.0-rc.15"

Hello everyone, I am currently using iview to develop the backend system, and I encountered the problem that the routing jump is very slow when the data items of the Select component are greater than 500. When it is slow, it takes more than 15 seconds to jump. Later, I tried using element ui and found that it also takes about 2 seconds to jump.

How to deal with the Select component to reduce the jump switching time when the amount of data is relatively large?

漂亮男人漂亮男人2684 days ago1077

reply all(4)I'll reply

  • 三叔

    三叔2017-06-14 10:53:49

    iview and element UI are both a bug

    Each option is a component, and each option is bound to several events.
    You have more than 500 options, which means that this Select alone has more than 500 components. The DOM elements under each component are also bound to several events, so the rendering is of course super slow.

    I have encountered this problem before, and the answer is that unless you Select don’t use iview or element UI, there is nothing you can do.
    I wrote a separate component for Select, which has too many options. Of course, the style is modeled after iview. After all, the style must be consistent, but its internal business logic is completely different from iview, and a lot of customization has been done. sexual optimization.

    reply
    0
  • typecho

    typecho2017-06-14 10:53:49

    You can try to group the data and then use continuous selection to select the data.

    reply
    0
  • 扔个三星炸死你

    扔个三星炸死你2017-06-14 10:53:49

    Of course it will be very slow to request a lot of data at one time. You can display it in pages.

    reply
    0
  • 高洛峰

    高洛峰2017-06-14 10:53:49

    When using the tree component, there are 4000 nodes, which are basically stuck. There is no way to change them to click to load.

    The select component jumps. Since there are 500 nodes, one-time display should not be very friendly. You can consider select with search. Each time a fixed 50 or 100 are returned according to the search value, which means adding back-end logic.

    reply
    0
  • Cancelreply