Update template when JSON changes.

[bigeasy]

Update a template in the browser when the underlying JSON changes. There will be a way to map objects in JSON to template chunks in a Stencil.

[bigeasy]

Couple of thoughts. The callback can take additional information that will get it to build dependencies. This dynamic ability ought to be only related to callback oriented code at first. A function return value is an annoying way to pass a lot of data.

Documents are built in document order, so we can identify a place in the document using a structure with arrays. If we add a dynamic structure to the document, we can put them in a parallel structure, with an array for each dynamic structure, and we can splice our parallel data.

The each operation will iterate over an array. It changes things. We have a difference operation for objects that can skip arrays, I believe. If you want to watch an array, you need each or some other helper.

But, I'm starting to see that I need a language for selecting from the DOM. This selection language tells Stencil that we're using bits of an underlying JSON object, so please keep an eye on that JSON object. There needs to be some way to create an association. If you reference the status update of a user, and the status update changes, but nothing else does, update only the status update.

Also, let's say you have a when field, minutes ago, 3 minutes ago, etc. You can use a callback that references a timer and the timer can expire once a minute, or something.

Making that association with a sub-component of a JSON document is almost certainly going to need a query language, so let's finish inquiry. It needs to be something that we evaluate, that tells us that something got plucked from our JSON. We can as $ to our statements to indicate that any expression can reference the JSON, and we'll track which bit and re-run the statement, with the same context.

I'd imagined a query attribute to use instead of evaluation, but we can tuck it into the evaluation.

Another possibility is to build an object that has an accessor for each item in scope. Use that with with. Then when the accessor is called, we create a wrapper with an accessor for each. However, besides being possibly very slow, especially when wrapping each index of a very large array, imagine loading geo data, it might not be possible to sort out which object we're using and how. Hmm... Actually, well, no we can't assume that it is will always be a path as in person.status.date.

Hmm... Actually, we can look at the last bit returned, and if it is a scalar, then we can assume it has been displayed. We then know that the scalar is what we're watching for change. I'll bet even join would go through our getters.

Potentially very slow, but then, only really necessary once. Let's say you do get an array of 1000 people, but you use each to visit 20. We only need to wrap those 20 to see what you'll do with them.

This is all potentially very slow, but transparent. A query language would not be transparent, but it would be fast.

Also, we don't have to use with. Few scalars are going to be in scope unless we do value. If a JSON query returns a scalar, then we need to track that JSON query.

each can have append and prepend elements to say that you want items to go before or after a as they arrive. Maybe insert with a collation?

[bigeasy]

At the point we have a way to track which bits of JSON are referenced, we need a way to say that a bit of the document will be dirty when that JSON changes. We need to keep that part of the template, the location of the DOM node generated by the template that needs to be replaced. We need to keep the JSON object and the path into the JSON object so we can compare.

Easiest if this is an engine driven by the previous JSON, visits the JSON in order, matching against the new JSON. It would find things that changed, trigger the changes. It can prune the JSON to be only that which was necessary to generate the page, so now we need to warn the user that we're destructive. Or else we build a copy, probably that.

Or maybe our little machine is a bunch of objects anyway, and not JSON.

New JSON gets a new little machine.

It occurs to me that when something is used in an if statement, we need to revaluate the if the data changes. That's more messy than value or updating a table or list created by each.

Not sure where to start. A simple timer is too simple to illustrate a problem. Maybe a list of statuses from GitHub or Twitter.

[bigeasy]

Want to use getters to track the path though JSON? Afraid that creating all those getters is going to be sloooow. Well, here's the good news: they can be cached. Need array index getters? Create an array of them. Use them for any array. Need a named getter, have a cache by name. They all reference the this object, so it is not a problem for you to reuse them.

Keep in mind that JSON is not the Soul Train Scramble Board. Objects within JSON will reuse the same names, so you can reuse the same getters.

Use a cache. If someone does something to defeat the cache, like load an array with a bazillion elements, they were going to run into memory problems anyway.