You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Menu PR tries a different approach to defining types, utilizing namespaces. The type definitions are also placed in the same file that has the implementation.
Not having to jump between files when changing/adding props is nice.
Having separate .types.ts files result in empty .types.js after transpilation. Placing everything in one file prevents this issue.
Using namespaces frees us from renaming identifiers when exporting from barrel files and makes it easier to control what is public and what is private (as we do it when defining a type, not in the index file)
The usage of types in namespaces is a bit weird and not very JS-like (props: Menu.Root.Props). On the other hand, it works pretty well with VSCode suggestions (you type "Menu.Root." and see everything related to the root, which is exactly what you need)
ESLint doesn't understand declaration merging well, and I had to disable a rule to make all this work.
We agreed to extend this pattern to the whole codebase.
To summarize, the following changes are needed:
Move types from X.types.ts to X.ts(x) (for example SwitchRoot.types.ts -> SwitchRoot.tsx) and remove the .types.ts files. The types should be defined after the implementation (but before proptypes), as it's usually more convenient to have the implementation visible when you open the file.
Create a namespace with the same name as the exported component/hook and place the types inside it, renaming them appropriately:
This issue has been closed. If you have a similar problem but not exactly the same, please open a new issue.
Now, if you have additional information related to this issue or things that could help future readers, feel free to leave a comment.
The Menu PR tries a different approach to defining types, utilizing namespaces. The type definitions are also placed in the same file that has the implementation.
We agreed to extend this pattern to the whole codebase.
To summarize, the following changes are needed:
TODO
Search keywords:
The text was updated successfully, but these errors were encountered: