Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error UI changes j 2023 #2034

Draft
wants to merge 6 commits into
base: main
Choose a base branch
from
Draft

Error UI changes j 2023 #2034

wants to merge 6 commits into from

Conversation

OAGr
Copy link
Contributor

@OAGr OAGr commented Jul 11, 2023

Before:
image

After:
image

@changeset-bot
Copy link

changeset-bot bot commented Jul 11, 2023

⚠️ No Changeset found

Latest commit: d532204

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
Copy link

vercel bot commented Jul 11, 2023

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

Name Status Preview Comments Updated (UTC)
quri-hub ❌ Failed (Inspect) Jul 29, 2023 0:40am
quri-ui ❌ Failed (Inspect) Jul 29, 2023 0:40am
squiggle-components ❌ Failed (Inspect) Jul 29, 2023 0:40am
squiggle-website ❌ Failed (Inspect) Jul 29, 2023 0:40am

Copy link
Collaborator

@berekuk berekuk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand that adding SqType can be a lot of (easy, but annoying and repetitive) work.

So while I think that we should do it the way I suggest in my comment, we can merge this without it and clean it up some time later.

@@ -29,6 +29,7 @@
},
"dependencies": {
"@commander-js/extra-typings": "^11.0.0",
"@tailwindcss/typography": "^0.5.9",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

squiggle-lang shouldn't depend on tailwind, I assume (hope) that you installed it here instead of components by mistake.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I probably did, this was done quickly

</span>
<div className="inline-block">
<span
className="text-xs text-blue-500 cursor-pointer items-center flex border-b border-blue-700 border-opacity-50 hover:bg-red-200 leading-4"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(minor)

This html/css is more complicated than necessary, I think (haven't checked, builds are failing). inline-block not needed because parent is flexbox; leading-4 is weird too because it's always (?) a single line, vertical alignment is done with items-center on parent.

Maybe it's a consequence of using borders instead of underline? There's enough classes in Tailwind to style underline properly (https://tailwindcss.com/docs/text-decoration-color, https://tailwindcss.com/docs/text-underline-offset), though I'd just suggest something simpler and more similar to StyledLink, like hover:underline text-blue-500 decoration-dashed.

);
};
console.log(style, "STLYYE");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
console.log(style, "STLYYE");

{...props}
language={match[1]}
PreTag="div"
style={style["oneDark"]}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dark theme looks too intense to me, I haven't checked how it looks in the context of playground since builds are failing but I expect it would be distracting.

@@ -25,6 +25,10 @@ abstract class BaseValue {
return Object.assign(Object.create(Object.getPrototypeOf(this)), this);
}

toTypeString(): string {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you ended up not using this?

If you did, I'd be opposed to it, because generally it's not possible to infer type from a value; e.g. [3,4,5] type should be number[], not [number, number, number].

\`\`\`js
${defs}
\`\`\`
Was given **\`${givenFn})\`**`;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are some things in this file and your overall approach that I think we should do differently.

You serialize function definitions to parse them again later (with JS parser, but that part could be improved) on the frontend. This is lossy and fragile, and I suggest we expose full type definitions instead.

After this PR you already did changes that added SqLambdaParameter. On main branch, SqLambdaParameter exposes only typeName?: string, but we could extend it to expose SqType that would wrap FRType objects. Then, on the frontend, we could render it by recursively turning it into JSX (similar to SquiggleViewer, but much easier), with whatever styling we need.

This is not 100% straightforward because right now FrType doesn't expose tag like SqValue does, so you can't switch over it, but this can be changed.

Type definitions will also be useful in other places, not just stacktraces:

  1. in autocompletion menu:
Captura de pantalla 2023-11-20 a la(s) 13 39 10
  1. on hover in editor when we add type inference for user-defined values;
  2. in docs (it's possible to replace manually defined types in docs with <RegistryFunctionSignatures fn="Plot.dist" /> component for Nextra, if we expose function registry from squiggle-lang)

This also means that we'd have to wrap ErrorMessage in SqErrorMessage, with abstract base class and discriminated union over specific sub-classes; that seems useful to me, as we previously discussed that different error messages should have different fields, otherwise a single REOther would be enough for everything.

ErrorMessage could still be serializable to a string, e.g. for CLI; it's just that on web I think we shouldn't do object->string->parsed string conversion.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm on the fence about markdown in toString. errorTypeName seems good, but markdown would look weird in CLI.

Thoughts:

  • maybe we could render markdown (at least bold/italic) in CLI by using a formatter that turns bold and italic markup to color?
  • I still believe that we probably have too many ErrorMessage subclasses, and a single class with (message, errorType) constructor would be enough in most cases
    • it's easier to create a full message at the location that raises an error
    • multiple ErrorMessage subclasses are useful only if they have different fields (if we adopt my proposal about SqType from another comment)

@@ -18,6 +19,10 @@ export class SqFrame {
location() {
return this._value.location;
}

toTypeString(): string[] {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SqFrame doesn't extend SqAbstractError, and this method is unused.

@@ -6,6 +6,7 @@ abstract class SqAbstractError<T extends string> {

abstract toString(): string;
abstract toStringWithDetails(): string;
abstract toTypeString(): string[];
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Allowing arbitrary number of type strings here seems excessive, or maybe I don't understand the intention; I see that you join everything except the first item with dashes in components, and I'm not sure if you had some longer-term vision about when more than 2 elements would be useful.

The way I'd do it is something like:

  • abstract getType(): string for top-level error type; or, even better, change tag field to match that public name and use that in components
  • separate getSubtype(): string { return ""; }, with "" as a default and overridden in SqRuntimeError.

(I'm using get prefix instead of to prefix in both cases, as to suggests "represent an entire error object as a string", while type and subtype are parts of the object)

@OAGr
Copy link
Contributor Author

OAGr commented Nov 22, 2023

Looking at this again, I think it was trying to do too much for one PR. (This does make sense, it was experimental).

I think I might isolate some of the simplest parts for a PR to do soon, then might do some of it incrementally.

@OAGr OAGr mentioned this pull request Dec 5, 2023
@berekuk
Copy link
Collaborator

berekuk commented Mar 27, 2024

This PR seems too stale to merge now, can we close it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 🔖 Later
Development

Successfully merging this pull request may close these issues.

2 participants