Would it be bad to allow VirtualDom.node through ports?

Learn
1

I tried this:

port render : Html.Html a -> Cmd msg

and the compiler said:

The `render` port is trying to transmit a `Node` value:

11| port render : Html.Html a -> Cmd msg
         ^^^^^^
I cannot handle that. The types that CAN flow in and out of Elm include:

    Ints, Floats, Bools, Strings, Maybes, Lists, Arrays, tuples, records, and
    JSON values.

Would there be negative consequences, if ports were to allow VirtualDom.node to pass through?

1 Like
2

What would you do with it?

1 Like
3

VirtualDom.node is an opaque type. The main advantage of opaque types is that you are shielded from any change in the implementation. Serializing such an opaque type would mean that you would expose the implementation which would tie you to the implementation.

4

Is the implementation not just some HTML DOM though?

Server side rendering of static HTML using Elm as the ‘template language’.

1 Like
5

Nope. It’s a lot more complex than that.

For this purpose you might be better served by something like GitHub - zwilias/elm-html-string: Drop in elm-lang/html replacement which can serialize to a pretty `String`

6

Problem with that approach is that you then cannot share code between server rendered and browser rendered. I have a lot of code that I share between both.

But I take your point about not exposing the implementation of VirtualDom.node. I suppose it would be helpful if VirtualDom exposed a toString function.

7

What if VirtualDom had this function:

toString : Node Never -> String

This lets you toString the DOM, only if it is static.

Could that be implemented, given the internals of VirtualDom?

8

I believe elm-html-string exposes a the same API as elm/html so you could get your code to work on the client or server by replacing the import. Should be able to automate that during a build.

Server-side rendering Elm is a little hacky because there is no official SSR support (yet). But when it does land, I would expect something like React’s ReactDOM.renderToString.

In fact, elm/virtual-dom has the beginnings of SSR support in the code, it’s just not used at this point.

Anywho, what I’m trying to say is that there is no perfect or official SSR for Elm at the moment.

9

Not going to work either, but it is a reasonable idea.

I am using rtfeldman/elm-css, and I chose that rather than elm-ui so that I could stick with using CSS for responsive rendering. That has elm/html as a transient dependency.

11

Maybe it’s a bit more heavyweight than you were hoping for, but sounds like a headless browser/browser automation tool would work? I’ve used Selenium + headless Chrome/Firefox before, there’s PhantomJS and a bunch of others I’ve never used, too. Send out a message through a port when everything’s rendered, so you know when to capture the page source.

Maybe you’ve already gone down this path!

12

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.