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
Hello all,
I am working on building a controlled data table on top of Carbon's React DataTable via react-table, and I will be creating xs inline versions of existing controls such as DatePicker, NumberInput, TextInput, and so forth.
I'd like to make sure my designs fit the vision that the Carbon team has for the library -- with that in mind, I have a few questions with regards to how I should approach making these before I start on a PR:
Is there any desire at IBM to have something like this in the library?
Would it be a good idea to fork the existing components and add an inline: boolean or size: "xs" | undefined prop, or create separate components entirely?
What requirements are there for A11Y and aria labeling?
How should I design the onChange events for inputs? I know that there are plans to refactor them; personally I prefer the approach of returning the native change event.
For reference, here's an example of the table size I am working with size="xs":
(The styling here still needs some work, but I'm aiming for a minimum component size of 150*24 px, with an unbounded x-axis as I am providing resizable columns in my use-case).
In addition, I plan on forking the DatePicker component to fix date format requirements, validation issues, and expose the underlying flatpickr props.
Finally: is there any issue with including Typescript definitions in the props of functional components?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello all,
I am working on building a controlled data table on top of Carbon's React
DataTable
viareact-table
, and I will be creating xs inline versions of existing controls such asDatePicker
,NumberInput
,TextInput
, and so forth.I'd like to make sure my designs fit the vision that the Carbon team has for the library -- with that in mind, I have a few questions with regards to how I should approach making these before I start on a PR:
inline: boolean
orsize: "xs" | undefined
prop, or create separate components entirely?aria
labeling?onChange
events for inputs? I know that there are plans to refactor them; personally I prefer the approach of returning the native change event.For reference, here's an example of the table size I am working with
size="xs"
:(The styling here still needs some work, but I'm aiming for a minimum component size of
150*24 px
, with an unbounded x-axis as I am providing resizable columns in my use-case).In addition, I plan on forking the
DatePicker
component to fix date format requirements, validation issues, and expose the underlying flatpickr props.Finally: is there any issue with including Typescript definitions in the props of functional components?
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions