@RALifeCoach I didn't have time to read through everything, but in regards to the recent comments, I didn't mean
type: "*"
if your data is only for view only
and doesn't change
you could use
can-connect to load non-observable plain JS data
and just pass that to stache
If you just pass a PJSO into can.view, it’s the same as constructing a can.Map -> that's not accurate
there's no conversion to
can.Map and there's no event binding.
computes are still created, and those computes are bound to ... but then we see that the computes have no observable dependencies and they are discarded
I’m confused then. You can still cross-bind to properties passed into can.view
if I do
can.stache("<h1>{{message}}</h1>")({message: "HI"})
That will output
<h1>Hi</h1>
but there won't be any event binding
and it won't implicitly convert
{message: "HI"} into a map or anything
But something could still bind to message using a 2-way binding, or a parent-to-child binding, update message, and that’ll be rendered
and if you updated message, it won't re-render
var data = {message: "HI"};
var frag = can.stache("<h1>{{message}}</h1>")(data):
data.message = "BYE";
frag //-> <h1>HI</h1>
Eh? My app was passing in a PJSO that had a user can.Map as a property and bound to switching out users just fine
non-observables aren't "observed" by can.stache
we've worked on a dirty-checking implementation
but never actually put it into the framework
var data = {message: "HI"};
var frag = can.stache("<foo-bar {(message)}="./message”/><h1>{{message}}</h1>")(data);
$(document.body).append(frag);
can.viewModel('foo-bar').attr('message', 'BYE');
frag //-> <h1>BYE</h1>
Something like that
's content
once proxies land ... we'll be able to do
var data = can.observe({message: "HI"});
var frag = can.stache("<foo-bar {(message)}='./message'/><h1>{{message}}</h1>")(data);
$(document.body).append(frag);
can.viewModel('foo-bar').message="bye";
guess you’re right
yeah, I sure as hell wouldn't be making people call
.attr for all these years if we had a good way of making POJO's observable
Even if you could though, I’ve always seen considered .attr an advantage as you can read some properties with
.attr and some without to limit the number of observables read
I have a map, like
myMap.define.foo.get = () => { ... }, and something observing it, like myMap.attr('foo') -- I don't understand the can compute implementation very well, but could that getter function ever be called before myMap.attr('foo') is evaluated?
Or maybe better asked: is it a bad idea for
myMap.define.foo.get to have side effects? Are they expected to be idempotent?
Binding or reading a computed property calls the getter, then caches the result. It’ll then re-compute that value if something it’s observing changes, and emit a change event if the resulting value is different. Internally, the
attr or computes read during a getter or helper will be tracked, and bound to, which is how it knows to re-compute.
A lot of times it’s unavoidable that your getter can’t be idempotent, such as doing async things, or returning object instances. So this can create side-effects, especially with multiple changes per batch. But this can be mitigated by using intermediate computes, basically allowing you to avoid unnecessary re-computes for things that you want cached but can’t easily do idempotently
It’s worth noting, you can use computes to do translations. For example, rather than using Component events to conditionally update some other state, you could accomplish the same via a compute / define getter
Makes things easier when dealing with complex binding requirements
I again need help.
can.fixture("/modules/page.tournament/tournament-leaderboard-new/data/stracka/leaderboard-cgo-v2.json",
"/modules/page.tournament/tournament-leaderboard-new/data/leaderboard-canjs" + counters.leaderboard++ + "-v2.json");I know the fixture is being loaded and I know that the can.ajax request url matches, but I am not getting the file I expected.
I continue to get the original file
I have also checked that the ajax request is using can.ajax
@cherifGsoul hi, any chance you got to look at the jsbin I sent you yesterday?
And can anyone give me feedback on what’s wrong with my fixtures
@dbleier sorry I didnt have a chance I will give it a moment this evening if you dont mind
@jeroencornelissen can you open an issue?
@RALifeCoach do you see a message in the console like “using a dynamic fixture for...” ?
ok, in the network panel do you see the http request?
yes
here is the entry from the network
http://localhost:8090/modules/page.tournament/tournament-leaderboard-new/data/stracka/leaderboard-cgo-v2.json?ts=1459436642250
http://localhost:8090/modules/page.tournament/tournament-leaderboard-new/data/stracka/leaderboard-cgo-v2.json?ts=1459436642250
can.fixture("/modules/page.tournament/tournament-leaderboard-new/data/stracka/leaderboard-cgo-v2.json?ts={ts}”, …);
try adding it
That might be worth mentioning in the docs - that query strings have to be accounted for including cache buster
thank-you for your time and assistance
feel free to open an issue or PR for the docs
Why aren’t can.batch.after / can.batch.afterPreviousEvents documented?
I was just thinking, what if we added something, say
can.debounceBatch that’s equivalent of can.debounce + can.batch.afterPreviousEvents. I think we can use that as a helper for making less noisy getters
Maybe even less noisy helpers too?