I'm totally going overboard with MB Blocks with my projects, but I'm having a huge issue when the context of editing is set to "side".
Whenever the user makes the most subtle change an Ajax call is fired to the server to render the block again. Now, if I have either a text field or a colour field or a range/slider field, this can end up happening so many times in a matter of a fraction of a second that it's likely to overload the server, especially if multiple people are using the block editor at the same time.
First of all, a new Ajax call should not get fired until the previous one completed, and also if the user makes further changes only the final call should be made instead of one-per-change.
Adding a simple delay to the triggering of the call would help a lot. I.e. if I'm typing in a text field, I'll likely need a few seconds to complete my sentence. So if the trigger waits 1 second we'd already avoid tons of calls.
I could not find in the docs a way to add a delay to the Ajax call. Is there maybe a filter I could use?
Also, _for text fields_ it would help if the call would be fired after I'm done editing, i.e. when I remove the focus. And for _colour fields_, it should fire when I click on "select color" rather than every time a change is made.
Hope this all makes sense!
Thank you for your feedback.
I think it's the main feature of the block editor itself when rendering the changes immediately to see everything on "live" without any delay. I will also inform the development team to consider supporting a filter to change the delay to Ajax call.
Thanks for your reply! Yes, live editing would be the whole point, but since that's not possible due to the nature of MB Blocks -- storing everything on server side and having to parse through a PHP template rather than updating everything through JS -- a quick workaround to this issue would be greatly appreciated.
Please note WP core blocks don't have this issue:
- in these you can enter custom text inline, on the editor side and not on the side, without triggering any Ajax
- Also, the WP blocks "range" system, i.e. on the paragraph typography option, does not call Ajax if you change a value
- finally, the built-in colour picker doesn't let you fine-tune colours so you don't end up changing it multiple times just to get to the colour you want. And even the colour change won't trigger Ajax.
So they managed to avoid this issue completely, I assume by assigning the appropriate classes to blocks via JS instead of parsing everything on the back end on every change.
Since at the end of the day most changes are made through classes, perhaps some options can be added to the fields to determine if the change of the field needs to fire Ajax or to just toggle some class to a specific part of the HTML? It sounds complicated, but it looks like WP Core is doing it so there should be a way to achieve this.
But that's for later. I think as a quick fix, a delay to Ajax would solve the most immediate performance issue.
Thanks for your work!