-
-
Notifications
You must be signed in to change notification settings - Fork 316
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
Store icon, labels, and input options for types on the backend #661
Comments
Marking as draft until the spec for how to represent things is fleshed out. |
Assigning to myself to flesh out backend implementation. |
What's the rationale for delegating icon choice responsibility to the back end? I would think we'd want to leave that choice up to the front end. Maybe we want to refactor all the icons to improve visual consistency. Maybe we want to apply CSS to change the icon color in certain contexts. Maybe we want to serve the icons as inline SVG. While these would all be possible with icon choices in the backend, any icon refactoring would inherently involve the back end which seems weird to me. Are we planning to provide some kind of user-defined type system at some point? Perhaps that's the rationale? -- Because icons might be defined at runtime? Even in that case, I'd like to think through this choice a bit more before handing such a presentational responsibility to the back end. |
@seancolsen Yes, the idea is to provide a user-defined type system at some point. People might have all sorts of custom Postgres types installed on their database and they might want to implement custom functionality for those types. The idea behind this issue is to allow the frontend to be type-agnostic and load whatever types the backend offers with all the information it needs for each type. It would also be useful in case someone was building, for example, a mobile client for Mathesar and wanted to use the same types and UX as the web frontend. I too am iffy about delegating presentational responsibilities to the backend. I'd like to put this issue off until after the alpha release and think through it more. |
Having dynamic types would help us build and publish types separate to the product itself. Considering that the idea is to allow plugins in the future, this would be an essential step towards that goal. Users can install a plugin which offers customized type support. I understand the hesitation towards not wanting to place presentation elements on the backend, however the entire types endpoint is built specifically for the client to make use of. My opinion is that everything related to types (allowed filters, allowed grouping options, sorting options, cell validation, label, icon etc.,) has to be stored on the database, inorder for us to move towards a plugin backed architecture. We can think through this more. |
@pavish and I chatted about the icons issue on a call today, and he helped me understand more. As I understand it now, it's not users who define the icons for new types, but plugin authors. That sounds great to me. Pavish and I chatted about various approaches that would allow the API communicate information about icons to the front end. The approach that I like the best is one where the [
{
"identifier": "email",
"name": "Email",
"icon": {
"set": "fontAwesome",
"name": "envelope",
},
// ...
},
// ...
] We would then provide documentation to plugin authors on which icon sets we support and how to access the respective docs for each icon set to choose an icon. We'd begin by supporting only Font Awesome, but we could choose to add more at some point later on. To me, this approach strikes the perfect balance between giving the front end control over the presentation of the icon and giving the plugin author the ability to choose their own icon. If a time comes when plugin authors feel that their choice of icon is too limited, then could address that need at that point, for example by allowing them to add their own icon set from within the plugin. |
@seancolsen that makes sense, thanks! I've moved this to the API v1 milestone (which is scheduled for post-alpha). I don't think it should block our implementation of data types. |
This issue has not been updated in 90 days and is being marked as stale. |
Can we close this? There's not been any activity here for 2 years. I'm also under the impression that we've walked back on the goal of putting the maximum of information on the backend (which we wanted so that implementing a new frontend would be easy). |
I'll defer to @pavish but I'm in support of closing. I assume we can reopen or open a new issue if/when we prioritize this work. |
Closing this, too old, requirements are out of date. We can create a new issue if we need this functionality in the future. |
Requirements
The frontend should be able to dynamically construct the view for displaying type options. The information related to this should be stored and obtained from the backend.
The backend should provide a JSON representation of the display properties essential to construct the dom and make requests on the frontend. It should cover:
Related
The text was updated successfully, but these errors were encountered: