Response title
This is preview!
Move this topic
Using PJAX or Turbolinks with jQuery Mobile on a rails app
in jQuery Mobile
•
5 months ago
On the desktop, I'm using PJAX (but plan to migrate to Turbolinks). For mobile, I've been using jQuery Mobile's default page and pushState behaviors. As my client side functionality gets more interesting, I'm looking for guidance on the best way to proceed.
Should I disable jQueryMobile's pushState and page caching in favor of Turbolinks? Or am I giving up too many of the benefits (page transitions, etc) that JQM provides? OTOH, integrating JS libraries like client_side_validations becomes more difficult as I have to account for more than one "single page application" strategy (desktop vs mobile).
Has anyone seen a blog post or have any guidance on how the weigh the pros and cons of this issue?
1
Replies(7)
Personally I don't know a lot about this topic. But I can tell you if you decide to throw away the JQM functionality, you may as well find a new framework. Part of the reason JQM is used is because of the page caching and AJAX transitions.
I think the real question you need to investigate is whether or not you want to use JQuery Mobile for your project. If you want to use those other tools, I would take a look at Zepto.js or other frameworks. Just my 2 cents.
Leave a comment on haga0054's reply
If it wasn't designed to work with JQM, you are just asking for trouble and over-complicating things. You are taking on the task of figuring out how to make them work together, possibly requiring modifications to one or both, (bat at minimum developing a set of rules on how to make them play well together) and then maintaining that solution through each upgrade of each product, which is likely to break your solution.
I wouldn't do it.
These both seem to try to solve problems already addressed by JQM.
I only did a quick read, but it seems to me that the main goal of Turbolinks is to keep pages loaded so that they can be quickly restored (and perhaps modified before being restored.) This can be accomplished in JQM with data-dom-cache="true".
I wouldn't do it.
These both seem to try to solve problems already addressed by JQM.
I only did a quick read, but it seems to me that the main goal of Turbolinks is to keep pages loaded so that they can be quickly restored (and perhaps modified before being restored.) This can be accomplished in JQM with data-dom-cache="true".
Hey, guys. Thanks for the rapid responses.
@hada0054, JQM is a full stack UI framework that is incredible and there is no way I would give that up just because I didn't use their notion of page caching and pushState.
@watusiware, I'm hoping to un-complicate my life. :-) I have both Desktop and Mobile versions backended by a Rails server. For both, I want a "single page application" model that leverages pushState, webSockets and caching in order to boost performance and usability.
JQM pioneered client-side improvements. As the server-side catches up, I want the best of both worlds. If the server knows that the client is just manipulating DOM fragments via AJAX then it can be smart and not re-render (or send) the static parts of the page (e.g., the <head> tag). Furthermore the client can leverage this win by not reprocessing those assets. If you have a lot of JS like I do with a client-side MVC framework, this is a big win.
So (despite how my initial question was worded), I'm not looking to turn off JQM's pushState code or DOM caching. I'm just want to leverage the experiences of someone who blazed this trail before me and get all the wins that both JQM and Turbolinks (or PJAX) provides.
Leave a comment on watusiware's reply
I wouldn't call JQM a "full stack UI framework". It's less than that. That's where a lot of confusion comes from.
I've been away from Rails for a while, so not sure what is out there. But it sounds like you want something like "UJS for JQM". You might want to do some searches.
Sounds like you want to just replace fragments inside your pages, which is very commonly done in JQM. I'ts not much addressed in the JQM docs (if at all) because you typically use jQuery to do this, and so the necessary functions are documented there. jQuery has quite an extensive array of methods for making AJAX requests and for modifying content in the DOM.
Yes, this can get tedious.
I do this a lot. I just have the server send back HTML fragments in response to $.ajax() calls (but I typically use higher-level calls that $.ajax() - usually don't need all those options), and then my Javascript code inserts it into the document.
The JQM Ajax page-loading mechanism has no bearing in this, since you are going behind it's back. It's completely irrelevant, except if you use a button or link to trigger this, then you do have to be careful to disable the default action. Add data-ajax="false" (a bit counter-intuitive, since you want to do AJAX, right? You need to tell JQM not to do AJAX...) to the link/button/form. Write an event callback. In the callback make sure you call preventDefault() on the event object.
Now you have a button/link/form that does nothing but trigger your event code. You can then write whatever you would like in that event code. Typically, then, make some Ajax request to a server, get the result, parse it if necessary (but I much prefer getting an HTML fragment rather than JSON, XML, etc.) and insert it into the DOM.
I usually use Rhodes in mobile apps, and there I can use their execute_js() function (in Ruby) to asynchronously send Javascript to the browser to execute, so I haven't had a need for solutions like webSockets. Typically I define a Javascript function in a file loaded in <head> and then just send a call statement.
I would look for something specifically designed to work with Rails and JQM. Otherwise, instead of un-complicating your life, you are going to make it miserable.
Edit: sounds like you should lobby to make sure that TurboLinks plays well with JQM. I don't recommend this as a do-it-yourself project unless you intend to behind a major contributor to the TurboLinks project.
I've been away from Rails for a while, so not sure what is out there. But it sounds like you want something like "UJS for JQM". You might want to do some searches.
Sounds like you want to just replace fragments inside your pages, which is very commonly done in JQM. I'ts not much addressed in the JQM docs (if at all) because you typically use jQuery to do this, and so the necessary functions are documented there. jQuery has quite an extensive array of methods for making AJAX requests and for modifying content in the DOM.
Yes, this can get tedious.
I do this a lot. I just have the server send back HTML fragments in response to $.ajax() calls (but I typically use higher-level calls that $.ajax() - usually don't need all those options), and then my Javascript code inserts it into the document.
The JQM Ajax page-loading mechanism has no bearing in this, since you are going behind it's back. It's completely irrelevant, except if you use a button or link to trigger this, then you do have to be careful to disable the default action. Add data-ajax="false" (a bit counter-intuitive, since you want to do AJAX, right? You need to tell JQM not to do AJAX...) to the link/button/form. Write an event callback. In the callback make sure you call preventDefault() on the event object.
Now you have a button/link/form that does nothing but trigger your event code. You can then write whatever you would like in that event code. Typically, then, make some Ajax request to a server, get the result, parse it if necessary (but I much prefer getting an HTML fragment rather than JSON, XML, etc.) and insert it into the DOM.
I usually use Rhodes in mobile apps, and there I can use their execute_js() function (in Ruby) to asynchronously send Javascript to the browser to execute, so I haven't had a need for solutions like webSockets. Typically I define a Javascript function in a file loaded in <head> and then just send a call statement.
I would look for something specifically designed to work with Rails and JQM. Otherwise, instead of un-complicating your life, you are going to make it miserable.
Edit: sounds like you should lobby to make sure that TurboLinks plays well with JQM. I don't recommend this as a do-it-yourself project unless you intend to behind a major contributor to the TurboLinks project.
Thanks for the in-depth response.
I'm watching what JQM does via my Proxy and Web Inspector. There is a lot going on below the hood that's been tested on lots of platforms. I have no desire to interfere with that.
I will beat the drum for JQM compatibility with the Rails team. In the meantime, if anyone else has JQM experience with Turbolinks, I'd love to hear from you.
Leave a comment on watusiware's reply
This really does require some specific behaviors for jQuery Mobile. It's not that hard, but it needs to be baked-in to the server-side tool (and associated Javascript support code) or else added as some kind of plug-in for the plug-in.
Anything that works with jQuery is a good candidate. But Ajax with JQM requires a bit more than ajax with jQuery. After content is inserted into the DOM, if it contains JQM widgets, it needs to be "enhanced". JQM does this automatically when you load a page using it's own AJAX mechanism. But when you insert stuff into a page, JQM doesn't know that you did so. You have to tell it. (trigger create on the parent node).
As well, there are certain container widgets (notably, listview and select) that need to be notified when you have changed something inside. This uses a different mechanism, you need to call the refresh() method on the container.
So, Rails plugins/helpers that were designed to work with jQuery could be adapted to work with JQM, but aren't going to work off-the-shelf without modifying them to conform to JQM requirements.
Anything that works with jQuery is a good candidate. But Ajax with JQM requires a bit more than ajax with jQuery. After content is inserted into the DOM, if it contains JQM widgets, it needs to be "enhanced". JQM does this automatically when you load a page using it's own AJAX mechanism. But when you insert stuff into a page, JQM doesn't know that you did so. You have to tell it. (trigger create on the parent node).
As well, there are certain container widgets (notably, listview and select) that need to be notified when you have changed something inside. This uses a different mechanism, you need to call the refresh() method on the container.
So, Rails plugins/helpers that were designed to work with jQuery could be adapted to work with JQM, but aren't going to work off-the-shelf without modifying them to conform to JQM requirements.
Leave a comment on watusiware's reply
After completing my port to Turbolinks, I believe that all of Turbolink's client side behavior is available in the JQM framework. Both do DOM caching, GET fetching via AJAX, pushState failover. For single page apps, JQM does a few more nice things like bundling multiple pages in a single request.
For simple mobile Rails apps it's OK to use Turbolinks and responsive web pages. But if your mobile app does anything interesting, use JQM and let it do all the heavy lifting.
Then come up with abstractions so you can do DRY up your desktop and mobile code as best you can. For me, backbone.js was a nice way to do that. As @watusiware points out, you have to make sure JQM knows about your dynamic client-side behavior. That's a small amount of edge code to get all of JQM's benefits.
Forex, I was able to use Simple Form to generate all my forms for both the Desktop and Mobile with platform specific wrappers that allowed me to DRY up all my formatting and validation code. For the really clever widgets, I'm happy to make JQM and Bootstrap (my Desktop UI framework) specific versions of each.
My ultimate goal is to package these with PhoneGap, so the less I tamper with JQM, the more likely I am to succeed with this strategy.
Leave a comment on ccmcbeck's reply
Change topic type
Link this topic
Provide the permalink of a topic that is related to this topic
Reply to ccmcbeck's question
Statistics
- 7 Replies
- 485 Views
- 0 Followers
