Roadmap: Tabs Field Type

[jmikrut]

Description

Design and build a UI-only Tabs field type, which will allow developers to better organize their admin UI fields into a tabbed interface. Presentational only.

Implementation Detail

Will operate similarly to the existing row field type and have no effect on data whatsoever.

Potential Breaking Changes

None

Effort

Medium

[martibravo]

Hi, I haven't seen a commit or branch with a Tabs implementation, so I would like to make a proposal for the config of tabs. Instead of making it work like a Row, I think it would be nice to add a tabs property to the CollectionConfig type. I have worked with ApostropheCMS in the past and its implementation of Tabs in collection config is very easy to use and set up.

So instad of doing this:

fields: [
        {
            type: 'tab',
            label: 'About',
            fields: [{
                name: "name",
                label: "Full Name",
                required: true,
                localized: false,
                type: "text",
                index: true
            },
            {
                name: "role",
                label: "User Role",
                required: true,
                localized: false,
                type: "select",
                options: roles,
            },
            ]
        },
    }

I feel a much cleaner implementation would be to set a tabs config property like this:

fields: [...],
tabs: [
    {
        name: "main",
        label: "Info",
        default: true
        fields: ['name', 'role', 'email', 'privacy_consent']
    },
    {
        name: "subscription",
        label: "Subscription",
        condition: (data, sibilingData) => data.subscription_status !== undefined,
        fields: ['subscription_type', 'subscription_status', 'subscription_start', 'subscription_end', "payments", "coupons_applied"]
    },
    {
        // Set up the sidebar here so all position config can be in one place
        name: "sidebar",
        fields: ['picture']
    }
]

For rows and groups, it would be as easy as adding a name property to them and add them to the tabs in the fields property.

Why?

Because I think that with a combination of Tabs, Rows, and Groups the fields array will become convoluted, with unnecessary nesting.

[jmikrut]

Hey @martibravo — very interesting thoughts. Thanks for writing this up and sharing these ideas.

I believe however our implementation might be a bit more demanding than what your suggestion could facilitate. As of now at least, we are not envisioning tabs to be a top-level construct. Instead, we are thinking to be able to "nest" tabs anywhere you want—even deeply within your schema. For example, you could have a block that includes tabs. Here is what ACF looks like when you nest tabs within a block:

At TRBL, we did this a ton with ACF.

Because tabs should be able to be placed anywhere, the pattern you've identified would get quite a bit more complex. Also, we would need to consider that some fields are not named - i.e. row fields. There would be no way of identifying that a row field should be slotted into a given tab.

Does this make sense? I actually think that your first option, the one you're trying to avoid, is pretty seamless and follows existing patterns. Can you elaborate on what about it exactly is dirty to you?