-
Notifications
You must be signed in to change notification settings - Fork 7
Description
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
- File
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.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status