Async subject causes incorrect behaviour of an input caret

[dmitry-korolev]

I've built simplest possible example, you can find it here: https://codesandbox.io/s/1y8rlnlp83

It looks like after an action is dispatched, actual emit of an action$ source happens in the next task, which causes the store to be updated too late. That causes React to directly set a value property of an input, which makes the caret to jump at the end.

An issue is neither with most itself, nor with react. I suppose the problem is in the async nature of most-subject.

[joshburgess]

Hmmm, I've built quite a few things with redux-most and haven't experienced that before. I actually built a production auto-complete search feature with it at a company and did not run into that problem, so I'm a little confused about what's going on here. I'll try to dig into your example soon.

If it's not some other sort of bug, and is, indeed, due to the asynchronous work in most-subject, there is an alternative sync version that we could switch to. When I first upgraded most-subject when they introduced the new async API, I tried both, but could not tell a difference between them.

Thanks for letting me know. Will try to look at it soon.

[joshburgess]

@TylorS167 thoughts?

[dmitry-korolev]

I forgot to notice that absolutely same setup based on redux-observable works as expected
https://codesandbox.io/s/0mj3lxy2qp

[joshburgess]

@dmitry-korolev I have confirmed that it is, indeed, an issue with the async subject in most-subject that I somehow overlooked. It must be in only specific use cases that this problem arises, as I've never actually ran into it before.

You can see that switching to using sync in the createEpicMiddleware.js file solves your problem and makes things work more predictably. See this forked version of your codesandbox project I created:

https://codesandbox.io/s/8n5owr4lml

However, it looks like most-subject has a new major version (6.0.0), which has another new API, and is intended to work with the new @most/core library. I don't yet have time to explore the API to see whether or not the same sync and async creation functions exist with different names. (I did try testing them both with most-subject@6.x.x, and they do not exist.)

I do plan to rewrite this library using @most/core soon, but I'm going to hold off on that for now and just continue using most-subject 5.3.0 while changing to the sync subject creation function.

Thanks again for letting me know about this problem!

[joshburgess]

This is fixed and in the new 0.6.3 release. Thanks, @dmitry-korolev