# Validate hooks approach in v0

### Problem

After experimenting with v8 hooks v0, we found a list potential issues/problems. This month, we'll try to finish converting the v0 Button to completely reuse the same hooks from the `react-button` package.

### Apetite

We want the same hooks and utilities in v0 and in v8. The project shuold last 3-4 weeks. We'll go heads down and solve the open issues/discussions discovered in August hacking.

### Solution

Problems that we need to solve:
1. **children vs content behavior** - v0 will adopt v8 approach.
1. **children should never be an object** - this is really important as it conflicts react notion of children
1. **v0 + v8 build issues** - not that important but it needs to be solved if we want to actually move forward with this.

### Risks

Time sink due to deep discussions with no clear "right" answers. We'll prioritize getting v0 and v8 onto the same solution so we can collectively solve the same problem set.

Not landing on something to replace compose [#14733](https://github.com/microsoft/fluentui/pull/14733) (this is not a big risk as compose was never used by our v0 clients, but we should at least convert internal usages of compose for the `Box` component that we have already in v0.)

### Out of scope (No-gos)

Anything beyond the these points :) We're really wanting to ensure it will be finished in reasonable time.

## August Hacking Findings (Levi, David, Marija)

**Expected**: Did not expect any default props for `icon`, `loader`, or `content`.
**Actual**: The state returned from useButton wrapped all slots in spans via default props of `{ as: 'span' }`.
**Proposal**: Do not add default props for `as` unless required for base usage.

The intuition is also that there is no way to skip rendering these slots since there are always props defined.
There may be additional magic to capture this case, but it is not intuitive.

### mergeProps root vs top-level keys

When merging props, it was confusing that some keys (classes, styles) go under `root`, while other keys (children) to at the top-level of the object.
Since all these props are intended for the "root element", it is unintuitive to have to put them in two different places:

mergeProps(state, {
  children: props.content, // <----------------------------
  dataFoo: 'works',
  root: {
    dataFoo: 'fail :(', // <----------------------------
  },
});

### mergeProps `children` is an object

**Expected**: To pass a string to the `children` "prop" in `mergeProps`
**Actual**: We need to pass an object since `children` is actually a props object for a child element and not the actual `children`.
**Proposal**: Keep the definition and behavior of `props.children` in mergeProps consistent with React's definition and behavior of children.

In order to render a string, we needed to defined props.children.children = 'my string'

const myProps = {
  children: {
    // this slot is called 'content' in v0
    children: props.content, // children.children is extra weird
    className: classes.content,
    styles: resolvedStyles.content,
  },
};

mergeProps(state, myProps);

### React Children expectations

We have these constraints:

1. Children can never be an object, why? Must be valid React children
1. Props objects passed to mergeProps should be identical to props objects spread on components
1. Library should be able to render props.children in a helpful place in the template
1. User must be able to redefine ALL children if they need to