make m.render aware of multi-app scenarios about mithril.js HOT 8 CLOSED

Not only redraw. Isn't, or shouldn't be m.start/endComputation also chained to a specific module? Overall I'm having problems understanding how mithril works in multimodule scenarios. I'd expect something like:

var app = m.module(container, {
  controler: function (app) {
    app.start/endComputation();
    app.redraw();
  },
  view: ...
});

Also support for no initial container, but just expose the root element as a documentFragment so I could insert it wherever I want:

var app = m.module({ controler: ..., view: ... });
app.el; // documentFragment with the app

I also don't understand how mithril redraws when bound events are triggered. For example:

m.module(container, {
  container: function (app) {
    this.add = function () {};
  },
  view: function (ctrl) {
    return m('button', { onclick:  ctrl.add });
  }
});

When onclick is triggered, how does mithril know to redraw? And how does it know what to redraw?

from mithril.js.

@darsain re: start/endComputation, yes the limitation affects those methods as well.

re: support for no initial container - you should be able to use a detached wrapper container element that you move manually, if you need to move it more than once.

re: how Mithril knows when to redraw: m.render internally wraps event handlers in a start/endComputation context. It also wraps around m.request, and long story short, Mithril waits until all the code within an event handler context is done running before running the redraw. The implementation is pretty simple; it just consists of a counter that is incremented on startComputation and decremented on endComputation, and correct placement of the methods to create a logical chain. Once endComputation detects a count of zero, it redraws. There's one caveat to this: Mithril throttles redrawing if it happens too often. In that case, redraw calls are dropped, and only a single call is scheduled at the next animation frame.

Redrawing consists of re-running the view function, which is relatively cheap, since the DOM is the bottleneck in templating systems. Mithril views operate exclusively with js data structures and only touches the DOM if needed - it keeps a cache of the virtual DOM tree and diffs any new values to determine when to do updates. On top of that, there are also various optional optimization tools to obtain varying levels of aggressiveness if needed.

from mithril.js.

So I thought about this for a while and there are two slightly different scenarios that need to be supported:

• multi-island: the same app has multiple "islands" (e.g. an widget on the header and another on the left column) and they share a model layer that could update templates in different widgets in the page. The most likely use case for this scenario is using Mithril to progressively add features here and there in a legacy app
• multi-tenancy: there are more than one app in the page, which should NOT interact with each other. The most likely use case for this is creating a embeddable widget that 3rd party developers/consumers can add to their own sites (which may or may not run Mithril apps themselves)

The first case can actually be supported without an API break, but it would involve an app-space integration caveat (much like integrating around 3rd party libraries as per existing docs, so I'm ok w/ it).

The second case will probably require a new API point to be exposed. I'm a bit on the fence about this one, because the use case is not very common, and this feature could be abused for premature performance optimization.

from mithril.js.

I added support for the multi-island scenario in origin/next. This is scheduled to be released in v0.1.9

I did NOT add the support for multi-tenancy because I don't believe that scenario is common enough (and slow enough to warrant adding a new API point to get around it), although I did some refactoring to make it easier to allow it in the future.

from mithril.js.

@lhorie,

Thanks for all the hard work! I am really enjoying Mithril overall. I am currently using Mithril to implement a video player, just as a proof-of-concept.

In my case, multi-tenancy would be ideal as I was thinking of embedding multiple instances of the video player on the same page (e.g. for different videos).

I am not sure if this would pass the "common enough" threshold, but do you have an idea of when or if you will add multi-tenancy support?

from mithril.js.

Hi @carlosmontes, it's possible to have multiple Mithril applications / widgets on one page without 'multi-tenancy' (this is what @lhorie is talking about when he mentions about 'multi-island'). The only problems occur if you want to do this and use m.route (a URL change might be useful for one app but reset another) and m.startComputation / m.endComputation (if one app decides to block rendering, which m.request will do unless you pass the background: true option, then the other apps will be blocked during that time too).

But it's always possible to make changes to an app to avoid m.startComputation / m.endComputation. Here's a demo of a video module factory for Mithril: Mithril updates the elapsed time on playback and plays or pauses the video on click. As you can see, there's no problem with running 2 of these on the same page.

from mithril.js.

Thanks for that explanation/example, @barneycarroll! My struggle seems that I tend to over think the problem. Mithril keeps it simple, so should I.

from mithril.js.

@carlosmontes ah but Mithril is deceptively simple — that's why it's so easy to overthink the problem! ;)

from mithril.js.