From now until KeyboardKit 11.0, KeyboardKit will start reducing namespace nesting, to move many types to the SDK root in order to increase discoverability. Expect fewer namespaces and more consistent naming.
This change will bring back Keyboard as a prefix for most features, except Emoji. This will make it even more obvious that e.g. KeyboardAutocomplete is autocomplete inside a keyboard, where Autocomplete is pretty vague. This will also reduce the risk of future name conflicts with native frameworks and models.
While most namespaces will be removed, the Keyboard namespace will remain to nest essential types that developers will still find while ing the framework. For instance, Keyboard.Case will be nested, while KeyboardSettings.Screen will be renamed to KeyboardSettingsScreen and moved to the SDK surface.
One reason why KeyboardKit started using namespaces was to avoid a huge type dump, where the DocC documentation would be hard to use. However, since each feature article now own its related types, this is less of a problem now than before.
Each feature namespace change will also adjust the related feature article, to better curate the available types in topics.
This ticket will be closed as part of KeyboardKit 11, when this will be done and the renaming deprecations will be removed. Until then, expect some renaming deprecations and to get some warnings to let you transition to the new naming.
This change will involve a lot of deprecations, so we will have to get everything done until the last 10.9 release, so we can remove all the deprecations in KeyboardKit 11. There will as such be no migration guides for these changes in 11.0.
From now until KeyboardKit 11.0, KeyboardKit will start reducing namespace nesting, to move many types to the SDK root in order to increase discoverability. Expect fewer namespaces and more consistent naming.
This change will bring back
Keyboardas a prefix for most features, exceptEmoji. This will make it even more obvious that e.g.KeyboardAutocompleteis autocomplete inside a keyboard, whereAutocompleteis pretty vague. This will also reduce the risk of future name conflicts with native frameworks and models.While most namespaces will be removed, the
Keyboardnamespace will remain to nest essential types that developers will still find while ing the framework. For instance,Keyboard.Casewill be nested, whileKeyboardSettings.Screenwill be renamed toKeyboardSettingsScreenand moved to the SDK surface.One reason why KeyboardKit started using namespaces was to avoid a huge type dump, where the DocC documentation would be hard to use. However, since each feature article now own its related types, this is less of a problem now than before.
Each feature namespace change will also adjust the related feature article, to better curate the available types in topics.
This ticket will be closed as part of KeyboardKit 11, when this will be done and the renaming deprecations will be removed. Until then, expect some renaming deprecations and to get some warnings to let you transition to the new naming.
This change will involve a lot of deprecations, so we will have to get everything done until the last 10.9 release, so we can remove all the deprecations in KeyboardKit 11. There will as such be no migration guides for these changes in 11.0.