Monaca Onsen UI Discord Chat Github Repo

Vue.JS + Vanilla = opinions?

  • @munsterlander I believe ons-tabbar is persistent by default in 2.0, so all of the ons-tab do get initialized before they’re shown.

  • Onsen UI

    @theprotocol said:

    Ideally, I’d love for navigator.pushPage to expose some kind of ‘page setup’ function, specifically for injecting into the DOM of the incoming page, rather than doing everything in ‘init’, something like navigator.pushPage(page, options, callback, pageSetup).

    Yes, I actually wanted to mention it. We already planned to add some love around ons-template so we will probably implement something like that. This way you can inject custom behavior and also modify the template itself for the new page before it’s actually created. It would allow to write real templates (using handlebars or anything) in ons-template. In my mind it was something like this:

    myNavigator.pushPage('page.html', {
      templating: function(name, template) {
        return template.replace('{{placeholder}}', 'content');

    However, this may not be included in RC yet since we are focusing in bug fixes rather than new features, so probably after the release.
    Do you have any suggestions about it?

    Apart from that, we also have a rewritables object in every navigation component to inject some functionality before showing the page. This is used internally for, for example, creating page’s $scope in Angular 1 bindings. I made an example to integrate Knockout.js with beta.5 using this, so it may be helpful:

    @munsterlander In v2 the tabbar attaches all the pages at the beginning so it’s normal to see 3 or 4 init events at the same time (1 per page). It could be possible that, even though the page is attached to the DOM, its inner components are not. If you find this kind of issue, please report it and we’ll check it. It’s a bit hard to control all of this because everything is asynchronous.

  • @Fran-Diox I like the proposal for templating with options but agree that it may not be a priority for everyone. With v2 going persistent - which I had implemented awhile ago based on another one of our many conversations - it definitely solved some of my issues. The problem I had with the internal components not being attached was the inability to do data binding on controls that were not visible yet. Again, show resolved that, so I don’t think it is that big of an issue. I think its more of the fact that I need to wrap my head around init better.

    Overall, I have no issues with the current RC and it is more of changing my hacking code to proper code now.

  • @Fran-Diox I understand that it’s not going to happen right away, but I’m glad to hear your plans for improved templating. This is really critical these days since most frameworks are going with the component approach, which sadly isn’t compatible with the typical innerHTML loading mechanisms of navigators and such.

    That rewritables code looks very promising. I’ll give it a shot soon, thanks! :thumbsup:

  • @Fran-Diox FYI I’m still experiencing the same animation issue whether using rewritables or init to do the DOM attachment. You can see the bug in action if you access this on iOS, where you’ll see that the animation is completely broken because the element being attached (page-2-component.html) contains an ons-toolbar.

    I understand it might not be considered urgent, although it does seem like a bug, since I can also reproduce the animation issue by doing other kinds of processing upon page init, not necessarily just injecting a riot tag into DOM.

    edit: Tested on Android and there was no animation bug, so it’s only on iOS.