mantine-react-table icon indicating copy to clipboard operation
mantine-react-table copied to clipboard

Add a table option for IME input

Open smallStall opened this issue 1 year ago • 5 comments

Thank you for creating a great library. I added enableIMEMode to table option. IME is an operating system program that enables users to generate characters not natively available on their input devices by using sequences of characters that are available to them. IME use Enter key as submit so the entered characters may be repeated twice in MRT.

https://github.com/KevinVandy/mantine-react-table/assets/91565962/99f868f1-9598-41ca-af73-cc8771a5fed9

smallStall avatar Jan 28 '24 11:01 smallStall

@smallStall is attempting to deploy a commit to the Kevin Vandy OSS Team on Vercel.

A member of the Team first needs to authorize it.

vercel[bot] avatar Jan 28 '24 11:01 vercel[bot]

I need to evaluate the best way to implement this.

KevinVandy avatar Feb 09 '24 18:02 KevinVandy

If you are using a Mac, you may prefer to add an additional input method as shown in the link below. If you select "Japanese - Romaji", the language input method switch “A” will appear in the menu bar of your mac. Switch to "あ" and type "ko" in MRT to get "こ".

https://support.apple.com/guide/japanese-input-method/set-up-the-input-source-jpim10267/mac

smallStall avatar Feb 10 '24 02:02 smallStall

On Windows I haven't been having any issues inputting in Japanese with the native IME. Maybe limited to Mac and its IME, or maybe a certain editing mode in MRT?

Edit: Seems limited to Mac and certain IME input methods. For example, if I enter れいしき and hit enter without doing anything else, I get duplicated input (can replicate on the MRT docs site). If I enter れいしき, hit space, select the kanji, then hit enter, there is no duplication.

So possibly, the branch change would cause unwanted effects for input methods beyond the very specific one described above (e.g. on Windows or when not hitting enter immediately after entering kana). Probably should be more investigation as to why the blur is causing duplication on Mac with that specific input sequence, rather than skipping the blur on every device and every input method.

GoldenChrysus avatar May 09 '24 00:05 GoldenChrysus

May be interested in this Stackblitz I put together: https://stackblitz.com/edit/vitejs-vite-pksfbb?file=src%2FApp.tsx Also a good reference of the event sequence: https://stackoverflow.com/questions/7316886/detecting-ime-input-before-enter-pressed-in-javascript

The only difference I notice with and without the blur is there is a final compositionupdate event missing with the blur. Presumably this event is the IME updating the input.

I was able to work around the issue using setTimeout(() => input_ref.current?.blur(), 0); although solutions like that always feel hacky. e.g. what if the blur still occurs before the compositionupdate?

I assume that when the blur happens immediately, there is no input for the compositionupdate event to be sent to. With the timeout, the timeout event propagates after the compositionupdate event.

A more elegant solution might be to detect that compositionupdate events are occuring on an input (i.e. we're dealing with IME input) and then wait for a compositionupdate event after the Enter keydown. Only then could we be sure it's safe to blur the input.

GoldenChrysus avatar May 14 '24 01:05 GoldenChrysus