This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
Now that it's live, don't forget to accept your certification badge on Credly today! Learn more here.
We are currently experiencing an issue with Email verification at this time and working towards a solution. Should you encounter this issue, please click on the "Send Verification Button" a second time and the request should go through. If the issue still persists for you, please email email@example.com for assistance.
We are developing a tool and the UI part of it is mainly responsible for building a nested json-object which represents a configuration-object that afterwards will be sent to our API.
We wrote a reducer for altering values in this json-object. This reducer receives the configuration and mainly copies it, except for the part that needs to be changed, for which a new configuration object is returned. To control which part needs to be updated we dispatch actions.
However, some user interactions cause multiple such actions to be dispatched. In this situation, the problem arises that "handleUpdateModel" (named as in the documentation) works asynchronously, so only the update from the last dispatched action persists.
We expected that behind the scenes the Context of '@alteryx/react-comms' uses the 'useState'-hook for this "handleUpdateModel" function. Therefore, we tried passing it a callback giving access to latest model in the Alteryx state object, as shown in the code below.
After trying this everything worked as expected, when multiple actions were dispatched the configuration was changed correctly.
Another issue arose here however: when leaving the tool, the following error message can be found in the 'Alteryx HTML Developer Tools': "Uncaught TypeError: Cannot convert undefined or null to object".
This causes the state to be entirely lost; bringing us back to square one.
Based on that error, I'd want to see exactly what the payload being sent to getConfiguration is. Have you console logged the last state of that config object before the tool attempts to persist and close? If so, and that doesn't shine a light on the problem, could you share that here? (Not sure if it contains sensitive info).