Consider using .valueOf() before providing fragment warning.

[rhys-vdw]

We updated and started getting this warning everywhere:

Warning: Any use of a keyed object should be wrapped in React.addons.createFragment(object) before being passed as a child.

Took me a while to realize that it was because we were using Number instances in our jsx.

I wonder if it would be acceptable to apply .valueOf() first (if present) to legalize this situation?

// Obviously we're not literally doing this:
<span>{new Number(5)}</span>

[sophiebits]

Why are you using Number objects instead of numbers?

[rhys-vdw]

Fair question.

In this case I'm moving Backbone code to React. I use a function to convert incoming JSON into an Immutable.js Map, which maps fields to types like so:

  types: {
    price: Money,
    unbilled_fixed_value: Money,
    unbilled_hourly_value: Money,
    unbilled_value: Money,
    assigned_user_ids: Immutable.Set,
    price_type: PriceType
  }

Here Money is a class that inherits from Number and does some things relevant to money. The Money constructor expects a string from the server. It's used everywhere throughout the application so it's preferable to continue using it.

So, in my render() function I'd like to be able to use {item.get('unbilled_value')} without getting this warning. Note that there is actually no problem rendering the value, but the warning is raised. The warning is slightly misleading too in this instance, since (insofar as I understand) createFragment wouldn't be appropriate here.

For what it's worth, I probably wouldn't have chosen to subclass Number for this task were I starting from scratch. But it is what it is.

[sophiebits]

I don't think we're going to support this, sorry. You can use <span>{+item.get('unbilled_value')}</span> which hopefully isn't too inconvenient.

Note that there is actually no problem rendering the value, but the warning is raised.

We usually warn for things that will break in future versions. This particular pattern will break hard in 0.14.

[rhys-vdw]

Fair enough, thanks for the explanation.