-
Notifications
You must be signed in to change notification settings - Fork 23
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
Playground style updates #3182
base: main
Are you sure you want to change the base?
Playground style updates #3182
Conversation
…ggle * 'main' of https://github.com/quantified-uncertainty/squiggle: bundle outputs entire dist/ copy *.node during bundle
🦋 Changeset detectedLatest commit: db6de0c The changes in this PR will be included in the next version bump. This PR includes changesets to release 7 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
* style-updates-april-2024: Lint fix Adding codeBracketSquareIcon to variable card Make code bracket square icon an outline Refactors to variable versions bar Improving model card them, Entity Card Minor model updates Minor cleanup Quick first pass at new model cards
* style-updates-april-2024: Formatted Remove prettier-tailwind Added tailwind-prettier to root package.json More card cleanup
* style-updates-april-2024: Added keys, to fix linter Fixed breaking of components Badge -> EntityCardBadge rename Added interspersedMenuItems Applied prettier, with tailwind-prettier Added prettier-plugin-tailwindcss delete dockerfile
|
||
const CHANGELOG_URL = "https://www.squiggle-language.com/docs/Changelog"; | ||
|
||
export const SquigglePlaygroundVersionPickerDropdown: FC< |
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 changed this from SquigglePlaygroundVersionPicker
, so that it could be called with custom children. The playground/website want to call it with CSS based on the Playground, which gets messy when it's attempted to be coupled with this component directly.
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 not sure I understand the problem, and I see issues with this new approach:
- you had to duplicate more code in website and hub
- I see that you import
PlaygroundToolbarItem
from@quri/squiggle-components
in the website and in the hub, so it's unversioned, and not future-proof: when the playground design (e.g. toolbar background color or height) changes again, both website and hub would have to be updated somehow, and it might get messy
It's possible to export PlaygroundToolbarItem
through versioned-components, but that's a headache.
The playground/website want to call it with CSS based on the Playground
If this is some technical issue that you encountered, maybe with Tailwind or with CSS inherited, maybe we can find another way to fix it?
* style-updates-april-2024: Minor cleanup <pre> tag in initial CodeSyntaxHighlighter
TODO:
|
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.
General meta-level comments:
- I understand that design is partially subjective, so I'm trying to limit my comments to the aspects that I think can be argued "objectively" (i.e., affect the usability in a way that I can describe), and this sometimes makes me to spell things out more than necessary, sorry about that
- also some of my objections might be caused by old habits; so I expect that I might eventually update in the direction of "ok, this is actually fine/better than before and I overreacted" about some parts of these changes, but not all of them
- as an example, pre-0.9.0 triangles in the viewer look uglier to me now than they did at the time; OTOH, I still don't like how tiny the post-0.9.0 carets are
- please just ignore my objections that you consider unfair/misguided; probably better to just proceed BDFL-style than spend much time looking for the middle ground, in this case
One more thing: there's a weird and quite annoying bug somewhere in this PR, that makes the first line in the editor to be unselectable. No idea why, maybe some invisible element from the toolbar bleeds into the editor area?
Die4Icon, | ||
Die5Icon, | ||
Die6Icon, | ||
}; |
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.
We can make this type-safe:
- add
as const
, remove explicit Record type on top (but addsatisfies Record<string, FC<IconProps>>
to make sure that all values conform to the same interface) - extract name type with
type IconName = keyof typeof allIconsMap
- use that type instead of string in
name: string
below
const IconComponent = findByName(name); | ||
|
||
if (!IconComponent) { | ||
return null; |
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.
Throw instead of returning null? (especially if we make things more type-safe, as I recommend above)
@@ -37,15 +37,15 @@ export const Button: FC<ButtonProps> = ({ | |||
className={clsx( | |||
"border text-sm font-medium", | |||
theme === "primary" | |||
? "border-green-900 bg-green-700 text-white" | |||
: "border-slate-300 bg-slate-100 text-gray-600", | |||
? "border-emerald-600 bg-emerald-500 text-white" |
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.
The old color was probably too dark, but this one is giving me a bit of eye strain. Can we boost it to emerald-600 by default?
The contrast is 2.53 (I had to patch HTML a bit to convince Chrome to show me the value).
The typical recommendation is 3:1:
(reminder that we're both on macs; people with worse displays will have harder time with it)
? "border-green-900 bg-green-700 text-white" | ||
: "border-slate-300 bg-slate-100 text-gray-600", | ||
? "border-emerald-600 bg-emerald-500 text-white" | ||
: "border-gray-300 bg-gray-50 text-gray-500", |
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.
Non-primary version is more readable for me, but gray-500 looks borderline disabled. Maybe it'll be ok in the context of other UI, I'm not sure.
wide && "w-full", | ||
size === "medium" && "h-8 rounded-md", | ||
size === "medium" && "h-8 rounded-sm", |
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.
Glad to see that small and normal buttons have the similar style now.
<SaveButton onSubmit={onSubmit} disabled={inFlight} /> | ||
<SaveButton | ||
onSubmit={onSubmit} | ||
disabled={inFlight || !codeHasChanged} |
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.
codeHasChanged
is not enough, we also save the seed, environment, and other things.
Comparing all those properties might be a headache. (Ideally, all of them would be managed by react-hook-form, and then we could use form.formState.isDirty, but that's tricky with our current implementation)
There's a workaround where you could insert a new line, but that's hacky.
Also:
- I've been hearing how disabling buttons on forms is a bad practice (I'm still not totally convinced, but that's a very common opinion).
- The "Saved" toast appears in the far corner, so there's now no obvious feedback that the model was saved (that toast could be improved, but it'll take a while)
Proposal: instead of disabling, pass a flag that would toggle from theme: "primary"
to theme: "default"
?
)} | ||
onClick={handle.toggleCollapsed} | ||
> | ||
<Icon size={13} /> | ||
<Icon size={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.
The clickable area is now 16x9, while it was 16x13 in v0.9.3. If the icon is smaller now, is it possible to add vertical padding to the clickable div around it?
isFocusEnabled && "cursor-pointer hover:underline" | ||
)} | ||
onClick={() => isFocusEnabled && zoomIn(valuePath)} | ||
> | ||
{title} | ||
</div> | ||
{showColon && <div className="font-mono text-gray-400">:</div>} |
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.
Lack of colon makes it harder to interpret the results:
In general, I'm concerned about optimizing UI by removing things that are visual cruft when you're an expert at the playground and understand which element is which, but that were very helpful for people who don't understand yet what's going on.
This specific case is minor, though, and I'd prefer that we wrap array indices in []
instead of using colons. Also it's less of a problem than this (which is a problem both in this PR and before):
onChange(newValue: boolean): void; | ||
}; | ||
|
||
export function StyledToggle({ |
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.
You don't use this anywhere and don't export it, was this intended for replacing "Autorun" in the future?
|
||
const CHANGELOG_URL = "https://www.squiggle-language.com/docs/Changelog"; | ||
|
||
export const SquigglePlaygroundVersionPickerDropdown: FC< |
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 not sure I understand the problem, and I see issues with this new approach:
- you had to duplicate more code in website and hub
- I see that you import
PlaygroundToolbarItem
from@quri/squiggle-components
in the website and in the hub, so it's unversioned, and not future-proof: when the playground design (e.g. toolbar background color or height) changes again, both website and hub would have to be updated somehow, and it might get messy
It's possible to export PlaygroundToolbarItem
through versioned-components, but that's a headache.
The playground/website want to call it with CSS based on the Playground
If this is some technical issue that you encountered, maybe with Tailwind or with CSS inherited, maybe we can find another way to fix it?
(95% of this can be reviewed now, but still have some small adjustments to make)