merge-props

Merges React className, style, and DOM event handlers (onClick, onFocus, on{LiterallyEveryEvent}) by the following rules:

• className props are concatenated
• style props are shallow merged with later values taking precedence
• functions are run in sequence from left to right.

Installation

npm install merge-props

Example usage

const props = mergeProps(
  { onClick: fn1 },
  { onClick: fn2, className: 'blue' },
  { onClick: fn3, className: 'button', styles: { display: 'block' } },
  { styles: { display: 'flex', color: 'red' } }
);

<button {...props}>Best button ever</button>

The button will have a className of "blue button", a style equal to { display: 'flex', color: 'red' },and when it is clicked, it will execute fn1, then fn2, then fn3, in that order.

Why is this useful?

One useful pattern for render props is having them pass props that are meant to be spread over the returned element to faciliate communication between the parent component and the render prop element. For example, consider a Tooltip component that decorate any DOM element or React component that accepts event handlers. If the Tooltip wants to avoid rendering a wrapper around its “trigger” element, it could use a render prop to inject onMouseEnter, onMouseLeave, onFocus, onBlur, and various WAI-ARIA attributes:

<Tooltip text="Some extra information about this button">
  {props => <button {...props}>Hovering this is great</button>}
</Tooltip>

This is a nifty pattern in environments where flexibility, reusability, and ability to customize are highly valued, because Tooltip can pass event handlers as props in order to attach what it needs to the target element while allowing the consumer to retain full control over what actually happens to those props.

However, one minor weakness of this pattern is the level of boilerplate that needs to be introduced if you needed to merge those injected props with props of your own in an intelligent way. For example, lets say that Tooltip also injects a className (perhaps to change the cursor appearance of whatever is being hovered), but you also need to pass your own className to the button in order to turn it a pretty shade of blue. You’d have to do something like

<Tooltip text="Some extra information about this button">
  {({ className, ...props }) => (
    <button {...props} className={className + ' pretty-blue'}>
      Hovering this is great
    </button>
  )}
</Tooltip>

And it gets much messier if you needed to run your own event handlers in addition to the injected event handlers:

<Tooltip text="Some extra information about this button">
  {({ className, onFocus, onBlur, ...props }) => (
    <button
      {...props}
      className={className + ' pretty-blue'}
      onFocus={event => {
        // BTW if Tooltip’s API changed to not inject this, it would break
        onFocus(event);
        myOwnOnFocus(event);
      }}
      onBlur={event => {
        onBlur(event); // Sure hope this exists forever
        myOwnOnBlur(event);
      }}
    >
      Hovering this is kind of sad
    </button>
  )}
</Tooltip>

Enter mergeProps:

<Tooltip text="Some extra information about this button">
  {(props) => (
    <button {...mergeProps(props, {
      onFocus: myOwnOnFocus,
      onBlur: myOwnOnBlur,
      className: 'pretty-blue',
      style: { alignSelf: 'flex-start' }
    })}>
      I love button
    </button>
  )}
</Tooltip>

It runs Tooltip’s onFocus and onBlur right before your own handlers, combines Tooltip’s className with pretty-blue, and even merges your style prop with one that Tooltip might want to add.

Type safety

This project is written in TypeScript. Aside from class names and styles, it’s designed to merge event handlers, which are whitelisted under React.DOMAttributes. As such, the type of the input props is constrained to valid event handler names. Technically though, the implementation doesn‘t check for event handler names; it just checks to see if the prop is a function, so you could use this package to combine any kind of function props, but to me, that feels fragile. If you have a compelling reason why this package should accept any kind of function props as valid inputs, I’d be happy to hear your use case in an issue.

Gotchas

I got an error like Didn’t know how to merge prop 'foo'. What?

mergeProps knows how to merge className, style, and event handlers (any functions, in practice). If you pass it anything else, it will happily pass it through:

const merged = mergeProps({ className: 'one' }, { className: 'two', role: 'button' });
merged.role; // 'button'

However, if it receives two instances of the same prop by an unknown name, mergeProps is faced with a decision of how to merge two props that it knows nothing about. Rather than risk making a bad decision, especially one that may be hard to debug, it throws an error saying that it doesn’t know what to do:

// What? How to merge two `role` props? ¯\_(ツ)_/¯ 
const merged = mergeProps({ role: 'button' }, { role: 'presentation' });
// Error: Didn’t know how to merge prop 'role'.

Contributing

Changes should be tested and have 100% coverage:

npm test

Design changes may be considered via an issue or PR.