asbjornh / view-models Goto Github PK

import Abcd from 'ab-cd';

Blabla.propTypes = {
  a: PropTypes.shape({
    b: PropTypes.exact(Abcd.propTypes), // Should error here
  })
}

The above example should have an error but it does not

A valid typescript boolean is boolean

If the same component is referenced in more than one prop, there will be more than one import statement for the corresponding type. There should be only one import statement for each type

Arrays of string enum are now output as

type A = "a" | "b" | "c"[];

The correct output should be

type A = ("a" | "b" | "c")[];

PropTypes.oneOf([1, 2, 3]) is currently transformed to "1" | "2" | "3" in typescript. The correct output is 1 | 2 | 3

const Link: React.FunctionComponent<LinkProps> = () => null;
export default Link;

This throws with the following error:

Cannot read property 'typeAnnotation' of undefined

Sometimes things don't build because of inconsistent naming, such as naming a file youtube-player but naming the component YouTubePlayer. In this case, the output import statements would be:

import { YouTubePlayer } from './YoutubePlayer';

This would fail, since YoutubePlayer.d.ts exports YoutubePlayer (lowercase t)

There should be an eslint rule to validate that identifier names match the pascal case version of file names

I'll use C#/Razor as an example here.

After generating the classes, one still has to stringly type the path to the component in the global scope:

@Html.React("Components.Header", model.Header)

It would be nice to be able to generate something to remove this, where the something generator would receive a list of the metadata for all processed components.

We could then generate a static class

public static class ComponentPaths
{
   public static string Header => "Components.Header";
}

and do:

@Html.React(ComponentPaths.Header, model.Header)

This will give us compile time safety for the now stringly typed component paths.

When a components uses a HOC in the export declaration (export default someHoc(MyComponent); a class isn't generated for the component and no errors are thrown. An error should be thrown when using HOCs.

Add compiler option (header?) that can be used to insert comments or anything really at the top of generated files

When running Linter and using syntax like this
https://gyazo.com/6bcf845196aedf7900ae71c4e8eb29f7 I get such errors
https://gyazo.com/f334f03a3669c988924abf1f1c569efe . For some models, I exclude properties from the generated models (using 'ignore' attribute), however, the @babel/eslint-parser highlights this syntax with an error, what can be the reason for such a behavior?

Just run the 'yarn run lint:fix' in the root folder of the example attached in order to reproduce the problem.

I would appreciate any help from your side, thanks in advance
ESLint-issue.zip

If props are passed manually, fewer guarantees can be made about generated viewmodels.

const Parent = ({ childProps }) => (
  <Child propA={childProps.propA} propB={childProps.propB} />
);

Parent.propTypes = {
  childProps: PropTypes.shape(Child.propTypes)
};

In this example, there is no guarantee that a valid Parent model will result in valid data being passed to Child because Parent contains a manual mapping from props to Child props. In the next example, we can guarantee that a valid Parent model will result in a valid Child model as well:

const Parent = ({ childProps }) => <Child {...childProps} />;

Parent.propTypes = {
  childProps: PropTypes.shape(Child.propTypes)
};

It would help a lot if the eslint plugin could warn about cases such as the first one. This would probably have to be pretty naive in order to keep complexity and scope down. The simplest heuristic seems to be checking whether a prop is a reference to another component (shape(SomeComponent.propTypes)) and also check whether that prop is being spread or not

There should be a way for the parsed file to provide prose that is output in generated files. Maybe a JSDoc comment connected to the type definition or a .viewModelDoc property for react components.

It seems that using double stars in globs to match an arbitrary number of directories is unsupported.

Given f.ex. client/**/*.jsx as input, I would expect both client/contexts/cool-context.jsx and client/components/cool-component/cool-component.jsx to be processed.

There doesn't seem to be any documentation for the CLI, but using a single star to match filenames works fine. Using double stars matches a single directory, but not an arbitrary number of directories.

Lists, for example from PropTypes.arrayOf are output as:

[string]
[{ blahblah: string }]

The correct output is:

string[]
{ blahblah: string }[]

Add rule that warns when specifying a meta type for a prop that isn't specified in propTypes.

In some rare cases, stuff can't be typed without the use of any/PropTypes.any. C# and Kotlin support this through the dynamic type, and typescript with any.