[QTable / Q-Table] When should I use server request (how many rows?) ?
-
Hi,
In the docs for QTable, it is written that “When your database contains a big number of rows for a Table… [well, you should use @request and server calls]”. My question is: roughly, how many rows is “a big number of rows”? 100s? 1000s? more?
Does it make sense to trigger server calls only if the number of rows is big enough? For instance, for someone starting to use my app and, thus, who does not have a lot of data to display, I may save some server calls.Thank you if you may answer
. -
@Coude said in [QTable / Q-Table] When should I use server request (how many rows?) ?:
Hi,
In the docs for QTable, it is written that “When your database contains a big number of rows for a Table… [well, you should use @request and server calls]”. My question is: roughly, how many rows is “a big number of rows”? 100s? 1000s? more?
Does it make sense to trigger server calls only if the number of rows is big enough? For instance, for someone starting to use my app and, thus, who does not have a lot of data to display, I may save some server calls.Thank you if you may answer
.This is a question answered by UX. If your users FEELS that is it slow, then it is slow. You need to test YOUR app with YOUR data in the usage pattern of YOUR users. And then test with REAL users. if at any point, in slow connection, busy hour, server peak anyone FELT sluggishnes, then you have your answer. Oh, and remember, that this “server” in docs is not necessary a server - it could be your local cache, web worker or local indexed db. The problem with table is not only with data access and transformation but also with data presentation. The simple table even with many rows could have different characteristics of usage than table with lots of columns or table with custom row or custom interactions or… table with on the fly computed data. Test, test and test. Then optimize.
What it means “slow”? Well, any user activated operation which lasts longer then 400 ms is “slow”. Any animation or haptic event longer than 280 ms is slow. Any app wait longer than 1 sec is slow. Any pause in media stream longer than - anything - is slow. This is for business apps. For entertainment apps those times are even shorter.
