I managed to refactor my test to use

find<MyView>(Scope())

like @edvin suggested. I had to resort to a

replaceView

with a transition duration of zero in order to avoid flaky tests. TestFX was failing to lookup by ID, I suspect because the transitions hadn't completed yet prior to the next test cycle. Would you mind taking a look at the setup pieces of my test? Any feedback would be greatly appreciated! https://github.com/caeos/coner-worker/blob/5-prompt-core-service-connection-details/src/test/kotlin/org/coner/worker/page/EstablishConnectionTest.kt

@kastork Checking, hang on. That might be expensive.

@kastork I might be able to create a less expensive property on the editmodel to retrieve the dirty state

Not sure if it is worth it

especially if doing it by tracking individual cell dirtiness

maybe it makes more sense to have cell edits just auto-commit

@kastork It's going to be (potentially) too expensive. There is already an observableHashmap with the state inside of

editModel.items

, so it's possible to get to this, but I'm not sure I can do it in a way that makes sense performance wise.

never allow a dirty cell other than when editing is actually in progress

Trying one more thing.

@kastork I found a way to do it, but it's too expensive, so I don't think it should be included in the framework.

@Carlton Whitehead That makes sense, animations will delay when the node is actually swapped. But you can use

replaceWith()

without a view transition, no need to set one with duration.zero

@edvin can you track the dirty state on the node itself with a custom property?

@edvin thanks for investigating

@kastork My pleasure. Sorry I couldn't find a cheap enough way to do it 🙂

no worries

@carlw What nodes are we talking about?

wonder if it could get cleared out as you're scrolling

the cells

@carlw Not the way I made it. I already made it pretty expensive 🙂

ok

I'm thinking of an event-driven possibility. On the first edit send an "I'm dirty" message and on a commit send an "I'm clean" message

maybe the best thing to do for updates is reconcile the table with a model component and produce a series of diffs? or gather up just a journal of the updates for a later save operation?

ah the journal is an interesting notion, then all you'd have to do is watch the empty state of that object

@kastork you're trying to avoid lots of small singular update calls?

@carlw Well in the example, the table tracks dirty cells and indicates individually. That's nice, but if the changes are off-screen, then user doesn't necessarily know if the collection needs a save or not

the rest of the framework makes it easy to disable things that would be no-ops if you did them -- except in this one case

making any cell edit commit immediately would solve it because the table as a whole could never be dirty

yeah. maybe the journal approach would work for you. i used it for a client who wanted to move quickly through a table and didn't want to save until they were finished. sometimes, they would correct themselves prior to saving and this had to be filtered in the journal

but that might not satisfy some cases where you want to edit the whole row, for example, before committing to ,say, a database

i let them add new empty objects that were valid (suitable defaults)