Is using individual blocks for form items when you need to do a submit for all the items the right approach?
In this scenario, i have 3 forms (the number of items are customisable) and each of the form items has its own internal logic to determine the values for the dropdowns etc. I have implemented these in a block. The block has input parameters which are each individual list item. With each updates within the block we're also passing the item back though the block event and updating the initial list.All this is so that when the user hits submit, we can submit the entire list together.Although this approach works fine for less number of items. When we have more than 10+ form items on the screen, it really starts to slow down. Would like any pointers on making this as performant as possible.Is this the wrong approach? If so how can we make this better?
Hi Saiful Aseem,
I would suggest you to use accordion instead of putting each form inside a block, also you should bind the input fields of the forms to either the current attribute of aggregate or local variables or structure.
If you haven't used accordion widget, you can take reference from here.
Thank you,
I hope this helps.
We're already using accordions too incidentally.
Hi Saiful,
It would help if you could explain at what point the screen slows down.
Also, I gather this is a Reactive app, is that right?
Possible reasons could be multiple calls to the server for each form, and/or slow queries. There are plenty of other possibilities, but we'll need more information to help further.
Is it slow when the user is entering data? If so, check for multiple service or server action calls or data refreshes when the user is entering data. If you can avoid or minimize these it may help. If not, reduce the server calls to a single call passing all the data required.
Is it slow when the user is submitting data? If so, check if there are multiple calls from the client to the server in the submit client action. If you find any, reduce the calls to a single server call.
If there are queries involved and they are slow, investigate if there are any missing indexes that can be added, or custom attributes, functions or joins that can be removed from the query.
I hope this helps!
Kind regards,
Stuart
Hi Stuart,I've decided to not update the parent with each update to the block. This way atleast a lot of the communication from block to parent and parent to block is skipped. We would be validating each block once the submit button is pressed.
To add to Stuart his response. Make sure you don't have an "event storm". I have done something like this in the past and one of my learnings in this is that you don't want to keep communicating between blocks for each change.
So let's say you have block 1. You fill in a input and at each character input you update the parent by an OnChange event. You can better use a debounce function (see the forge ;)) to only update the parent when the user is done typing.
When when the changes of block 1 are received by the parent you can choose to check validation right then and signal back the results to the child (via the input parameter "OnRefreshTimeStamp of type DateTime) for example) but you can also choose to only do this when the submit button is used.
By making sure you only use event signaling when need you keep the load on the client down and this could solve a lot of issues.
Another approach would be to make use of a Wizard instead. Why have a form that is multiple screens long when you can divide these in sections (and you have already done this) and have each section on its own wizard page. Wizards can easily be placed in a list and I have had great success with this in the past.
You can best analyze event storms by adding a console.log to each call. If you don't see the logs show up immediately then you can be sure you have one 😂
Hi Vincent, This might just have been the issue we had. Current approach is to not update the parent at all until the submit button is clicked.And the wizard approach wouldnt really work for us, since its not individual forms with different logic.
Nice to hear that this was a possible cause of your problem. If my answer helped you please mark it as solution :).