Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow non-pjax page updates. #684

Open
wants to merge 12 commits into
base: master
Choose a base branch
from

Conversation

ndelage
Copy link

@ndelage ndelage commented Oct 1, 2014

Extract transition functionality from push.js into a new file, transitions.js.
Expose a global function, similar to PUSH named TRANSITION used to transition
from one page/view to another without dictating how the new markup is sourced.

This allows for Ratchet style page transitions when rendering client side.

I'll add comments to the diff shortly, highlighting some of the changes I've made.

//
// These following selectors define which elements are transitioned with
// simple DOM replacement and are always immediate children of <body>
var barSelectors = [
Copy link
Author

Choose a reason for hiding this comment

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

I didn't see any reason to keep the list of bar element selectors in an object (see the key/value pairs at the top of push.js). So it's a simple list of selectors now.

@cvrebert
Copy link
Contributor

cvrebert commented Oct 4, 2014

@ndelage This is failing in Travis: https://travis-ci.org/twbs/ratchet/builds/36779341

@ndelage
Copy link
Author

ndelage commented Oct 4, 2014

Yeah, I noticed. The linter doesn't think TRANSITION has been defined. But in the context of a full Ratchet codebase, it is defined on window (as part of transitions.js). I haven't put too much effort into satisfying the linter yet. I figure we can cross that bridge once we've discussed the patch.

I'm welcome to any suggestions if you've dealt with a similar issue before.

@hnrch02
Copy link
Contributor

hnrch02 commented Oct 4, 2014

Change /* global _gaq: true */ to /* global _gaq, TRANSITION */ to fix that.

@ndelage
Copy link
Author

ndelage commented Oct 10, 2014

Thanks, Travis is passing now.

transitionContent(newContentDiv, existingContentDiv,
transition, complete);
} else {
document.body.innerHTML = contents.innerHTML;

Choose a reason for hiding this comment

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

@ndelage Suggest to modify this line as follows:

document.body.innerHTML = "";
document.body.appendChild( contents );

This will ensure that all bound events and data will remain attached to the element instead of "flattening" it to just HTML string

@ndelage
Copy link
Author

ndelage commented Oct 12, 2014

Thanks for the comments @avinoamr, these are spot on. I agree with moving TRANSITIONto PUSH. I wasn't too excited to expose another global. That said, it seems that Ratchet would benefit from a single namespace, but that's another discussion entirely.

I'll submit the relevant changes in the next day or so.

}

container.parentNode.insertBefore(swap, container);
complete && complete();

Choose a reason for hiding this comment

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

@ndelage If transition is set, you end up calling complete() twice - once here and again when the transition completes.

Copy link
Author

Choose a reason for hiding this comment

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

I've removed the premature (before the transition completes) call to complete. In my version transitionContent is only called when a transition is present.

@ndelage
Copy link
Author

ndelage commented Oct 13, 2014

Now appending content instead setting innerHTML.

@hnrch02
Copy link
Contributor

hnrch02 commented Oct 22, 2014

Pinging @connor for a review.

@ndelage
Copy link
Author

ndelage commented Oct 22, 2014

I'd love some feedback, but given the potential that we move to a module approach with a single top-level object/namspace Ratchet, I think it makes sense to move the new TRANSITION function into the push.js IIFE. This way we avoid adding another global.

Later if we move towards a single Ratchet object, it will be easy to expose the transition functionality via a property of Ratchet (e.g. Ratchet.transition)

@Tarang
Copy link

Tarang commented Oct 26, 2014

Cool PR. It would definitely help our project. I've not dived deep in, but is it able to take DOM over raw html?

@ndelage
Copy link
Author

ndelage commented Oct 26, 2014

Yep, that's the idea. The TRANSITION function takes the markup & transition style as arguments. I've been using this with a Backbone app (allowing me to avoid PJAX)

@Tarang
Copy link

Tarang commented Oct 27, 2014

Cool! I just gave this ago but I seem to have a couple of problems. I tried to use TRANSITION(domElement, 'slide-out') or slide-in. If I remove the transition it swaps the page out. With the transition I can see the transition going on, but the new page seems to disappear and I'm remaining with the old page, albeit without the titlebar.

@ndelage
Copy link
Author

ndelage commented Nov 8, 2014

Hey @Tarang, sorry for the delay. I just pushed an update, including auto-generated js & css in dist/. The update allows for both HTML markup as a string or DOM elements as the contents argument to TRANSITION. Here's example usage, passing a string:

var contents =   "<div><div class='bar-tab'></div><div class='bar-nav'></div><div class='contents'<p>Foo Bar Baz</p></div></div>";
TRANSITION(contents, 'slide-left');

The single wrapper <div> needs to be included. It could be another element (like <body>) if necessary. But the contents argument needs to represent a single element.

Give it another shot and let me know if you run into any issues.

@helloworlder
Copy link

Is anybody else noticing a memory leak on transitions?

@ndelage
Copy link
Author

ndelage commented Nov 8, 2014

Could you test master for the same leak? Can you provide details on how you've been testing for memory leaks?

@ndelage
Copy link
Author

ndelage commented Nov 8, 2014

Just added a step to clone the contents argument to TRANSITION (I discovered it was being modified when applying a transition).

@ndelage
Copy link
Author

ndelage commented Nov 8, 2014

Disclaimer: I'm no expert in tracking down memory leaks or profiling JS. I ran some tests using Chrome's timeline, tracking memory usage over time and forcing garbage collection a few times throughout the test. After each GC, it looks like everything has been cleaned up. I don't see a memory increase:

garbage-collection

@helloworlder
Copy link

Thanks Nate for the reply! I looked deeper into it and it seems like it may be a weird jQuery XHR issue, and not related to the TRANSITION call. I also looked at the DOM through the remote Safari debugger and it looks like everything is being cleaned up correctly. So sorry about that.

@cocoademon
Copy link

Is this likely to be merged?
I'd love to switch from using my current workaround, which is having a bunch of empty .html and injecting template contents in an on('push') handler.

@XhmikosR
Copy link
Member

XhmikosR commented Feb 4, 2015

@ndelage: can you rebase and clean up this branch?

@luisrudge
Copy link

+11111111 to this :)

@XhmikosR
Copy link
Member

XhmikosR commented Feb 9, 2015

@ndelage: please fetch and rebase.

@ndelage
Copy link
Author

ndelage commented Feb 9, 2015

Will do. I'll get to this in the next few days.

Extract transition functionality from push.js into a new file, transitions.js.
Expose a global function, similar to PUSH named TRANSITION used to transition
from one page/view to another without dictating how the new markup is sourced.

This allows for Ratchet style page transitions when rendering client side.
Ensure that all bound events and data will remain attached to the
element instead of "flattening" it to just HTML string.
@ndelage
Copy link
Author

ndelage commented Mar 12, 2015

Just pushed a rebased branch, switching over to the new window.RATCHET global. Going to do a bit of testing locally, but feel free to have another look at the pr.

@XhmikosR
Copy link
Member

  1. We don't need the dist files in the PR to reduce conflicts
  2. Many of the patches can be squashed

@ndelage
Copy link
Author

ndelage commented Mar 12, 2015

Roger. I'll make those changes.

@qkdreyer
Copy link

Any updates ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants