Better Feedback on Query Status

[mcrascal]

This PR does two things:

1. Trigger invalidate on the data object for each page whenever queries have changed, and update their contents client side
2. Report on the status of the queries with "toasts" in the bottom right 2.

See below -- no hard refresh on SQL edits:

Still to do:

• [x] Some of our built-in components are not reactive to client side updates to the data object
• [ ] The set context operation in preprocess is also not reactive

[changeset-bot[bot]]

⚠️ No Changeset found

Latest commit: 0d803c06c7848021a2bd903aed25a93b82ae0e6a

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
evidence-docs	✅ Ready (Inspect)	Visit Preview	Nov 18, 2022 at 11:48AM (UTC)

[archiewood]

Cool - big improvement on the current "have to go back to my console to see if it's ready" experience.

Could you make it more obvious the that query is "running" when it's grey? I'm imagining that if I had a query that was taking a longer time to run eg Snowflake seems to take a while, then it might not be super obvious what all the grey boxes mean?

For example you could make the text say:

• working_query running and then
• working_query complete / failed

Or you could animate the toast with a ... or a spinner or something?

[archiewood]

Just had another thought while I was working in stackblitz. The server crashed and the only feedback was on the console.

The final part of the "feedback experience" that hasn't made it into the UI yet, is whether the server is running (or has crashed). It might be out of scope for this, but a little card popping up saying "Server crashed" would address this. (Obviously it would be best if the server never crashed silently - ie with no visual feedback, but it still does in some edge cases)

[mcrascal]

@eleweek

Picking up the conversation here. Three items outstanding to get this into main:

• [x] preprocess creates local variables for each query {query_name} in a way that is not reactive
• [x] tests aren't passing on this PR, in part because of this
• [x] merge conflict in __layout
• [x] Archie's build of indicating the status

[mcrascal]

@archiewood @ud3sh @hughess -- this is ready for review.

Would be helpful to get some additional tire kicking on this before we merge.

Thanks,