[docs] Add Grid List TypeScript demos

[Dudrie]

This are the typescript demos for the grid list components.

• I have followed (at least) the PR section of the contributing guide.

[mui-pr-bot]

No bundle size changes comparing 2c2075e...94cc041

Generated by 🚫 dangerJS against 94cc041

[sperry94]

Everything looks good! For tileData.ts though, I would just add a tileData.d.ts file and define the type that is exported by tileData.js. That could look something like:

export interface TileDataItem {
    img: string;
    title: string;
    author: string;
    cols: number;
    featured: boolean;
}

declare const tileData: TileDataItem[];

export default tileData;

That way you don't have to redefine the values of tileData!

[Dudrie]

Everything looks good! For tileData.ts though, I would just add a tileData.d.ts file and define the type that is exported by tileData.js. That could look something like:

export interface TileDataItem {
    img: string;
    title: string;
    author: string;
    cols: number;
    featured: boolean;
}

declare const tileData: TileDataItem[];

export default tileData;

That way you don't have to redefine the values of tileData!

I liked that idea, so I tried to do it. However, after adding the definition file, docs:typescript:check reports Test file should not use a relative import. Use a global import as if this were a user of the package. See: https://github.com/Microsoft/dtslint/blob/master/docs/no-relative-import-in-test.md on all files using tileData.

The question is: How do one solve this problem?

• Should we stick with the solution of creating the additional file (like it's done now) because the js demos get created from the ts demos so the data.
• Or should we go with the definition file and ignore the tslint setting (which would probably cause confusion at the people reading these demos later?)? 🤔

For now, I won't change it due to the linting error.

[oliviertassinari]

• The import of the tileData file is preventing us from enabling the Codesandbox edit links. One option si to inline & duplicate the data set in each demos.
• I'm confused by the error: A test file should not contain relative imports;. Are we linting a test file? Should we keep this rule? How should I use no-relative-imports microsoft/tslint-microsoft-contrib#435

[sperry94]

I think that rule is there to prevent someone from adding a relative import to the component in the demo (ex: GridList), which wouldn’t be helpful to readers.

I think the inline/duplication idea might be the best option

[Dudrie]

I think that rule is there to prevent someone from adding a relative import to the component in the demo (ex: GridList), which wouldn’t be helpful to readers.

I think the inline/duplication idea might be the best option

We could get rid of the "describing comments" which describe the structure of the tileDate in the demos aswell if we go down the inline/duplication route.

[eps1lon]

Since they are not meant to be editable in codesandbox the relative import is fine.

However disabling the lint rule for a file would need a comment which is preserved during transpilation. Does the CLI pick up an additional tslint.json in this directory that disables this rule?

I would also agree that a tileData.d.ts is sufficient. The tileData.ts is never actually used.

[oliviertassinari]

Since they are not meant to be editable in codesandbox the relative import is fine.

The more demos we can run on codesandbox the better. But it does not always worth it.

[Dudrie]

@eps1lon I pushed a version with tileData.d.ts and corresponding disabling comments above the import of ./tileData. However the ts demos and js demos aren't equivalent anymore and the generated js demos would contain this comment aswell.

[eps1lon]

@Dudrie Maybe try it with a tslint.json in the directory that disables that rule.

[Dudrie]

@eps1lon Done 😊

[eps1lon]

@Dudrie Much appreciated! Thanks.