In this weekly series, Martin describes a question that was raised by a Fonto developer, how it was resolved and why Fonto behaved like that in the first place. This week, a developer reached out with a screenshot of a generic error: something about an Uncaught (in promise): undefined. In this blog post, we’re going to go over the debugOperation option and how to use it.

Let’s start with finding which operation actually caused it. We got a screenshot of a stack trace and the editor, so that was easy.

The breaking code seemed to be in some custom metadata panel where the OperationsManager‘s executeOperation function was evaluated. This code looked a bit like this:

export default function updateInputField (value: string, contextNodeId: NodeId): void {
	void operationsManager.executeOperation('execute-update-script', {
        contextNodeId,
        expression: 'replace value of node $data?contextNode with $data?value',
        value,
    });
}

This code is at some point used in a piece of React code that we will not go into now.

In the 8.5 version of Fonto we introduced a debugOperation flag. I outlined this in a recent blog post: How do I debug validation issues!?. In this blog post we will go into how we used it to debug this operation.

We started by passing the debugOperation flag to the operation. This made the code look like this:

	void operationsManager.executeOperation('execute-update-script', {
		contextNodeId,
		expression: 'replace value of node $data?contextNode with $data?value',
		debugOperation: true,
		value,
	});

Then we triggered the error. The debugOperation flag made the operation log the failure to the console. This was logged:

Custom mutation executeXQueryUpdateFacilityScript: disabled because result is not valid:
This node may not be modified - it is in a subtree subject to configureAsReadOnly rules for selector(s): "self::some-element".
<innerElement>…</innerElement>

This warning pointed us to a configureAsReadOnly somewhere in the code. This pointed us to the actual mistake. Because an ancestor element to the one we were editing was read only, the execute-update-script operation was rejected. Because the code immediately called the operation (without checking the state first) we got an error.

We gave the following advice to the partner:

1. Update that configureAsReadOnly code to not apply to the element. If it’s read-only you’ll not be able to change it. Without knowing more of the configuration we could not give any better advice.

2. Use the useOperation React hook here. This comes with an easy way to check the state of an operation so you can react to it. In general it’s not good practice to call an operation immediately, without checking its state first.

I hope this explained how Fonto works and why it works like that. During the years we built quite the product, and we are aware some parts work in unexpected ways for those who have not been with it from the start. If you have any points of Fonto you would like some focus on, we are always ready and willing to share! Reach out on Twitter to Martin Middel or file a support issue!