Don't use text input for all topic options

[tombentley]

Right now the compression.type configuration is an unpleasant UX. There is no up-front advice about what's valid, so the user either has to already know what are the valid compression types or has to make a mistake and get corrected (currently they have to click next to trigger the validation, which is even worse).

There is a case to hard code knowledge of the allowed value for this option as, for example, a drop-down list.

A similar comment can be made for message.timestamp.type.

There are also a few boolean typed options which might be better presented as a switch?

cleanup.policy is similar, but it's a list of two allowed values, so a drop-down isn't quite right.

[riccardo-forina]

This table is fully data driven, the UI had no domain knowledge at all about these properties.

Kafka provides us with some metadata, like if the value is a string or a list, but nothing specific about the allowed values.

In RHOSAK we had an hardcoded properties editor, but I'm concerned about its maintenance. What if in a newer release of Kafka a property changed to allow more values than what it allows today? Or a new property is added entirely?

[tombentley]

So it sounds like we should be able to have an on/off switch for booleans without much effort.

In RHOSAK we had an hardcoded properties editor, but I'm concerned about its maintenance. What if in a newer release of Kafka a property changed to allow more values than what it allows today? Or a new property is added entirely?

This is a reasonable concern. It's worth pointing out that:

1. It's pretty uncommon for a new Kafka release to add a topic config. So it's not like we're going to have to do lots of extra work for each release. Most of the time it's going to be simply asked the question "Were any new topic configs added? No? Then there's nothing to do here..."
2. CompressionType and TimestampType already have enums in Kafka. While they're visible to 3rd party code unfortunately they're not part of the public API. In principle they could change incompatibly between releases, but in practice this is not going to happen.

So I wonder whether putting that hard coding in the backend REST server changes the maintainability picture enough. We could accept the risk of using these non-public APIs for those cases where a public enum exists.

I do feel that this would be a really nice improvement in the UX.

Alternatively we could propose a KIP to add this info to describeConfigs(), but that would come with a long lead time.