These are chat archives for ractivejs/ractive

23rd
Apr 2017
Arnaud Dagnelies
@dagnelies
Apr 23 2017 08:24
Dunno. I remember I did it once in the past and everything looked fine ...but it's not a 100% guarantee either.
paulie4
@paulie4
Apr 23 2017 21:58
Does anyone know if there's a prettier way to specify a root keypath in a template mustache (i.e. for when a mustache is within a context mustache section)? The only way I know how is like this: {{@.root.data.keypath}}, which is kinda ugly...
Chris Reeves
@evs-chris
Apr 23 2017 23:10
That's pretty much it, unless you set up a link/mapping from the js side
paulie4
@paulie4
Apr 23 2017 23:36
OK, thanks.
Chris Reeves
@evs-chris
Apr 23 2017 23:40
Any chance @shared could work for you?
paulie4
@paulie4
Apr 23 2017 23:46
The CHANGELOG.md says, "There is a new Ractive-private shared store, @shared. This is roughly the same as @global, but it is not susceptible to interference from the global scope." I'm not sure what that means. What context is that referring to? I tried both {{@shared.keypath}} and {{@shared.data.keypath}}, but neither seemed to work.
Chris Reeves
@evs-chris
Apr 23 2017 23:48
It's a cross-instance store, so it's shared among all ractive instances
You have to access it externally with r.set('@shared.keypath', 123)
paulie4
@paulie4
Apr 23 2017 23:51
Oh I see. That won't work in this case, since there are multiple Ractive instances, each with their own value, but thanks for the info on @shared, since I didn't know how that worked.
I actually got around having to use @ by making sure my keypath had a default value when the instance was created. The problem I was having was because when the template was first rendered, the keypath was undefined, so Ractive logically assumed I meant that the keypath was under the current context, since the mustache was within that section. In Ractive 0.7, it must have checked down into mustache sections when a set('keypath',...) was called for a new keypath, but that is obviously much slower.