Use of "\n" instead of custom onSubmitCustomKeyboard block

[dm-zharov]

Just FYI:

Call of textDocumentProxy.insertText("\n") should be used to confirm typing. This could help to get rid of .onSubmitCustomKeyboard closure implementation and switch back to native .onSubmit.

[paescebu]

@dm-zharov Very nice to know! Ill think what i can do with it. Surely we don't need to pass logic for the submit button, BUT a quick test showed that the current solution is a bit more flexible. Using textDocumentProxy.insertText("\n") when an "enter" button is tapped makes the keyboard move away and pop up again in a form, while using the current solution gives you the possibility to still define a different behaviour.

My thought is, to change "onSubmit" to directly use your proposal so that the native "onSubmit" modifier can be used, but additionally provide a closure in the builder that has one more parameter for custom actions, should onSubmit not suffice (essentially do what onSubmitCustomKeyboard is providing and rename it to something more generic.

What do you think about this?

[paescebu]

@dm-zharov Heres a branch where i am experimenting with that thought, would be awesome if you'd let me know what you think! feature/introduce-passing-custom-action-and-allow-native-submit-handler

[dm-zharov]

@paescebu Current solution is more flexible, that's true. "Move away and pop up again in a form" is native behavior for system keyboard starting from iOS 16.0 (yes, it's awful).

I tried to find a way for implementation of additional closure, but didn't succeed. Maybe this logic should be inside custom keyboard?

[paescebu]

@dm-zharov have you tried my suggested branch? There I added a separate additional (optional) closure that can be used in the KeyboardBuilder so that we can keep the flexibility. Just add one closure parameter in the trailing closure. 'onSubmit' is replaced with native behaviour. And the respective modifier deprecated.

[dm-zharov]

@paescebu I think it's better to leave one submit closure in custom keyboard builder (as it was before). If custom closure is not provided near textField code, then insertText(\n) is called.

That behavior should be chosen on caller side via modifier. onSubmit – for native return key press handling, or onCustomKeyboardReturnKeyPress – for custom handling of return/submit button.

• It's not required to use native onSubmit modifier, so that makes usage of library easier. Just create keyboard and that's all.
• Do you want to handle keyboard submit? Use system onSubmit/onSubmit(.text, .search) as it described in native documentation.
• Don't like native submit behavior of keyboard dismissal? Use .onCustomKeyboardReturnKeyPress { }.

[paescebu]

@dm-zharov Love your inputs! I'll think about it. Not sure yet of the idea to introduce modifier that could conflict with the native 'onSubmit' modifier. What would be the expected behaviour from the lib user if both modifiers are used? Might keep the closures and their appropriate modifiers separate. I usually don't like to outsmart the user. But in this case it could also be fine.

Have to think about it. But really valuable feedback. Keep the ideas coming!

[paescebu]

@dm-zharov What do you think about this branch? https://github.com/paescebu/CustomKeyboardKit/tree/feature/implement_custom_submit_modifier_to_override_native_submit_behaviour_completely

• onSubmit modifier to use the native onSubmit callback
• if you want to override it completely you use onCustomSubmit
• make onSubmit as a closure parameter from the CustomKeyboardBuilder non optional as by default theres always a closure.
• if both modifiers are used, onCustomSubmit takes precedence

The longer I think about it the more I like the approach you tried to get me into.

let me know about your thoughts

Have a great weekend Pascal

[paescebu]

Closed as its now implemented with 1.0.3

[dm-zharov]

Please excuse me for not responding sooner. I do like updated implementation.