-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request]: Export props for TypeScript components #16154
Comments
Thank you for submitting a feature request. Your proposal is open and will soon be triaged by the Carbon team. |
Thanks for opening this, I think it's worthwhile to consider exporting these. I'm not sure if there's any downsides, but if I'm not mistaken, consumers have always been able to pluck proptypes off the exported components. Makes sense to enable the same through TypeScript. This would be an excellent opportunity for a contribution from the community.
Majority of these cases are due to a sibling component not yet being migrated. Once all exports in the component(s) If you notice any that have all their exports migrated, but it's still |
The Carbon team has accepted this proposal! Our team doesn't have the capacity to work on this now, so we are requesting community contributors. Please see the labels for roles that are needed. If you are willing to help out, comment below and we will get in touch! |
As a work-around, in typescript it's possible to extract the type of a parameter of a function. So type MyExtractedProps = Parameters<typeof MyFunctionalComponent>[0]; allow to use the Props of a functional components even if not exported. |
I was going to suggest the same thing, except with ComponentProps<typeof TableToolbarSearch> It's a bit easier to use since you don't need the Having said that, I have no objection to exporting all the properties explicitly again. That's how it worked in Carbon 10. |
@Sam-Wool What do your type imports usually look like? Could you confirm that you're not able to import // So I believe this won't work:
import { type ModalProps } from "@carbon/react";
// whereas this should work
import { type ModalProps } from "@carbon/react/es/components/Modal"; I don't know that we'll be able to export these from the root until everything is converted and the root |
@tay1orjones Our import for |
Awesome! One more point to clarify, if a component has been converted to .tsx but the index.js for the component is not yet able to be .ts, the exported types/interfaces should still be available at a fully qualified path that bypasses the index.js. Right now MultiSelect is a good example of this: import { type MultiSelectProps } from "@carbon/react/es/components/MultiSelect/MultiSelect"; |
I've opened a new issue to contain this work: |
@tay1orjones with regards to ModalProps, this should be easily raised to the We've been working a lot this past week on moving things over to carbon11, writing ambient modules to help ease the transition and fill in the missing prop exports. The team was wondering what the expectation is for the end goal of the prop exports. Should we ultimately expect to be able to pull types from the main |
The workarounds mentioned by @gillesdandrea and @wkeese may work to get type info for the transpiler but the comments are completely lost, no IDE or tool like Storybook can include that documentation anymore. Also the import approach mentioned by @tay1orjones does not work in any case because there are still components without exported interfaces, e.g. So, let's hope we can get it soon directly from the root |
The problem
In the
@carbon/react
project multiple components which have been converted into TypeScript in Carbon 11 are lacking either exports on their props,. Without access to the props, it is much more difficult to create wrappers for components, pass along props as part of parent components, and assigning types to objects that can help build out components neatly. This has affected my team's efforts to move over from Carbon 10 to 11.For example, in my team's product we leverage the base component's props (aliased here as
CarbonAccordionProps
) to create the typings for a wrapper for theAccordion
component with a simple overwrite. Without these props, we would have to redefine all of the parameters in our codebase by hand, which would open us up to issues down the road if the Carbon component's props change.Included here is a list of all props that are missing exports that my team have found. Note that there may be additional components with this issue that we haven't identified yet.
Tasks
We've also noticed some components are missing an
index.ts
or.d.ts
file - this has caused a similar issue when trying to import props belonging to that component. Below is a list of the components we've found with this issue:Tasks
OverflowMenu
#16444SwitchProps
#16547The solution
To fix this, we need to export the props (see attached for example of an interface lacking an export).
There are also some instances where a prop is missing an
index.ts
or.d.ts
file - in those cases, we should be able to fix this issue by refactoring an existingindex.js
toindex.ts
. See below for an example of a healthyindex.ts
file.Examples
No response
Application/PAL
IBM Storage Fusion
Business priority
Medium Priority = upcoming release but is not pressing
Available extra resources
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: