Loss of focus when using inputs in Fable React

[bruinbrown]

I'm currently working on Fable React bindings for the Kendo React controls. One of these components is a Grid which is a defined React component taking in among other props an array of data and an OnItemChange callback. The OnItemChange callback is used for handling changes to any row in the data array. This can then update the data array and be fed through to the grid through the props, all very elmish style and this works well.

However, when I compare the Fable version to the JavaScript version I'm seeing some slightly different behaviour in that on any input change the Fable version loses focus on the input and this causes the cursor to jump to the end. In the JavaScript version, as can be seen here (https://www.telerik.com/kendo-react-ui/components/grid/editing/ and click open in stackblitz) (Also the example on the telerik site exhibits the same problem as Fable whilst the StackBlitz example does work) when editing the name field the cursor stays in the correct position.

I raised this as a potential issue in the Telerik forum and have received a response that this is likely something stealing focus. Thread here https://www.telerik.com/forums/kendo-react-grid-edit-behaviour-in-examples This Gist is a minimal reproduction of the issue. https://gist.github.com/bruinbrown/8fa09d22728bf53104935b010812a31b and can be tested by overwriting the Client.fs and package.json files in a new SAFE template.

Is this issue likely something happening within Fable React? Or is this problem limited to the implementation of the control in Kendo? If it is happening within Kendo is there any way to mitigate it?

[MangelMaxime]

Hello @bruinbrown this is probably the same problem that people have when working with input by using Value and Program.withReactBatched seems like React don't handle correctly the Raf requests or they are messing up with it.

You can try using Program.withReactSynchronous which don't try to optimise high rates of message/rendering.

[bruinbrown]

@MangelMaxime Thanks Maxime, using withReactSynchronous fixes the issue. What is the underlying difference between withReactBatched and withReactSynchronous?

[MangelMaxime]

• withReactBatched trigger the rendering at most at 60fps. So if you have 120 messages in one second, it will trigger 60 render calls.

• withReactSynchronous trigger the rendering each time you have a message in your application. So if you have 120 messages in one second, it will trigger 120 render calls.

Note that in theory, React is already having a way to optimize quick draw so in most of the case you probably don't need the optimisation.

Closing as the problem is known and have a solution.