wix-incubator / autoviews Goto Github PK

Is there an existing issue for this?

• Yes, I have searched the existing issues

The problem

`prefixItems` is a way to define Tuples in JSONSchema.

There is no way to describe a specific array in `prefixItems` and use any tool in this package to render result.

Describe the solution you'd like

Either `<AutoItems />` should support it, or it should be a similar component that will take data and `CoreMetaSchema[]` and render one-by-one item from it.

Describe alternatives you've considered

No response

Is there an existing issue for this?

• Yes, I have searched the existing issues

The problem

AutoItems props are defined as

export type AutoItemsProps = {
    render?(
        item: React.ReactNode,
        props: AutoViewProps,
        index: number
    ): React.ReactNode;
} & AutoViewProps;

which forces to provide render as a prop in JSX, as

<AutoItems {...props} render={
    (node) => <li>node</li>
}>
</AutoItems>

Describe the solution you'd like

I suggest to change the interface a bit, renaming render to children, so that

export interface AutoItemsProps extends AutoViewProps {
    render?(
        item: React.ReactNode,
        props: AutoViewProps,
        index: number
    ): React.ReactNode;
}

which allows

<AutoItems {...props}>
    {(node) => <li>node</li>}
</AutoItems>

and still allows using

<AutoItems {...props}/>

Basically, using a property named children allows to place the function as a child in the JSX

Describe alternatives you've considered

No response

• Bundling with rollup
• formatting with prettier #61
• yarn 3 #42

Is there an existing issue for this?

• Yes, I have searched the existing issues

The problem

rendering table headers and groups is too complex and requires direct usage of too many low level functions and concepts, which should be encapsulated.

Describe the solution you'd like

AutoHeaders

<AutoHeaders {...props}>
  {(header, i) => <TableCell key={i}>{header}</TableCell>}
</AutoHeaders>

used to render field names in the same order as AutoFields will render the components. The provided children callback is called for each rendered component with the field title and index.

AutoGroups

<AutoGroups {...props}>
{(name, children) => (
  <Form.Group className="shadow p-3 mb-2 bg-light rounded" key={name}>
    {children}
  </Form.Group>
)}
</AutoGroups>

The equivalent of AutoFields but also supports groups from UISchema.

The callback is called with the group name and the result of AutoFields for that group. The component by default also renders the UNGROUPED group, which we can decide to control using another prop

Example here - https://codesandbox.io/s/autoviews-demo-forked-dzc83n?file=/src/autoExtensions.tsx

Describe alternatives you've considered

No response

I guess /packages/docs folder must be moved to the /website folder.

Ideally, packages folder should contain only packages that get published on npm. docs is not being published that way.

Having docs within packages also introduces additional challenges with running build scripts. For example, before publishing, we have to build every package, excluding docs folder.

Is there an existing issue for this?

• Yes, I have searched the existing issues

The problem

Predicates are confusing. 
It seems like it should force AutoView to select that component no matter what, 
however, in fact it works like that:
The last component without predicate or the last one with predicate which returns true wins.

The idea is, when you add a component for the same type afterwards to give you option to narrow cases when it is used, so you can stay with general one by default.

Describe the solution you'd like

add relevant docs

Describe alternatives you've considered

No response

This is copy of internal issue created before autoviews was migrated to external github project

For discussion:
If onError callback blocks render then no need to fix different handlers for unmatched schema.

Right now we are ignoring error without onError handler.
We still can make use of this callback, but we also can make some run-time decisions when we know that that AutoView in so called "error" state.
In order to do this, we need couple of things

1. Save error in validate method https://github.com/wix-incubator/autoviews/blob/master/packages/core/src/auto-view/auto-view.tsx#L170-L172

if (!isValid && validate.errors!.length) {
    this.error = formatValidationError(validate.errors![0]);
    if (onError) {
        onError(error)
    }
}

2. propagate error to child AutoViews https://github.com/wix-incubator/autoviews/blob/master/packages/core/src/auto-view/auto-view.tsx#L154-L160

return (
    <AutoViewLogic  
        {...this.props}
        error={this.error}
        schema={subSchema!}
        validation={false}  
    />
);

3. Create error component in repository

const repo = new ComponentsRepo();

repo.registerError({
    name: 'error-component',
    predicate: props => {
        return props.error.schemaPointer === props.schemaPointer
    },
    component: props => (
         <>
              <h2
                   children={props.data.message}
              />
              <pre
                    style={{backgroundColor: red}}
                    children={JSON.stringify(props.error.data)}
              />
        </>
    )
})

4. call error component before any logic https://github.com/wix-incubator/autoviews/blob/master/packages/core/src/auto-view/auto-view.tsx#L85

const error = this.error || this.props.error;
if (error) {
     const ErrorComponent = components.getErrorComponen(this.props);
     if (ErrorComponent) {
          return <ErrorComponent {...this.props} error={error}/>
     }
}

(this will probably require to move validation to constructor and also more complex logic for wrappers)

Is there an existing issue for this?

• Yes, I have searched the existing issues

The problem

Right now predicate function has only current schema node argument. 
There is an idea to extend it with other entities: full JSONSchema, data, UISchema maybe.

Describe the solution you'd like

make research and implement if needed.

Describe alternatives you've considered

No response

Is there an existing issue for this?

• Yes, I have searched the existing issues

The problem

I think we should find a way to externalise validator. 
https://bundlephobia.com/package/@autoviews/[email protected]

Describe the solution you'd like

remove Ajv as deps

Describe alternatives you've considered

No response

This is copy of internal issue created before autoviews was migrated to external github project

Is there an existing issue for this?

• Yes, I have searched the existing issues

The problem

composeRepos is amazing for component records & wrappers, but it can't do much with getNodeType.
As example, here is implementation of getNodeType from two composed repos (real example from AutoCMS):

// filter-button repo
node => {
  if ('enum' in node) {
      return 'enum';
  }
  
  if (
      'additionalProperties' in node &&
      'wixDataType' in node.additionalProperties
  ) {
      return node.additionalProperties.wixDataType;
  }

  return node.type;
}
// subschemas-v1-compatible-repo
node => {
    switch (true) {
        // `$ref`, `oneOf` and `if` are in order as they were in AutoViews.render
        case '$ref' in node: return '$ref';
        case 'oneOf' in node: return 'oneOf';
        case 'if' in node: return 'if/then/else';
        case 'enum' in node: return 'enum';
        default: return node.type;
    }
}


And composed result expected to be like this:

```ts
node => {
    if ('oneOf' in node) {
        return 'oneOf';
    }

    if ('if' in node) {
        return 'if/then/else';
    }

    if ('enum' in node) {
        return 'enum';
    }

    if (
        'additionalProperties' in node &&
        'wixDataType' in node.additionalProperties
    ) {
        return node.additionalProperties.wixDataType;
    }

    return node.type;
}

Describe the solution you'd like

We may stop using default return in getNodeType, or/and change entire format.
For example, getNodeType might be some array with predicates and type values.

// Similar to repositories, huh?
const getNodeType = [
    {
        predicate: node => 'enum' in node,
        getType: () => 'enum'
    },
    {
        predicate: node => 'additionalProperties' in node && 'wixDataType' in node.additionalProperties,
        getType: node => node.additionalProperties.wixDataType
    },
    {
        predicate: node => '$ref' in node,
        getType: () => '$ref'
    },
    {
        // default predicate if needed
        predicate: () => true,
        getType: node => node.type
    }
];

Those allows to merge multiple different getNodeTypes objects. However it doesn't cover cases, when complex merge should be applied, like switching order of predicates or like ignoring duplicates.

Describe alternatives you've considered

No response

Is there an existing issue for this?

• Yes, I have searched the existing issues

The problem

Project has lodash listed in peerDependencies.

The expected behavior

Has bundled function(s) or as regular dependency.

Relevant code

No response

What is version of @autoviews/core are you using?

v1.0.3

Do you have a code demo link?

https://codesandbox.io/s/inspiring-kowalevski-x035ze

Additional information

No response