-
-
Notifications
You must be signed in to change notification settings - Fork 359
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
Homepage UI #3711
Homepage UI #3711
Conversation
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.
Mostly looks great!
I added some inline comments. Also:
-
I didn't like the global CSS you had in
ConnectDatabaseModal
so I pushed aa42c52 to refactor it out.I've said this before, but I'd prefer that we avoid global CSS whenever it's easy to do so. And this is a case where I think it's pretty trivial to avoid.
The changes I pushed did alter the spacing of some things in minor ways, but I can see that the spacing in your version didn't match Figma pixel-for-pixel so I think we're okay. In fact, I'd say that the Figma spacing is actually a bit wonky.
In contrast, the global CSS in
InstallationSchemaSelector
is fine with me. Ideally we wouldn't have the global CSS there either, but that's harder to change, so I see it as an okay compromise to make for the sake of speed.I've not been super happy with the abstractions that Svelte gives us to handle styling like in
InstallationSchemaSelector
. I'm curious if it will improve in Svelte 5. In particular I'm wondering if snippets will help. For example it would be neat ifCheckboxGroup
could accept an optional snippet for itsul.options
element. Then we could pass in a snippet containing an entireul
element (with a CSS class). If this actually works, then I think it could become an incredibly powerful way to build low-level components which can be easily styled. I'm looking forward to playing with this at some point. -
I also made a few other minor changes in aa42c52:
-
I changed the left-most grid column to be
auto
instead of hard-coding it as100px
. (That way it's more adaptive to other code changes, and not reliant onpx
units, which I prefer to avoid.) -
I removed superfluous
<div class="icon-holder">
element andclass="content-holder"
attribute, simplifying the markup.
-
I'd like to give it one more quick look before we merge.
mathesar_ui/src/api/rpc/databases.ts
Outdated
id: number; | ||
name: string; | ||
server_id: Server['id']; | ||
} | ||
|
||
/** | ||
* TODO: Figure out a better place to move classes like these. |
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 like this idea, but I have some different opinions regarding the rules. It would be nice to chat about this on a call.
Also, it's nice seeing this sort of proposal written down, but process-wise I don't like using code comments as a discussion channel. I'd prefer to use a wiki PR or github issue.
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 could resolve this in the proposal PRs and on call. I've removed the discussion code comments.
* } | ||
* ``` | ||
*/ | ||
export class Database implements DatabaseResponse { |
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'd like to put this code somewhere else, and I support putting it in @mathesar/models/database
. That move doesn't necessarily need to happen in this PR though.
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'd like to make any change related to this after we figure out the store structures from the proposal PRs.
readonly server_id: number; | ||
|
||
readonly server_host: string; | ||
|
||
readonly server_port: number; |
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.
Can we use a single server: Server
property instead of three separate server_*
properties?
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'd like to make any change related to this after we figure out the store structures from the proposal PRs.
|
||
readonly server_port: number; | ||
|
||
constructor(databaseResponse: DatabaseResponse, server: Server) { |
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 curious why you chose a class for Database
(instead of an interface). I'd be inclined to use an interface since they're simpler and we don't have any methods. Maybe you foresee adding methods in the future? With an interface we'd lose the server id validation in the constructor, but that doesn't seem important to me. I don't have a strong opinion here though. Mostly just curious.
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 could resolve this in the proposal PRs and on call.
const role = requiredField(''); | ||
const password = requiredField(''); | ||
const installationSchemas = requiredField<InstallationSchema[]>(['internal']); | ||
const form = makeForm({ databaseName, installationSchemas }); |
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 makeForm
should include all the form fields. That way the "Create Database" button doesn't get enabled until all the fields are filled out. Was there a reason you left some of the fields out of the form?
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.
Good catch. I missed them while adding the fields. e6a70d9 fixes this.
Fixes #3687
This PR implements home page changes based on the new permissions designs
Note:
Reference: Figma file
Screenshots:
Checklist
Update index.md
).develop
branch of the repositoryvisible errors.
Developer Certificate of Origin
Developer Certificate of Origin