Support Map interface for props

[swannodette]

High performance Map implementations are starting to appear in modern web browsers. By supporting the Map interface users can now instead supply props as an Immutable.js or ClojureScript Map instance. This change would not even require providing an equality hook for the first pass as users can memoize props themselves.

For users embracing immutable data this is a huge change, it means that styles can be defined in code, overridden and shared efficiently. React DOM elements with memoized immutable props can be skipped over, etc.

[levand]

I second this - it would be a huge boon to performance when using React from ClojureScript.

[bhauman]

Yes supporting Map will allow many possibilities, cursors, etc. This sounds good.

This is actually quite a good idea. I would love to see this in React, with or without Clojurescript. Offers considerably improved styles of working in the React environment.

[brigand]

I suppose the main thing blocking this is key/ref being passed like props, and a useable syntax/api to allow this. Adding it to JSX would be pretty straight forward.

<!--  Valid -->
<div {map} />
<div {map} key={...} />
<div {map} key={...} ref={...} />
<div key={...} ref={...} {map} />
<div key={...} {map} ref={...} />

<!-- Invalid -->
<div {map} foo={...} />
<div {map} {...foo} />

But createElement is variadic, which is a problem... some potential solutions (where meta is an object with key and ref):

// breaking change
React.createElement(tag, map, childrenAlwaysAsAnArray, metaOrUndefined)
React.createElement(tag, {props: map, key: ..., ref: ...}, childrenAlwaysAsAnArray)

// add another function, this makes it explicit that react should treat the
// second argument as an opaque data structure and metadata is separate
React.createElement2(tag, map, metaOrNull, ...children)

// generic, react agnostic, array
// see #2932 – unsure if it's feasible for performance 
[tag, map, childrenAlwaysAsAnArray, metaOrUndefined]

_{Related: Consider Using JsonML as Notation for ReactElement #2932}

[skrat]

Oh, this isn't there already? +1

[mybuddymichael]

Yesssss.

[dmhood]

👍

[syranide]

Has this actually been verified? Using objects for props is exactly what objects are intended for it seems to me, the same set of known keys used over and over. Maps should have way higher mem/perf overhead than objects for props I would assume.

PS. Also how would I access a specific prop in a universal way? Not possible AFAIK.

[dmhood]

@syranide
In our case we are using immutable.js to turn component state into an immutable map/record, and would like to be able to do the same with props in order to have the same api with each object.

As far as perf goes, having a way to make props immutable (along with state) would allow us to more effectively perform equality checks in shouldComponentUpdate, and I doubt the slightly higher mem/perf cost of immutable maps would ever be much of an issue.

As it stands now we can check for state equality immediately but still have to do a form of shallow equals comparison with the props object, which is slower and also not as robust.

[swannodette]

@syranide there are many very well known old tricks to supporting the hash map interface while incurring very small overheads - a common approach is to encode small maps (which are very typical in many programs including React) as arrays.

[syranide]

As far as perf goes, having a way to make props immutable (along with state) would allow us to more effectively perform equality checks in shouldComponentUpdate

@dmhood Objects can be immutable too and immutability in itself is not enough to get away with a simple equality test. I don't know how you would even go about universally reusing non-mutated "props" between renders.

there are many very well known old tricks to supporting the hash map interface while incurring very small overheads - a common approach is to encode small maps (which are very typical in many programs including React) as arrays.

@swannodette Certainly, but that's just making them faster, it doesn't make them "as fast". An object (with a hidden class) should be be cheaper to instantiate, use less allocated memory and be faster to access. An object seems like the obviously correct DS for props (and state too) if you ask me, maps haven't replaced objects, they replaced objects-as-maps.

Anyway, I assume CJS sees it differently and it might make sense for you, but AFAIK it doesn't make any sense for "regular" React and would even come at a big "cost".

[skrat]

@syranide Can you explain what is the "big cost"?

[syranide]

@skrat this.props.foo vs this.props.get('foo') (you can't have both), then there's also memory and perf which may be more or less measurable.

[swannodette]

@syranide allocation and access costs for supporting ES6 Map interface is almost entirely in user-land. A huge bottleneck this removes is the Object iteration cost that React eats everywhere during reconciliation. Which is going to be faster, iterating over an Object with hasOwnProperty checks or iterating over a array? I've never seen the former outperform the later. Couple this with the memoization story this provides I suspect Immutable.js Map props based programs will kick regular React ones in the ass.

[syranide]

@swannodette

A huge bottleneck this removes is the Object iteration cost that React eats everywhere during reconciliation.

Object iteration is not slow AFAIK, but hasOwnProperty is at current relatively very costly (but not in IE11), but if that's really a problem then as soon as we drop IE8 it's should be safe to proceed under the assumption that no environment worth supporting breaks the object prototype I would say. There's also #3227. Or you could also provide an abstraction that returns an object and a list of keys thus you avoid the hasOwnProperty check without having to resort to other overheads related to maps.

http://jsperf.com/objvsarrxyz (and this doesn't include the overhead of actually dynamically creating and accessing the underlying array structure)

APIs shouldn't be designed from the standpoint of current performance characteristics if you ask me.

Couple this with the memoization story this provides I suspect Immutable.js Map props based programs will kick regular React ones in the ass.

How would you (realistically) perform universal fast memoization for "props"? Perhaps I'm missing something but I can't see how you would accomplish that.

Also, memoization should work equally well for objects as it does for maps, it doesn't favor one or the other.