White boarding session: Props merging

"a well-designed system makes it easy to do the right things and annoying (but not impossible) to do the wrong things."

Context

Currently, there are some HS API's that are designed to be combined with the use of React-utils hooks together. Depending on the API/use-case, the user experience can be overly cumbersome or visually exhaustive.

Example:

 const rovingTabIndexProps = useRovingTabIndex()
  const submenuNavProps = useSubmenuInteraction()
  const submenuStyles = getMenuProps({
    label: props.label,
  })
  const listItem = getMenuItemProps()

  function onTriggerBlur(e) {
    submenuNavProps.trigger.onBlur(e)
    rovingTabIndexProps.onBlur(e)
  }

  return (
    <li {...listItem.menuListItem}>
      <button
+        {...listItem.menuItem}
+        {...submenuNavProps.trigger}
+        {...rovingTabIndexProps}
+        onBlur={onTriggerBlur}
      >
...

Problem to solve

What can we do within the Pando internal tools (non-user facing) can we create to easily combine API's whether they are React-utils hooks or HS helpers.

Idea session (15 min)

The original design for HS is to create helper functions that return presentational meta (i.e. a11y and style related props), not dynamic meta (i.e. event handling, etc.).

IDEA: How can can we make Pando libraries easier/faster to write without using components? We support the use of components, but initially, they might not always be the answer to all problems.

1. Something like class merging except using helper merging that's compatible for any Pando API (C)

• Can use only in HS, or...combine with HS and RU hooks

2. ⚠️ Return a fleshed out component in X framework (similar to the concept of what React does for JSX tags)? (C)
3. ⚠️ Return something functional that applies properties rather than returns them (T)

• Similar to #2, however...future React has [deprecated all functional component helper APIs]
• Create custom helper that returns X component from X framework? (https://beta.reactjs.org/reference/react/legacy)

4. Allow API chaining (vanilla JS APIs, .map().filter())? (C)
5. Create a multi-language plugin that allows a new syntax that interprets multiple API's and creates the props[^1] (C)

• Requires pre-processing to be used in user's setup
• Would also eliminate the need for using functional helpers for people who are struggling with the concept of headless APIs

6. ⚠️ Higher Order helper that combines everything on the user-side (T)
7. Just provide a new API that does it all for X specific use case (C)

• Instead of importing 4 APIs, the user imports 1 that's for a very specific use case that combines them all internally (lego block specifically for lighting)

8. Do we update HS to now except dynamic meta (i.e. events, and default props)? (T)

• We are doing this in a minimal way in React Hooks
• There is a slight complication when we become more agnostic that will complicate the process (i.e. React, Vue, Angular, Svelte, HTML all have different props APIs). Should this matter?
• ⚠️ Might be a user API, not internal

9. Do we create a vanilla JS hook to use internally that natively combines APIs (how JS functions like reduce accept callbacks)? (C)

--

[^1]: Each framework would use a unique prop/attribute that utilizes a plugin Pando provides that allows them to natively write a new prop/attribute on a component that would list the API's like a class (or similar).

// Custom Pando plugin would allow React/X framework to interpret attribute "pando:btn"
<button pando:btn>Special Button with multiple Helpers</button>

Action Items

Return next week to create new footnote example usage APIs from current ideas to experiment with how they might actually work (footnotes).