ntharim / vdom-to-html Goto Github PK

The vdom structure:

var test = svg('svg',
    svg('use', {
      'xlink:href': "symbols.svg#symbol1"
    })
);

Renders fine in the browser but vdom-to-html outputs <svg><use></use></svg>

Let me know if I can help!

I'm interested in rendering Markdown files using this library, but reading the code it seems impossible, even if I use a Widget or a Hook.

data-* and aria-* should be handled as attributes rather than have a special case for them as properties.

https://github.com/nthtran/vdom-to-html/blob/fe04172917f596dc4b24a4b0dc20c747c9454144/test/test.js#L58-L64 is currently

  it('should render `data-` and `aria-` properties', function () {
    var node = new VNode('web-component', {
      'data-click': 'clicked!',
      'aria-labelledby': 'label'
    });
    assert.equal(toHTML(node), '<web-component data-click="clicked!" aria-labelledby="label"></web-component>');
  });

these shouldn't need to be handled as a special case in properties because it is inconsistent with what virtual-dom does and so any rendering code which uses these as attributes will not produce the same results in the browser. as attributes these don't need any special handling.

  it('should render `data-` and `aria-` attributes', function () {
    var node = new VNode('web-component', {
      attributes: {
        'data-click': 'clicked!',
        'aria-labelledby': 'label'
      }
    });
    assert.equal(toHTML(node), '<web-component data-click="clicked!" aria-labelledby="label"></web-component>');
  });

is this something you want to continue to support or are you open to dropping them?

This looks like it's by design - I see a test that verifies that it doesn't render custom attributes here:

https://github.com/nthtran/vdom-to-html/blob/master/test/test.js#L41

Wondering what the motivation behind this is, as I'd like to use this library without removing custom attributes.

Shouldn't toHTML(h('div', {dataset: {key: 'value'}})) render to <div data-key="value"></div>? Today it is giving <div></div>, although toHTML(h('div', {attributes: {'data-key': 'value'}})) works.

This one really got me: vdom-to-html ignores these three microdata properties when lower-cased.
property-config.js uses camel-cased properties, but I cannot find any reason for those when peeking through schema.org.

Is this intentional? Am I missing something? Or, is this a bug?

please add a 'beautify' option to return html that formatted with line breaks and indentation

I'm having some problems with value attribute being rendered as [object Object] instead of its actual value. This is because a soft hook is created and the following code does not render it because of the second condition value.namespace.

if (isVHook(value) && value.namespace) {
   ret += ' ' + createAttribute(name, value.value, true);
   continue;
}

As an example this test fails if added:

it('should render hooks', function () {
  var node = h('input', { type: 'submit', value: 'add' });
  assert.equal(toHTML(node), '<input type="submit" value="add">');
});

Hi,

These implementations look very similar to me:

https://github.com/Matt-Esch/virtual-dom/blob/master/vnode/vnode.js
https://github.com/Matt-Esch/vtree/blob/master/vnode.js

However the latter is resulting in an empty result. test:

var toHTML = require('vdom-to-html');

var VNode = require('virtual-dom/vnode/vnode');
// var VNode = require('vtree/vnode'); // Doesn't work

toHTML(new VNode('input', { className: 'name', type: 'text' }));

Currently https://github.com/Raynos/mercury is not working either, I'm wondering if it's also using a vnode which is incompatible?

Thanks

Since virtual-dom 1.1 added better support for svg attributes, though our use-case doesn't require changing svg content, innerHTML works fine for now.

Discovered this when I try to convert h('meta', { charset: 'UTF-8' }) to no avail.

I don't know why React is doing that, but I can't think of any instance where charSet is used in DOM, they should all be charset. Maybe React has different behaviour internally? Can't tell from related pull request.

In DOM: