Is it a normal behavior to have all element properties stringified (through hast-to-hyperscript) ?

Hi, thanks for your work !!

here’s a bit of context.

I’m developing a common mark generic extensions plugin, supporting this kind of syntax: !Element[content](argument){ properties }

I’m using !Icon[My-tooltip](my-icon){ floating } for testing

My remark inline tokenizer returns this node:

{
  type: 'extension',
  data: {
    hName: 'Icon',
    hProperties: {
      tooltip: 'My-tooltip',
      icon: 'my-icon'
      floating: true
    },
  }
})

Notice the boolean property named floating.

I can properly have my corresponding react component TooltipIcon render with the following snippet (es6):

import remark from "remark"
import reactRenderer from "remark-react"
import merge from "deepmerge"
import sanitizeGhSchema from "hast-util-sanitize/lib/github.json"

import TooltipIcon from "../TooltipIcon"
import genericExtensions from "./remark-commonmark-generic-extensions.js"

remark()
    .use(genericExtensions, {
      elements: {
        Icon: {
          attributeMap: {
            content: "tooltip",
            argument: "icon",
          },
          attributeDefaultValues: {
            floating: true,
          }
        }
      }
    })
    .use(reactRenderer, {
      sanitize: merge(sanitizeGhSchema, {
        tagNames: [
          "Icon",
        ],
        attributes: {
          Icon: [
            "className",
            "tooltip",
            "icon",
            "floating",
          ],
        },
      }),
      remarkReactComponents: {
        Icon: TooltipIcon
      },
    })
    .processSync(body, {
      commonmark: true,
    })

Whereas my floating property is effectively boolean inside the HAST tree generated by remark, it is stringified by hast-to-hyperscript at this line, called here in remark-react.

In order to avoid a react PropTypes type warning, i’m actually forced to also allow String in addition to Boolean propTypes for the floating property inside my component. I then coerce the floating property back to boolean, in order for the subcomponent (which requires floating to be boolean) to be happy.

Here’s my TooltipIcon component:

import React, { PropTypes } from "react"
import IconButton from "react-toolbox/lib/button"
import Tooltip from "react-toolbox/lib/tooltip"

const TooltipButton = Tooltip(IconButton)

const TooltipIcon = props => {

  const { floating, ...otherProps } = props
  if (floating === "true") {
    otherProps.floating = true
  }

  return (
    <TooltipButton
      { ...otherProps }
    />
  )
}

TooltipIcon.propTypes = {
  floating: PropTypes.oneOfType([
    PropTypes.bool,
    PropTypes.string,
  ]),
  tooltip: PropTypes.any,
  theme: PropTypes.object,
}

export default TooltipIcon

I hope you get the general idea, and if you can tell if it’s a requirement to have every property stringified. Because in this case only String properties can be passed to React if i’m not mistaken.

[medfreeman]

Do you know if React’s VDOM accepts non-strings in normal elements too, or just for components?

The answer is basically yes, but the processing differs depending on the node / attribute:

• style, dangerouslySetInnerHTML, children, __html, suppressContentEditableWarning are processed separately, i won’t go into the details, info here (code ref)
• properties corresponding to event handlers are bound to the passed function
• if it is on a custom component (i.e. polymer, that contains a dash in its tagname) and the property isn’t reserved and doesn’t contain invalid chars, it goes through setValueForAttribute, is stringified ('' + value) or removed if value is null
• if not the above, and attribute is in this list (code ref) or a data- or aria- attribute, it goes through setValueForProperty where:
  • if prop has mutationMethod, for now that only applies to the value property and has a value, it is stringified, with exceptions for number validation in input type fields (for browser validation/focus/blur reasons)
  • if prop value should be ignored, it is unset
  • if it has a MUST_USE_PROPERTY flag (ref. here), it is passed as is to the corresponding dom object property
  • if not one of the above, and:
    • element namespaced (i.e. svg) -> namespaced and stringified
    • is boolean: AND true ->set attribute to empty string / OTHER value -> stringified
• The “unknown” properties are dropped for now, but should be passed on from ~v.17, see facebook/react#140, current PR facebook/react#7311

References in order:

Differences with html attributes

All Supported HTML Attributes

updateDOMProperties

setValueForProperty and setValueForAttribute reference

shouldIgnoreValue

propertyInfo initialization

propertyInfo config definition

mutator function

facebook/react#140 facebook/react#7311

[medfreeman]

Should i just make a PR updating hast-to-hyperscript ?