We need to transform codebase from standard JavaScript to TypeScript. Inspiration can be found in private RACOM repositories where TypeScript is already used. If you use parts of configurations from RACOM repositories, it would be easier for you as we would not have to much comments on that.
We would like to use strict typings, so that any type is prohibited if not necessary.
Speaking of convention where to put type definitions. It seems the most practical for us to have structure of component like this:
- Directory
<ComponentName>
- File
index.ts - exporting named export
- File
<ComponentName>.tsx - component itself
- File
<ComponentName>.types.ts - all types associated with component
If you thing that <ComponentName>.types.ts is not necessary, place type definitions into <ComponentName>.tsx before definition of component, but separate file seems more friendly to us (at least for now). You can of course look into other libraries like Material UI, Ant Design, ..., how they work with type definitions.
There is lot of props that are defined as enums. Like colors, variants, priorities etc. Those definitions should be placed in some global file (e.g. src/types.ts, src/definitions.d.ts, ...) , do not define them per components, we do not want to repeat those definitions in each component.
Speaking of "API" section in documentation. As @mbohal wrote in the email, do not try to fix "table of props". It will be solved by @mbohal in following issue as we use our custom documentation platform.
We need to transform codebase from standard JavaScript to TypeScript. Inspiration can be found in private RACOM repositories where TypeScript is already used. If you use parts of configurations from RACOM repositories, it would be easier for you as we would not have to much comments on that.
We would like to use strict typings, so that
anytype is prohibited if not necessary.Speaking of convention where to put type definitions. It seems the most practical for us to have structure of component like this:
<ComponentName>index.ts- exporting named export<ComponentName>.tsx- component itself<ComponentName>.types.ts- all types associated with componentIf you thing that
<ComponentName>.types.tsis not necessary, place type definitions into<ComponentName>.tsxbefore definition of component, but separate file seems more friendly to us (at least for now). You can of course look into other libraries like Material UI, Ant Design, ..., how they work with type definitions.There is lot of props that are defined as enums. Like colors, variants, priorities etc. Those definitions should be placed in some global file (e.g.
src/types.ts,src/definitions.d.ts, ...) , do not define them per components, we do not want to repeat those definitions in each component.Speaking of "API" section in documentation. As @mbohal wrote in the email, do not try to fix "table of props". It will be solved by @mbohal in following issue as we use our custom documentation platform.