These are chat archives for ractivejs/ractive

28th
Mar 2018
Bruce Tu
@brtu
Mar 28 2018 17:19
i am having some trouble with two-way binding in an iterative list
using ractive .9, when i click on select, the variable does not get set within the list, but works outside of the list
i looked over the patch notes, and in .8 it has this note: "Two-way binding is no longer allowed in computed contexts e.g. {{#each filter(someList)}}<input value="\{{.prop}}" />{{/each}} because changes to the computed child (filter(someList).0.prop aren't kept in sync with their source (someList.?.prop) as Ractive doesn't know how to reverse the expression. There is an ongoing discussion about how to address this, including an open PR that would put this behavior behind a flag and attempt to keep the sources up to date as the computation children changed."
is this related (though it is not a computed context) and what would be the workaround in ractive .9?
Chris Reeves
@evs-chris
Mar 28 2018 17:27
there's also a change wherein ambiguous references default to the immediate context if they aren't found elsewhere
disambiguating the refs should resolve that
Bruce Tu
@brtu
Mar 28 2018 17:29
nice, will try that
Chris Reeves
@evs-chris
Mar 28 2018 17:29
even with the data initialized with the myVar props in place, unambiguous refs are preferable because they resolve faster and can't resolve to different paths depending on how the data is structured
Bruce Tu
@brtu
Mar 28 2018 17:29
if the iterative list data is computed, i.e. filtered from a list somewhere, would this still work?
Chris Reeves
@evs-chris
Mar 28 2018 17:31
@curtistee it looks like there's an outstanding PR to support the changes in pointer events... you should be able to hack around it temporarily by simply setting window.navigator.enabled = !!window.PointerEvent
yes, but you'll probably want to enable syncComputedChildren too
there's planned support for telling an iterative section how to map back to a source list rather than having a computed context, but it's not done yet
Curtis Taylor
@curtistee
Mar 28 2018 17:53
@evs-chris thanks for the tip. I’ll give it a shot.
Chris Reeves
@evs-chris
Mar 28 2018 17:56
sorry, that last prop should be pointerEnabled not just enabled
Curtis Taylor
@curtistee
Mar 28 2018 17:56
very good
Curtis Taylor
@curtistee
Mar 28 2018 19:05
not working, unfortunately. I’ll see how much more hacking I can get away with.
Curtis Taylor
@curtistee
Mar 28 2018 19:26
I downloaded Jose Marinan’s full umd script as-is from the pull request. Plugging it into my code it works fine with Edge & IE 11 on windows 10, and chrome on mac osx. I’ll do some more testing but it looks like it’s going to work well.
Bruce Tu
@brtu
Mar 28 2018 19:52
@evs-chris how would i go about setting the ref both inside and outside my iterative to the same value?
Paul Maly
@PaulMaly_twitter
Mar 28 2018 19:54
try this: playground
Bruce Tu
@brtu
Mar 28 2018 19:59
@PaulMaly_twitter looks good, thank you!!
Paul Maly
@PaulMaly_twitter
Mar 28 2018 20:07
your welcome
Chris Reeves
@evs-chris
Mar 28 2018 20:35
@curtistee here's a playground with the hack that seems to work well in edge, just in case
@brtu yep, that's one way to go. See also ~/myVar, which works with both context and instance mutators.
Bruce Tu
@brtu
Mar 28 2018 20:43
ohh that is great... simpler and so easy
Curtis Taylor
@curtistee
Mar 28 2018 20:49
that playground example works, but not for me in our (messy) codebase, unfortunately.