-
Notifications
You must be signed in to change notification settings - Fork 25
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
base: main
Are you sure you want to change the base?
Error UI changes j 2023 #2034
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
There was a problem hiding this 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", |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
console.log(style, "STLYYE"); |
{...props} | ||
language={match[1]} | ||
PreTag="div" | ||
style={style["oneDark"]} |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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})\`**`; |
There was a problem hiding this comment.
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:
- in autocompletion menu:
- on hover in editor when we add type inference for user-defined values;
- 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 fromsquiggle-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.
There was a problem hiding this comment.
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 aboutSqType
from another comment)
@@ -18,6 +19,10 @@ export class SqFrame { | |||
location() { | |||
return this._value.location; | |||
} | |||
|
|||
toTypeString(): string[] { |
There was a problem hiding this comment.
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[]; |
There was a problem hiding this comment.
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, changetag
field to match that public name and use that incomponents
- separate
getSubtype(): string { return ""; }
, with""
as a default and overridden inSqRuntimeError
.""
instead ofundefined
for the same reason as in Saving variableType and docstrings #2542 (comment)
(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)
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. |
This PR seems too stale to merge now, can we close it? |
Before:
After: