designsystemsinternational/mechanic

Handle async design function

Opened this issue · 5 comments

Is your feature request related to something something in Mechanic? Please describe.
We should support async design functions

Is your feature request related to a problem? Please describe.
It actually works, but the canvas seems to be rendered multiple times when updating the values
Screen Shot 2022-09-02 at 2 31 31 PM

Describe the solution you'd like
That I can write a design function that uses async and it just works. This would not be something that could be used for engine-react since React components are not allowed to be async.

From what I see, this specifically happens (from what I gather in the photo) because of a combination of things. That design function has to read the image being loaded, which in a way timeouts the call for done, and if we change values in the UI very quickly, like moving the slider very fast (without debouncing), then multiple calls for done with different canvas lineup together with the most recent call for the engine, and the canvas engine doesn't know how to handle that.

A simple tweak would be clearing the content in the root element of the iframe for each frame/done call.

Also, unrelated, did you load a picture of your ID? lol

Ah, I see. That actually makes sense in this case too, so that's probably what happened. And yes, I only had a picture of my passport and realized right when I was about to post this issue that it might not be a good idea to upload the screenshots unaltered 😂

Seeing this – might not be 100% related to the async question – made me think about the image input: Would it make sense to move the async image loading to that input? So a design function is always passed a base64 image it can use immediately?

I think this would make design functions a bit cleaner as it would remove user code to turn the FileBlob into an image they can work with.

I just tried the above approach and this would actually lead to exceeding the local storage quota really fast 📦🥸

Yeah that's the original reason we didn't do it that way. It somehow needs to involve uploading the image somewhere and keeping a reference to it. We've discussed a couple of times in the past about maybe adding a config prop that gives the auth credentials for an S3 bucket or Dropbox folder to make this happen as an option for better image handling.