Mithril.js: Render without DOM?

[yanns]

It is possible to render a component without a DOM, in node.js for example?

React has the function React.renderComponentToString for example to allow that.
Quite useful to pre-render the page on the server and for tests in node.js.

[lhorie]

Yeah, there's a couple of ways to do it.

One way is to implement a function that takes virtual elements and spits out an HTML string. A virtual element is a object that looks like

{tag: "div", attrs: {id: "foo", class: "bar"}, children: [ "a text node", /*other virtual elements */ ]}

You'd call this method instead of m.render if you're piecing things together manually.

I have a snippet that does this somewhere in my hard drive, but I haven't published it w/ the project. I'll go dig it up, but in the meantime, if you're feeling up to writing a bit of code, it's just a recursive function and not that hard to re-implement.

There's also an undocumented way, which is to mock the window dependency with the m.deps method. I have an example of this in the tests folder (mock.js), and a mock implementation that you can adapt to produce html strings as a side effect.

This second method is probably the more useful one, since it allows you to run the entire app on a programmable "browser"-in-the-server without the need for PhantomJS or similar.

I'm planning on releasing both the virtual-dom-to-html-string utlility method and a proper node.js adapter when I get the chance.

[Raynos]

@yanns

you can use min-document or html-element as minimal DOM implementations.

Both of those support serializing their DOM representations to a HTML string.

You can also write a stringifier for a vdom representation by finding another stringifier and adjusting it to support mithril vdom like stringify.

[activestylus]

Did you ever release that dom-to-string utility?

[Raynos]

https://github.com/alexmingoia/virtual-dom-stringify

[activestylus]

Cheers Raynos!

[StephanHoyer]

https://github.com/StephanHoyer/mithril-node-render

[lhorie]

@StephanHoyer nice :)

I'm actually working on something similar too. A few things to consider: empty elements (e.g. <br />), and maybe considering handling events based on the value type instead of their names

[StephanHoyer]

good point!

Fixed this

[StreetStrider]

@lhorie, @StephanHoyer, @Raynos
Hello, everyone. Can you tell what's the status on this? Which soultion is preferred now?
@yanns, are you using some particular solution and if yes, which one?

[lhorie]

@StreetStrider I'd use @StephanHoyer's library

[tivac]

@StreetStrider we've been using @StephanHoyer's library for months, it's exactly what you'd want.

[StreetStrider]

@lhorie @tivac, Thanks for help! I'll certainly investigate it.
Also, thanks for keeping mithril in way of modularity and composability.

[amireldor]

Hello persons. I've been trying out @StephanHoyer 's mithril-node-render. There's this issue with parameters to routes mentioned in his article (about his package). In order to get a parameter in your controller you have to do something like var stuff = params ? params.stuff : m.route.param('stuff').

Quoting:

This can be improved of cause. I simply did not come up with an elegant solution for this. Any ideas?

So, did anyone did come up with an elegant solution?

[isiahmeadows]

For what it's worth, for this reason alone I'm considering resurrecting my m-iso. Mithril itself simply relies too much on the DOM to sufficiently be useful in isomorphic applications. That's how it can stay so small. You'd be effectively reimplementing Mithril along with half of the DOM if you were to try to shim it into working in Node, especially if you're doing more than just rendering simple views and controllers (no network).

It's not elegant to remove Mithril from the DOM, and matter of fact, its source code isn't very elegant to begin with. Imagine spaghetti logic that manipulates quantum references to improbability drives. That's Mithril at the moment, and that's why @lhorie is working on a rewrite (thankfully).

As for m.route.param, that's a pretty simple concept to implement. The biggest problem with routing currently is Unicode. But to be honest, Unicode sucks. All it does is complicate things beyond all known recognition.

_(Well...that and make it possible to write an app that supports 15 different languages, but let's ignore that for now...:smile:)_

[ancms2600]

i made this one in 35 lines if anyone is interested
https://gist.github.com/ancmikesmullin/102bcba5836362d46f4c0e7880e5a98f