Weird bug with data-text-as-pseudo-element + ::before

[MovingGifts]

It took all day to hunt this bug down and would love to find a solution.

It seems this bug is caused by the way this library renders RX.Text inside a RX.Button with data-text-as-pseudo-element + ::before combo.

To start, please use an iPad, open Safari, and then open a tab to any website you choose. Next, open a 2nd tab, and load the problematic React XP page) in the tab (code linked at bottom of post).

Now let the fun begin:

1. In the text input field on the top, type '123'.
2. You should see that there is:
   a. '123 People' that is just RX.Text
   b. '123' that is just white RX.Text in the orange RX.Button
   c. All works perfect so far.
3. Now click the other tab you have open, wait a few seconds, and come back to the testing tab.
4. Now, add '456' so it should read '123456' for both 2a and 2b.
5. It shouldn't have worked for the button, only for the text.
6. If it worked and you see '123456', try to add '789' after changing tabs with a few seconds wait.
7. The button will basically not render the full reactive text input value, even though if you inspect it, it will show that the entire string is indeed the value for the button's data-text-as-pseudo-element attribute.

I noticed that the text in 2a always matches the text input value correctly because it does not use the data-text-as-pseudo-element + ::before combo. I also noticed that once the button is not matching the text input after switching tabs and coming back and adding some more text, that flipping the iPad causes it to "correct" itself and match the text input value. So it seems it needs a reflow/redraw of the button to occur for it to update correctly.

Would love to hear your thoughts on what solution we can implement so that the button matches the text input value without having to flip the iPad.

Updated links to view in chrome:
Here is the full screen link to reproduce
Here is a link with code

NOTE: It loads much faster in chrome, so I recommend checking out the code there.

[MovingGifts]

Any thoughts on this?

[MovingGifts]

Bump.

I added the updated links in the original question, they load much faster in chrome if want to debug the code. Still need a iPhone/iPad w/ Safari to test the full screen rotation bug though.

Anyone?

[MovingGifts]

It seems we can't use <RX.Text> and instead must use <div> which isn't really the ReactXP way but it seems to solve problem.

<RX.Button style={styles.buttonStyle}>
    <RX.Text style={styles.textStyle}>{this.numberOfPeople}</RX.Text >
</RX.Button>

should be:

<RX.Button style={styles.buttonStyle}>
    <div style={styles.textStyle}>{this.numberOfPeople}</div>
</RX.Button>

Please let us know if there is a better ReactXP way to do it. Thanks!

[MovingGifts]

Hmmm... changing to the div while it updates the text, more complex styles that we applied via other components and passed down to <RX.Text break the app now. It seems it's best to keep the <RX.Text so it doesn't break anything in our large app.

Still looking for a better way so posting again here hoping someone can check it out from the ReactXP team and give some feedback.

[fbartho]

There isn't exactly a ReactXP "team" at this time, just us people on the internet @MovingGifts!

Please let me know if you figure out a way to fix this. I'm coming from a Mobile-Native background, so I wouldn't recommend using pseudo-elements since they wouldn't be compatible with native.

This feels something you solve with either a new Wrapper Component, or documentation / examples. Thoughts?