Divider/Alias setup flow

[benhaynes]

The divider (and maybe all aliases or presentation types) should not have a "Default Value" or "Required" toggle. That's extra visual noise and might confuse users.

[benhaynes]

Also, the key is not _super useful here (nor the type), but we do have a title interface option. I wonder if there's a way to combine these?

Also, small request to move the title above the color/icon options. 👍

[benhaynes]

I wonder if there's a way to "auto create" a key (eg: divider-abcd) for these presentation interfaces that have "Hide Label" enabled. Then we could hide the key and type (always disabled)... which would only leave the interface options. Sounds cleeeeean!

[azrikahar]

I wonder if there's a way to "auto create" a key (eg: divider-abcd) for these presentation interfaces that have "Hide Label" enabled.

Does this fit the requirement here? Maybe we can bump it up to 8 random chars to further reduce possibility of collisions. (Though I wonder will this ever happen even for 6 chars anyways...)

Of course the above is just to show and confirm the randomly generated IDs. This should be the end result:

---

One question I do have would be is this the expected outcome?

Just wondering will the random chars be remotely "daunting" to non-technical users here. If it's deem not to, then I'll proceed with the current iteration with a PR. 👍

[benhaynes]

I love this!! Wondering if it would feel cleaner to do divider-1 (dropping the category to keep it shorter, and moving to an auto-increment index). Not sure how possible this is, since we'd need to loop over existing fields to see which number is not taken. Also, then when you reorder these, the numbers might be out of sequence (not an issue unless you're OCD).

I think if we remove the category (eg: presentation) and keep 6 characters, we should be good as-is!

Also, we should be able to allow editing the key (in the advanced editor) for presentation-only fields, since there's no data there... but that's a question for the future.

[rijkvanzanten]

I love this!! Wondering if it would feel cleaner to do divider-1 (dropping the category to keep it shorter, and moving to an auto-increment index). Not sure how possible this is, since we'd need to loop over existing fields to see which number is not taken. Also, then when you reorder these, the numbers might be out of sequence (not an issue unless you're OCD).

I think I would actually prefer going with the short hash here for this exact reason. Having divider-1, divider-3 and divider-2 in that order would kill me.

[azrikahar]

Also, we should be able to allow editing the key (in the advanced editor) for presentation-only fields, since there's no data there... but that's a question for the future.

Is this the expected "editing the key in advanced editor" here? Haven't modified anything since technically it's "hidden" on the new field flow area, but definitely still visible (and editable) in the advanced editor:

[benhaynes]

Ahh, true! Though I don't know if you can edit it after the field is created, even through the advanced editor.

[azrikahar]

ohh after it's created. Now I understand what the "no data" meant now 👍

Just tried to give it a shot, was able to apply the same "interfaces with hide label" logic to make the key editable, but unfortunately the API currently will hit an error, especially the "where field.field" (field.field being the key in this case) since it can't find itself as we updated the key. Of course this assumes if we don't want to introduce changes in these parts in the API for this added flexibility.

directus/api/src/services/fields.ts

Lines 293 to 313 in 975e0eb

	if (field.meta) {
	const record = await this.knex
	.select('id')
	.from('directus_fields')
	.where({ collection, field: field.field })
	.first();
	if (record) {
	await this.itemsService.updateOne(record.id, {
	...field.meta,
	collection: collection,
	field: field.field,
	});
	} else {
	await this.itemsService.createOne({
	...field.meta,
	collection: collection,
	field: field.field,
	});
	}
	}

[benhaynes]

I think we'll be adding the functionality to be able to edit any field key sometime in the future, so no need to add special logic now. 👍