These are chat archives for ractivejs/ractive

2nd
Oct 2018
Cerem Cem ASLAN
@ceremcem
Oct 02 2018 15:05

#RandomQuestionOfTheDay : Development-wise (code, build, maintenance, features, etc), what direction would you want Ractive head to and why?

I can't say "Ractive should do this" but I imagine Ractive will be used for declaring a 3D Parametric CAD design

Joe Turner
@JoeTurner-IR
Oct 02 2018 17:24
now for whatever reason my thing is working, might have been a caching issue, not sure
Joseph
@fskreuz
Oct 02 2018 18:27
Alternatively, it might be importing the wrong thing :grin: happens to me a lot
modifies component, nothing. checks everything, nothing. was editing a totally different file. :grin:
Shally Virk
@svirk_gitlab
Oct 02 2018 19:45

Hey Guys, I have an unusual issue while using 0.8.14 (i cannot update yet). Turns out that an observer does not fire when resetting the data on a component... case in point : https://codepen.io/shal1y/pen/EdVmZp

To reproduce:

  • Type something in the text box and then focus out
  • If the text changed from the original, you should see a cancel btn
  • clicking the cancel btn will reset the whole object (not using ractive.reset()).
  • try to change the text in the input box and then focus out
  • the observer does not fire

I'm changing the .updated property on the object and seems like the 2nd time around the system just won't listen.
Am I doing something wrong here?
The example is a segment of an app that I'm working on and this is the issue that I'm having.
Any insight would be appreciated :)

Chris Reeves
@evs-chris
Oct 02 2018 20:31
it looks like maybe you're fighting the twoway binding a little
Shally Virk
@svirk_gitlab
Oct 02 2018 20:31
@evs-chris do u suggest that I go away with the two way in the input and just manually change the it?
Chris Reeves
@evs-chris
Oct 02 2018 20:33
there's a lot going on, but if you change the value back to the original again, blur, change, and blur again it redisplays the cancel button
Shally Virk
@svirk_gitlab
Oct 02 2018 20:34
@evs-chris changing it back if fine, its just when I update the model, like hit the cancel and then change, blur => no effect :(
Chris Reeves
@evs-chris
Oct 02 2018 20:35
the observer appears to be firing on the updated though
at least I still get a console log
Shally Virk
@svirk_gitlab
Oct 02 2018 20:36
if you did not change anything, the log is of comparison of the initial and final values... i.e. if you are seeing just true, false etc
Chris Reeves
@evs-chris
Oct 02 2018 20:43
I think what's happening is the tagUpdated event is triggering the observer that fired it, which gets the observers internal state wonky because 0.8 doesn't have a guard for that
if you through the fire in a setTimeout it should work
from the base tag.updated observer
Shally Virk
@svirk_gitlab
Oct 02 2018 20:43
@evs-chris let me try that :)
@evs-chris still not working :( should I even be doing something like this? I've realized for sometime, when this kind of issue happened before, I would usually set the model to null, then in a timeout set it to the value I wanted... it worked before, but now I had too complicated of a system made... thought I'd ask you guys before I changed it again
Chris Reeves
@evs-chris
Oct 02 2018 20:49
interesting
there's another race somewhere that's causing the button to stick on and off
Chris Reeves
@evs-chris
Oct 02 2018 20:54
hmmmm
Chris Reeves
@evs-chris
Oct 02 2018 21:04
there's something really whacky going on because in the blur handler, you can edi.get('tag.updated') immediately after setting it to true and it will return false
Shally Virk
@svirk_gitlab
Oct 02 2018 21:05
@evs-chris I know! like I set it to true and after the promise, log out the object again, and its not changed at all
Chris Reeves
@evs-chris
Oct 02 2018 21:13
ahhhhh
it's the getNamedTag computation for the tag binding
it's recreating the tag when it changes because it forces a recompute
Shally Virk
@svirk_gitlab
Oct 02 2018 21:14
@evs-chris you mean that it does not serve the actual tag, but clones it?
Chris Reeves
@evs-chris
Oct 02 2018 21:14
you would need to stop that from happening by either calling getNamedTag for the data object or having a memoized function that would return the same tag for subsequent calls for the same id
tag="{{getNamedTag(...)}}" is a computed binding
so (in 0.8) when you update tag, it's recomputing and overwriting the changed object with a fresh one
Shally Virk
@svirk_gitlab
Oct 02 2018 21:16
hmm
so do not use a computed prop otherwise this will keep happening?
Chris Reeves
@evs-chris
Oct 02 2018 21:16
at some point, we introduced static computed bindings tag="[[getNamedTag(...)]]" to avoid that, but it looks like it was after 0.8
Shally Virk
@svirk_gitlab
Oct 02 2018 21:17
let me try that... maybe the static works
Chris Reeves
@evs-chris
Oct 02 2018 21:17
or use a memoized computed binding so that you get back the same object
then it won't reset
Shally Virk
@svirk_gitlab
Oct 02 2018 21:18
memorized computed binding... can u tell me how to do that?
Chris Reeves
@evs-chris
Oct 02 2018 21:20
your getNamedTag function would need to reference a cache e.g.
var cache = {};
function getNamedTag(name, type) {
  const key = `${name}--${type}`;
  if (cache[key]) return cache[key];
  // create the tag object here as tag
  cache[key] = tag;
  return tag;
}
Shally Virk
@svirk_gitlab
Oct 02 2018 21:21
got it....! thanks a lot for your time @evs-chris I'll give it a shot and see if it all works for me... :)
Chris Reeves
@evs-chris
Oct 02 2018 21:22
good luck :)