Store icon, labels, and input options for types on the backend

[pavish]

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:

• Icon information (Links or base64 encoded icons. Links to an svg file would be best)
• Universal Input options (Input used within table, filters, groups etc.,)
  • Type of input (depends on the db/mathesar type. Boolean has be a checkbox, while text has to be text input).
  • Label for input
  • Id for input (to use as key while making requests)
  • Validation options for custom types (eg., regexes need to be specified for email type. The input would be a text box, and additional validation needs to happen over it)
• Feature specific input options (If there is a different UX for specific purposes eg., for filtering/grouping, the representation for that should also be covered)
• Type options (what database options a type accepts)
• Whether we support default values for the type

Related

• https://github.com/centerofci/mathesar/discussions/1035#discussioncomment-2087528

[kgodey]

Marking as draft until the spec for how to represent things is fleshed out.

[kgodey]

Assigning to myself to flesh out backend implementation.

[seancolsen]

@kgodey @pavish

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.

[kgodey]

@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.

[pavish]

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.

[seancolsen]

@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 types API returns an response like this:

[
  {
    "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.

[kgodey]

@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.

[github-actions[bot]]

This issue has not been updated in 90 days and is being marked as stale.

[dmos62]

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).

[kgodey]

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.

[kgodey]

Closing this, too old, requirements are out of date. We can create a new issue if we need this functionality in the future.