Skip to content
This repository has been archived by the owner on Mar 20, 2021. It is now read-only.

Client restore #338

Merged
merged 18 commits into from
Mar 17, 2014
Merged

Client restore #338

merged 18 commits into from
Mar 17, 2014

Conversation

kpdecker
Copy link
Contributor

Implements the logic necessary to restore server rendered views on the client side.

At a high level this is a hueristic that tracks the references made in handlebars templates and allows for views to be associated with the rendered HTML. Should we not be able to associate under a variety of cases, discussed below, the view will be rerendered at the deepest node possible given the specific error case.

These are covered in the tests, but the primary restore cases are:

  • Helper Views : Reconstructs the parameters passed into the helper and follows basically the same path, omitting the root HTML generation logic. Should the server not be able to store the data needed to restore the view will be marked for client side rerender.
  • Collection views
    • For simple templates the collection will restore per the helper views behavior.
    • For complex templates or collections whose models do not have a consistent id value, where the item templates have depthed references, {{../foo}} for example, the entire view will be rerendered on the client side.
    • For collections that differ in item ids on one side or the other, the elements that exist in both will be restored, missing items will be removed, and new items will be inserted into the collection view.
  • Layout.setView : Restores named views automatically. In the event of name mismatch, the layout element is cleared and standard rendering continues.

This may be kicked off by calling the restore method on the view directly but generally it's expected that Layout.setView restore path will be the primary path for views to be restored.

Assumptions/Caveats:

  • Data is available at the time of restoring. This breaks in situations where a loading UI may be displayed prior to the data being immediately available. A future PR will help address some of these (including documentation)
  • Any handlebars helpers that generate a custom context must update the contextPath data attribute.

$('[' + modelIdAttributeName + ']', el).each(function() {
var id = this.getAttribute(modelIdAttributeName),
model = self.collection.get(id);
if (!model) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry to be sense but if the collection item was rendered for a model in the collection, what would be the case where the model would no longer exist?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two cases: the there is no constant id value and somehow the data changed between data sources between the time that the client and server data was rendered. The later generally shouldn't happen but we want to play it safe.

kpdecker added a commit that referenced this pull request Mar 17, 2014
@kpdecker kpdecker merged commit 1c1ce74 into master Mar 17, 2014
@kpdecker kpdecker deleted the client-restore branch March 17, 2014 22:29
@kpdecker
Copy link
Contributor Author

kpdecker commented Apr 1, 2014

Released in v3.0.0-alpha.1

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants