Workflow failure when constructed lensed component from asynchronous resource
Description
Environment
Activity
Antranig BasmanJuly 3, 2022 at 9:07 AM
Yes, that's right, your existing function is admirably suited to being packaged as a simpler and more functional relay rule. If there is no match amongst ports it can simply return undefined or an empty array. Thanks for the ping about docs, I've added a catch-all docs JIRA https://issues.fluidproject.org/browse/FLUID-6743 for things we need to catch up on. Short-form model relay tests are at https://github.com/fluid-project/infusion/blob/main/tests/framework-tests/core/js/DataBindingTests.js#L1444-L1542
Tony AtkinsJuly 1, 2022 at 5:02 PM
I suspect that if I understand what you meant by func (singleTransform?), I can use what I have and simply return the value to be set as part of a relay instead of trying to apply the change myself.
Tony AtkinsJuly 1, 2022 at 2:57 PM
Is there an example somewhere that uses a modelRelay with the` func` property? I didn't see anything in the docs.
Also, idiomatic or not, the model relay pattern might not be a good fit for all cases. I only want to pass on the information if conditions are met, i.e. if there is a match among ports for what I would like to connect to. I haven't seen anything about conditional model relays thus far.
Antranig BasmanJuly 1, 2022 at 1:21 PM
It looks like this failure is due to the strategy of converting between "ports" and "connectionPort" via a programmatic modelListener which then fires a manual model change - this is something we would do more routinely in "old Infusion" (of the 2.x-3.x era) but prefer to do more declaratively via relays. I verified the issue with a test case looking as so:
but found that if we axe the modelListener in favour of a more idiomatic modelRelay definition like so:
The instantiation error goes away. However, the headline issue should still be fixed.
Encountered as a bare failure in https://github.com/continuing-creativity/youme/pull/2#issuecomment-1170977935 where a component "connection" is lensed from an asynchronous resource. The failure is
What has happened is that the 3rd component in the transaction, "connection", begins at workflow level 0, "enlistModelComponent" as a result of having its model resource resolve, and since this workflow stage is not marked as "waitIO", the current tree transaction is not restored.
Perhaps this is a good opportunity to eliminate the confusing and probably unperformant heavily promise-based implementation of the workflow system in favour of a priority queue, perhaps the one at https://stackoverflow.com/a/42919752
Something is odd, however, since this seems like exactly the case covered by the test https://github.com/fluid-project/infusion/blob/main/tests/framework-tests/core/js/DataBindingTests.js#L1204-L1226 which lenses a tree of components from a resource-backed model, but perhaps the difference is that there is one level of "firebreak" in that the top level of tree containment "levels" is static.