Page life cycle with pagecontainer: Reasons to keep 'pageshow' event

[wauwau0977]

This is not a bug request, i would like to raise an design / architectureal issue. Starting in JQM 1.4 onwards, page life cycle events (e.g. pageshow) are deprecated in favour of 'pagecontainershow'. Please consider the case below, where i think it's not a nice replacement.

We use JQM in a rather big project with several developers, where we try to split up the app in functional "modules". For this we also use separated files to give the app a certain structure. It was very convenient to have a way to implement the page specific handlers on the page itself for actions like templating and custom JavaScript preparations, etc...

Now, with the container i still can do that, but i must control the logic centrally and then dispatch again to the page module... Architectural wise, that's a strange approach...

I would love to see again a way to bind "life cycle" logic to a page again. Since programmers will work on pages as their logical work unit and they want to control the life cycle on that logical work unit...

Cheers,
Patrick

[Palestinian]

I have made this post explaining page cycle of a page in jQM 1.4. Unfortunately, between all events, only two events can be attached/delegated to page div pagebeforecreate and pagecreate.

Initializing plugins such as Google Maps won't function as they should because page div is still hidden and dimensions are unknown. They should be initialized on pagecontainershow only.

Using if statement or switch/case to identify on which page pagecontainershow emits, isn't an ultimate solution.

I second @wauwau0977 on this issue. Please, we want the old events back.

Thanks!

[simsam7]

I support @wauwau0977 and @Palestinian on this, the new 'pagecontainershow' does not really encapsulate one of the elements of jQM that I have always seen to be a core feature, namely to handle page cycle events with relative ease and clarity. The current solution would make me rather use another framework for more complex scenarios, since it architecturally inhibits a more modular approach.

I agree as well, I feel as if jQM 1.4 took a step backwards in this area, requiring much more code and adding much more confusion to things that should be fairly "simple"

[jtara]

You can do this yourself, but why should you have to write a work-around for something so fundamental and useful?

It is useful to fire events on the objects that have the greatest need to know about them. Most of these events concern (primarily) the page that is involved. It is almost always page-related code that is interested in pagebeforeshow, pageshow, pageinit, etc. There are limited instances where this might be of interest globally, and in those few cases, you can allow the event to bubble to the document and catch it there.

An "if" statement in a document-level callback is not a good alternative. It means that code that applies to a specific page (or class of pages) has to be dealt-with at the document level. It makes it difficult to write modular code. Given the level of sophistication of the average jQuery Mobile developer (low - not meant to insult anybody, just an observation...) this is going to create tons of awful spaghetti-code.

This seems an issue of purity of concept winning over ease of use. The end effect is it appears the developers want to make it difficult to use. Makes no sense.

Work-around is to catch these events on $(document) and reflect those that are applicable (e.g. when the page actually exists) to the page. But you'll have to invent new names because the old events have only been deprecated, not removed.

So, now everybody is going to be writing their own code (with their own bugs) and inventing their own names for these events.

Why not do this in a standardized way and make it an option?

This is somewhat less efficient than the old way, because now the document will get an event, and then the user's own code will reflect it down to the page, from which it will then (potentially) bubble back up to the document. (Which is another reason why the reflected events have to have a different name!)

[arschmitz]

Hi just want every one to know we are listening to you and reading these comments. I am currently working on a solution i hope will please everyone. I will post more details shortly once a few things are finished up and the changes will be coming in 1.4.3

Thank you for your patience on this.

[jtara]

To clarify, I'm going to post one of our typical .js files (a short one). I believe that this is typical of the type of code that wawau0977 is talking about when he speaks of "modules". I suspect this is a pretty common design pattern for jQuery Mobile JS code.

Of note is the caching of various in-page selectors on pageinit. The new system makes writing this kind of code impossible without reflection of events down to the pages.

Edit: OK this isn't really a great example. If we want, say, to do something on pageshow, that would be done inside this closure as well. I'll edit-in an empty example below:

/*jslint browser: true, devel: true, vars: true, unparam: true, white: true, indent: 2 */
/*global jQuery */
(function photoEditListSelfEx($, window, document, undefined) {  // Ignore JSLint error on undefined
  'use strict';

  // Note that edit_list.js now handles most of photo_edit's JS needs.
  // Only need new Photo and new Drawing code
  $(document).on('pageinit', '.page_edit_photo_list', function() {
    var $page = $(this);
    var auditID = $page.data('audit-id').toString();
    var $list = $page.find('.one_to_many_item_list');
    var $newPhotoBtn = $list.find('.nav_to_new_photo');
    var $newDrawingBtn = $list.find('.nav_to_new_drawing');

    $page.on('pagebeforeshow', function() {
      // Do somewhere here before the page is shown. Typically, populate something,
      // hide/unhide something, clear "active" classes, etc. etc.
    });

    $newPhotoBtn.on('vclick click', function(event) {
      event.stopPropagation();
      event.preventDefault();
      if (event.type === 'click') { return; }
      var $a = $(this);
      var $btn = $a.closest('.ui-btn');
      $btn.addClass('ui-btn-active');
      $.post( '/app/Photo/new_photo', {id: auditID} );
     });

    $newDrawingBtn.on('vclick click', function(event) {
      event.stopPropagation();
      event.preventDefault();
      if (event.type === 'click') { return; }
      var $a = $(this);
      var $btn = $a.closest('.ui-btn');
      $btn.addClass('ui-btn-active');
      $.post( '/app/Photo/new_drawing', {id: auditID} );
     });

  });

}(window.jQuery, window, document));

[arschmitz]

@jtara thank you for your example however pageinit is an event issued by the page widget it is only being deprecated because it is no longer needed. It's original purpose was it provided a particular timing needed for some widget auto enhance code. However this was due to our old event based autoinit which we have since replaced with a non event based solution which allows for better timing so no the page widgets built in create event can be used and init will be removed. If you have a use case where pagecreate does not properly replace pageinit please open a separate issue for this.

However this issue is about page events vs pagecontainer events which is a very different issue.

Note: looking briefly at your code the only thing you need to do is change pageinit to pagecreate in your first binding.

[jtara]

^ Yes, I understand pagecreate is roughly equivalent to old pageinit.

pagecreate is still fired on the page, not the container? (Yes, I see that the page widget now has only two events - pagebeforecreate and pagecreate...)

But what about pagebeforeshow (or equivalent?) How can I get a callback on the equivalent of pagebeforeshow and package it as above? This will still work only because pagebeforeshow is currently only deprecated. But it is slated for removal in 1.5.

OK, I guess I can listen at the document level within my module, and test with an if statement. Was a lot neater to just bind to pagebeforeshow, pageshow, pagehide etc. within the pageinit (or pagecreate) callback.

This means if you have a bunch of modules, you will have a bunch of document-level callbacks needlessly listening to stuff they don't need to listen to, testing with an if statement, and then deciding "nope, not interested in this, this isn't me!"

Is this inefficient? Probably not very. Should be roughly the same as what is already going on when you delegate to document. But you'll note that my code does't delegate to document. It binds to page (for pagebeforeshow in the example.) And is listening on document and if-testing inefficient vs that binding? Probably only slightly so. But it's more code than was previously needed, and is a messy solution for the developer.

Can we please have something in the documentation similar to this for 1.4?:

http://bradbroulik.blogspot.com/2011/12/jquery-mobile-events-diagram.html

[Palestinian]

@jtara here you go http://jqmtricks.wordpress.com/2014/03/26/jquery-mobile-page-events/

[Palestinian]

@arschmitz thank you, we look forward to seeing page events revived.

[wauwau0977]

@arschmitz, @jtara, @Palestinian, @simsam7, @livewire1407: These are great news. What a great promise and what a quick reaction time... Big thank you :-)

[Palestinian]

@wauwau0977 Yup, great news from a great team.

[simsam7]

Thanks @arschmitz and the jQM team for responding to feedback like this & also thanks to @Palestinian and @wauwau0977 for pushing for it in the way that you have! :-)