StepperRow cell artifact when using Eureka v5.1.0
sedwo opened this issue · 13 comments
Similar to the Eureka issue listed here: xmartlabs/Eureka#1910
Except SplitRow
seems to create a dual stepper control.
eg.
let signNumberQuantityRow = SplitRow<TextFloatLabelRow, StepperRow>() { row in
Hi @mats-claassen,
I've replicated the issue here using Xcode 11, iOS 13 simulator.
As I work to debug it, would you happen to have any insight as to why this UI artifact occurs?
fyi: Set Swift Language Version
= "Swift 4" within Build Settings for FloatLabelRow
pod
@mats-claassen I tested a few Eureka versions and this artifact seems to occur only with v5.0.1
I think this is related to the Eureka issue you mentioned. There is a fix waiting to be merged. Let's see if the issue here is still there after with that fix
@mats-claassen v5.1.0 of Eureka still has this issue. :/
@mats-claassen bump. 😬
Hi, I have looked into this. Issue is that the setup
function of the cells inside SplitRow
is called twice, which in the case of the StepperRow ends in two steppers being added but it might lead to other issues with other rows.
Issue is in SplitRowCell here (* edited class name). By accessing the cell of a row (the first time) the cell is being initialized and setup
is called. setup
is called manually again later inside the setup
of the inner tableView.
Possible fix is to remove line 36 (row.baseCell.setup()
) from SplitRowCellTableView
@mats-claassen is it guaranteed for all row types, that the row's setup
function is always called before SplitRow
executes it?
We surely can add an exception in SplitRow for StepperRow as long as it’s shipped with Eureka core. But not quite sure if this is the best approach...?
Sorry I misspelled the class name above. Corrected it now. Issue is in SplitRowCell.
I do think this issue affects all rows. However it is possible that some rows work fine with setup
being called twice even though by design it is not correct.
I have not tested the fix I suggested but I am quite positive about it
@mats-claassen thanks for the hint! I've added the following fix in master branch:
if !(row is _StepperRow) {
row.baseCell.setup()
}
What I've seen it works. Can you guys verify everything behaves as it should? Will do a new release after confirmation.
EDIT: As the issue only arises on StepperRow
right now, I'd prefer fixing this issue explicitly for this one row type to avoid any potential side effects. If the issue arises again for another row type, we should definately look further into this and find a way to make sure setup()
is called only once.
Thank you @marbetschar, your change works. 👍
Tested with Eureka v5.2.0.