Runtime Discovery Editor

[nerik]

[netlify]

✅ Deploy Preview for veda-ui ready!

Name	Link
🔨 Latest commit	472d40c
🔍 Latest deploy log	https://app.netlify.com/sites/veda-ui/deploys/64ac213a96915e0008bdec14
😎 Deploy Preview	https://deploy-preview-551--veda-ui.netlify.app/
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[nerik]

This is the state of things:

Untitled.mov

I'd be interested in hearing your thoughts about the approach @danielfdsilva @hanbyul-here ... Now to tackle error handling

[hanbyul-here]

It is amazing to see how you approached this problem. Such an exciting prototype with a relatively small amount of code 👯 A few thoughts after playing with it. (Maybe too detailed at this point?)

I tried to make errors in various ways. I have found two ways to make errors so far. 1. MDX syntax level (ex. <> in the middle of the paragraph): error message displays below the code mirror editor 2. Component level error (ex. giving a wrong dataset id to Map component, give a not allowed combination to Block): this displays hinted error, leaving other parts of the page intact. As you said, a good next step will be error handling, including consolidating how these errors are handled. (A real quick workaround for 2. will be having a button like 'try again', but it prob goes against 'real-time' editing principle.)

A draggable code editor is a brilliant idea to work around some problems quickly. But while trying to edit, I realized that dragging is also needed for editing (duh) 🤔 maybe some mechanisms to unlock/lock the code editors dragging?

How do you picture the output of this editing process to be saved? Local files? GitHub?

[danielfdsilva]

@nerik This is quite an interesting approach and it's nice to get the immediate preview! :D

I spent some time thinking about the error handling, but it is not straightforward to do with the current block scoped approach.
I think the error handling for the MDX editor should be different from the rest. The whole error handling should happen at a higher level so it can be cleared once the content changes. (An idea that you had already mentioned) Each block would render their own error, but they would be captured and stored higher up.

I tried to see if we could compare the props of a given block and clear the error if they were different, but since the mdx get evaluated on every render, the components are always different even if the content did not change, so this approach is a no go.

[nerik]

@hanbyul-here @danielfdsilva This is ready for review. And merge if we all agree on #559 (comment)

This is new since we spoke last time:

• Content is stored on local storage to persist on page reload
• Added option to reset editor contents
• Block-level errors are properly handled: any error at this level will be caught by an ErrorBoundary, reported at the block site, and reset at each editor content update (and if the content is still faulty, the block will simply throw right away again)
• Global errors making the whole thing crash could in theory happen.
  • The only manner I managed to get this was when changing from no content to any content (or the opposite), because of a rules of hooks error. I've added a specific hack for this case (no empty string is allowed on the editor), there is a more elegant fix for sure, but this does the trick.
  • Any putative global error will lead to a fallback screens which offers to do a full page refresh with or without the currently saved content

[hanbyul-here]

Such an exciting change 👯

We can consolidate the diverged approaches to achieve a similar goal inside the applications. ex. Analysis page and MDX editor use both local storage but in different ways. + I wonder if we can just use ErrorBlockBoundary component for block error handling.

But I think it is more important to test this idea fast. so if you want to consider the integration with the existing architecture later, I am down with it.

[nerik]

@hanbyul-here

We can consolidate the diverged approaches to achieve a similar goal inside the applications. ex. Analysis page and MDX editor use both local storage but in different ways.

Interesting, we might even be able to have a pseudo "user parameters" page where a user could see saved AoIs, analysis params, discovery draft, etc... With the obvious caveat that this is tied to the current browser, which must be clearky communicated.

But I think it is more important to test this idea fast. so if you want to consider the integration with the existing architecture later, I am down with it.

Cool! Let's also see what comes out of #561

[danielfdsilva]

nitpick: all files and folders on veda follow the kebab-case syntax. Would be good to maintain consistency

[danielfdsilva]

The CRA overlay is still popping up. I'd suggest we change the selector to the following one so it is more generic. It is very unlikely that this would interfere with any other piece

body > iframe:last-of-type {

[nerik]

The CRA overlay is still popping up. I'd suggest we change the selector to the following one so it is more generic. It is very unlikely that this would interfere with any other piece

@danielfdsilva Fixed, although I was not able to replicate this.

[hanbyul-here]

Not a blocker, just a note so we know the quirks.

• the components that use the internal files (chart, image) don't work in the editor.
• the editor gets 'scrolled away' with scrolly map component.

but an exciting change! I look forward to getting some feedbacks.