Many lookup instance causing the form experience slowness and laggy
I have 6 instance lookups for 30 note (6 multiply 30). What is the best recommendation on number of lookup instance in a form.
would relevant can be used to stop the instance from executing and save compute/RAM resources?
when would instance lookups executed? It seems like it ran at each typing.
Example: I put the instance lookup below in hint::English andn hint::Malay for one of the field named 'crop_cycle' to retrieve current plant, P1, P2, P3, M1, M2 and M3. 7 lookup instance. There are close to 30 such fields with similar configurations.
In addition to this, instance also used in relevance to check whether entity contains value. If it does contains value in entity, it will return as 'true' and hide the field. This is to prevent the empty field write back to entity, replace existing value. But, this mechanism also will increse number of instance use for the entire form.
Any idea on the best practice for using instance()
One big thing to know is that, in Collect, currently instance calls are optimized for Entity Lists in a way that they're not for static CSVs attached to your form or internal lists. If possible, consider storing your data in an Entity List to take advantage of that optimization. Even if your data is unchanging, it may be worth using an Entity List for this reason. If you are using Entity Lists and things still feel slow, it would be helpful to see your form definition (you can message it to me directly if it can't be public).
That's true in a field list. If you have one question per screen, then it's on screen change which can make the form feel a lot faster. Consider limiting the number of questions with calculations in field lists.
Is it possible it’s working but not as you expect? The default value is evaluated once at form load. Usually instance expressions require values from the form. What you’re probably looking for is a calculate with a trigger. Docs
If that’s not the issue please send a sample form.
Thanks for the insight. It helps me to understand more on the default field
Default value is evaluated at form load (using now() or pre-defined values in the form such as username, etc)
To use instance at default field, the example (given in documentation) is lookup last repeat value of the same field.
calculation (of a value) +trigger (by an id) is useful to get other value based on the id (with choice_fiter = true)
My great worry for calculation + trigger: If one changed the value first and then changed the id later, the value will be replaced with re-calculated value. There is no problem on the logic, it works as it should.
For my actual use case, I am finding a good method to prevent an empty optional question write back to entities and nullify the field. I thought of two methods:
using calculation + trigger to fill default value (must trigger first, then only change the value,)
using relevant to hide the question when there is pre-existing value in the entity ( allow question to be filled once only)
Neither method would resolve the issue completely and it seems the workflow is where the problem lies:
If what I worry will happens, perhaps it is better off just let them nullified the entity.
This is because Method 1 might create more data issue if someone perceive data is still intact after changing the id (without knowing the id will trigger re-calculation of the field and overwritten the entered value).
Method 2 will limit the entry and unable to do repeat observation.