Custom fields

[rgesulfo]

Disclaimer: This RFC is at an early stage and covers only high-level requirements. We are hoping the community can help us identify and spec the technical requirements. Thank you in advance for your help.

You can read it here.

[derrickmehaffy]

Some immediate questions that come to mind is how is the backend handling this, say with pagination, filtering, field selection, ect.

[sunnysonx]

Some immediate questions that come to mind is how is the backend handling this, say with pagination, filtering, field selection, ect.

The custom fields feature is more about the "frontend". So all the backend functionalities should work the same because schema doesn't change. Even if you have Shopify products as in the example, these will be stored in a json field.

[esiao]

Very excited about this feature, loved the presentation at today's conference. I love that you have already identified some use cases and are building ready to plug Custom Fields. What I'd love to know is if like plugins we'll be able to code our own custom fields and consume them in the Content Builder?

[rgesulfo]

Very excited about this feature, loved the presentation at today's conference. I love that you have already identified some use cases and are building ready to plug Custom Fields. What I'd love to know is if like plugins we'll be able to code our own custom fields and consume them in the Content Builder?

Hi Aurélien, Thank you for your message :) You are absolutely right. The goal is for anyone to install custom fields (via plugins or else) in Strapi, set them up in the Content-Type Builder, and used them in the Content Manager. Would you be open to sharing your use cases, even if similar to the examples? Thank you :)

[soupette]

Very excited about this feature, loved the presentation at today's conference. I love that you have already identified some use cases and are building ready to plug Custom Fields. What I'd love to know is if like plugins we'll be able to code our own custom fields and consume them in the Content Builder?

Yes you will be able to! The Custom Fields feature will allow plugins developers to create new fields which they could submit to our Marketplace. Once the package validated the Custom Field plugin will be available for download in our in App Marketplace and when installed in a Strapi App users will be able to select the Custom Field directly from the Content Type Builder plugin and then consume it in the Content Manager.

[jlfetter1]

This is very exciting. Do you have any idea as to when this feature will be available?

[Krislunde]

Any chance we might see conditional fields in this feature? Something like Fields B and C are only shown if Boolean Field A is true, for example?

Would it enable things like enumeration fields with labels?

Red | #FF0000 Blue | #0000FF etc.

Where only the label is shown in the select field in the admin panel, but the value is saved for the REST response.

[esiao]

@rgesulfo, @soupette thank you that's beyond exciting. Coming from the WordPress + ACF Pro combo what I've been missing is a few fields that I have a use for in most projects. So far I had to use turnarounds in order to meet my expectations with Strapi.

Here are a few of the ones I'm thinking of from an editing experience perspective:

• Link: Allows connecting to an entity and outputs the slug + a configurable title. This is useful when creating links between pages. So far I have a component setup for that with just two simple text inputs. Ideally, it should be a search with autocomplete to find a resource, pulling its slug. The title would just be a regular text field and then a target one if it needs to be _blank for example.

• Relationship: Strapi has relations that are perfect in a web-app environment as we create relations between two content types. In a Website setting, it's a little less ideal. Since we are talking about content rather than relation what I've been missing is a way to order these relations, the workaround is to create a repeatable component. And also being able to select more than one content type. (for example mix press articles and regular articles). ACF's relationship field has a really good UX and that would be what I'd expect.

• Tags: Just have a tag input type field that functions similarly to Relations one just a different UI output.

• List: Similar to the Enum field but a bit different. ACF has a great feature with their List field because you can have a text value and an option value which means you can have something like: [ { value: hello_world, text: Hello World } ] which would allow controlling the displayed text from the Back-End rather than the Front-End.

I have created some plugins for internal use on projects and would be happy to help develop these custom fields.

Another thing that I think we should consider is if Custom Plugins could also rely on Custom Fields, for example using the new Color Field inside a custom-built Admin page.

[derrickmehaffy]

Any chance we might see conditional fields in this feature? Something like Fields B and C are only shown if Boolean Field A is true, for example?

Would it enable things like enumeration fields with labels?

Red | #FF0000 Blue | #0000FF etc.

Where only the label is shown in the select field in the admin panel, but the value is saved for the REST response.

Probably not in this feature but that is one feature request that comes up quite often :)

[roelbeerens]

This is nice! I'm curious about the way the data will be stored, but I think that will be added later.

[rgesulfo]

Some immediate questions that come to mind is how is the backend handling this, say with pagination, filtering, field selection, ect.

These are good points. We don't have a clear answer yet (some of the solution could come from supporting other field types/formats). To move forward as quickly as possible on this, we are thinking to forgo them in the list view for now. Or to treat them as Strings (ex: filtering hex values or google maps URLs). We could also leave the developers to handle how their custom fields should be handled by the filters and search.

@soupette @alexandrebodin feel free to jump in on this tech topic :)

Thanks

[rgesulfo]

This is very exciting. Do you have any idea as to when this feature will be available?

Without overpromising anything, we can tell you the Expansion squad will start working on a beta version this quarter :)

We are hoping to share more updates in the coming weeks.

[rgesulfo]

This is nice! I'm curious about the way the data will be stored, but I think that will be added later.

That's a very interesting topic indeed. We're hoping to keep things simple for now without worrying too much about how data is stored. At first, it could be JSON only. But later on, we could potentially store meta data (ex: title, duration, preview, etc) from a Youtube URL to not have to fetch the data all the time the field is displayed and be able to serve this content through our endpoint.

Feel free to share some ideas on the matter if you want :)

Thanks for your question.

[b-barry]

Hello all,

I would like to add my 2 cents to this conversation.

I think that in terms of implementation, Strapi should look at GraphCMS (https://graphcms.com/docs) which is very close in terms of management (code). We should take the good ideas that it proposes:

• add defaults fields :

Color (https://graphcms.com/docs/api-reference/schema/field-types#color) which would have the following format:

type Color {
  hex: Hex! # Returns a String in the format of #ffffff
  rgba: RGBA! # r, g, b, values as RGBAHue!, and a as RGBATransparency!
  css: String! # Returns in the format of rgb(255, 255, 255)
}

Location (https://graphcms.com/docs/api-reference/schema/field-types#location) which would have the following format:

type Location {
  latitude: Float! # Geographic coordinate (north-south position on Earth)
  longitude: Float! # Geographic coordinate (east-west position on Earth)
}

Enumerations (https://graphcms.com/docs/api-reference/schema/field-types#enumerations) but I'm not convinced by the latter

The addition of the first 2 would allow to satisfy the Color picker and Map usecase.

For the data storage, they will be put directly in the database since it is static data.

Now for the videos, e-commerce usecase I propose to keep the plugin approach which can add fields that are just extensions of the base fields. GraphCMS calls them UI Extensions (https://graphcms.com/docs/ui-extensions/field-extension/quickstart)

I think we could take up their extension statement:

const declaration = {
  extensionType: 'field', // In strapi it will be a plugin type maybe, I don't know
  fieldType: FieldExtensionType.STRING, // In strapi it be one of the default type
  features: [FieldExtensionFeature.FieldRenderer], // in strapi it where the plugin will be display or features of the plugin
  name: 'Hello UIX World', // In strapi, it is the plugin name
  config: { // In strapi, it is the plugin config to be able add custom key etc. Only issue with that it is should be stored securely
    API_KEY: {
      type: 'string',
      displayName: 'API Key',
      description: 'API Key for this UI Extension',
      required: true,
    },
  },
};

Configuration display in GraphCMS

All the management of UI could be managed using the Strapi design system and some react context. You can read more here and examples here

With UI Extension we can handle usecase for Video and E commerce. The data will be stored directly to the database and because it is a extension of some type, the backend layer will not change. For the UI extensions, I will suggest to add two last feature for the case of JSON stored in the database:

• We should be able to define a schema for the json :
  • if you are using the GraphQL, Strapi will replace JSON by the type directly so we got type safe
  • if you are using Content Manager, you could do some validation based on this schema and block the saving. So better data quality
• We should be able to transform the data before saving it in the database. Why? imagine I install a plugin for Shopify that provide a product picker. By default, when I select the product it will take snapshot of the product and store it. But in my custom type, I am using a string field because I only want the productId to avoid stale data. With the transform, we could just pick the data that I need from the plugin response and respect my string field

Based on the transform usecase above, UI extension for e-commerce solve one part of the problem. Indeed, most of the time when we use this kind of plugin, we only store the ID and on the backend, we do the fetching of the linked data to be sure to always have the last update. This usecase opens the way to a last type of custom field: Remote Field. Again GraphCMS Remote fields (https://graphcms.com/blog/working-with-remote-fields) provide us a nice configuration that could fit perfectly in Strapi.

Remote field solve the URL usecase in the RFC.

First, we define a Remote Type Definition

{
    // In GraphCMS it is a GraphQL schema but in Strapi it will be a content type schema for example
    definition:
        "type CommerceLayerSimple { code: String, name: String!, formatted_ammount: String!, available: Boolean }
    displayName: "Commerce Layer Simple", // Name in the plugin maybe ?
    description: "Information from the Inventory Management",// Description in the plugin maybe ?
}

Then, we are adding a Remote Field that we call Inventory

{
        apiId: "inventory", // Name of the Field in plugin maybe ?
        displayName: "Inventory",  // displayName in the plugin maybe ?
        remoteConfig: { // Configuration to execute the HTTP call
            method: "GET",
            payloadFieldApiIds: ["productId"], // an existing Strapi field (in the content where the the remote custom field is defined) that is used to pass its value as an argument to the remote API call
            returnType: "CommerceLayerSimple", // The return type of the remote field. In this case, it is our custom CommerceLayerSimple type. It is defined above
            url: "<YOUR_REST_ENDPOINT_HERE>", // Url to the endpoint
            // or we could add request function and let the developper handle the stuff
            request:async(payloadFieldApiIds): CommerceLayerSimple =>ReturnYourPromise
        },
}

Once an API call is issued to the Strapi backend and you request a remote field. Strapi will execute the remote config HTTP call and the JSON response contains fields with those names and types, the values of those fields will be returned, from CommerceLayer, in the Strapi response of your content API, without the content itself being created and/or duplicated into the CMS.

I hope with that we could be make Strapi perfect for all extension.

Thanks for reading

[WiktorG]

Hello guys - any predictions when this feature may be added to main version of Strapi? 🤔

This has been something I've been thinking about for a long time! :D

[derrickmehaffy]

Hello guys - any predictions when this feature may be added to main version of Strapi? thinking

This has been something I've been thinking about for a long time! :D

Sooner than you think :wink:

[stafyniaksacha]

Hey @rgesulfo @derrickmehaffy @soupette here are some questions:

• How will it look like in the api schema config? Can custom-field's developers be able to add options to the attributes config (like enum property)
• Can a custom-field be a group of attributes? (like a "virtual" component that just nest fields)
• Can we set custom validators? (like defaults yup validators in strapi/lib/services/entity-validator/validators.js)
• Can we set how our field can be queried? (like in utils/lib/parse-type.js)
• Will it be possible to customize how our field is mapped for each dialect? (like in database/lib/dialects/postgresql/schema-inspector.js)
• Can we will be able to set parser/stringifier from db storage? (like defaults in database/lib/fields.js)

[stafyniaksacha]

I have a use case with https://github.com/strapi-community/strapi-plugin-local-image-sharp

We may want to create a new field based on an image field (like slug is bound to a text field) to create different formats.

In this field, we can select multiple format on the admin ui (different size, in different format, etc...). Those settings should be set on the Content-Type Builder and not on the Content Manager. Like we select types of files that can be uploaded.

This can not be done in a stand-alone package since we need to perform these image manipulations on server.

We also need to alter responses to include our new images data

[rgesulfo]

I have a use case with https://github.com/strapi-community/strapi-plugin-local-image-sharp

We may want to create a new field based on an image field (like slug is bound to a text field) to create different formats.

In this field, we can select multiple format on the admin ui (different size, in different format, etc...). Those settings should be set on the Content-Type Builder and not on the Content Manager. Like we select types of files that can be uploaded.

This can not be done in a stand-alone package since we need to perform these image manipulations on server.

We also need to alter responses to include our new images data

Hi Sacha,

Thank you for sharing your use case. It definitely picked my brain so much that I had to make some designs to look at how we could accommodate it in our vision.

Let me know if this is clear enough and could solve what you are describing.

Thank you for your help :)

[am2222]

I like this idea but this is just ui level field. What if we want to support database types? Like geometry and geography type? If CTM give access to the plugins to validate and convert field data it will be perfect. Geojson is perfect but does not open our hands to query data in database using gemetry functions. We can convert geojson to geometry and query them but still it is one extra layer.

[strapi-bot]

This pull request has been mentioned on Strapi Community Forum. There might be relevant details there:

https://forum.strapi.io/t/discussion-regarding-the-complex-response-structure-for-rest-graphql-developer-experience/13400/76

[alexandrebodin]

Closing this RFC as we got enough feedback and merged the implementation one :)