-
Notifications
You must be signed in to change notification settings - Fork 4k
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
feat(Dropdown): component shorthand in options prop #1757
feat(Dropdown): component shorthand in options prop #1757
Conversation
|
Hm, this looks like it will have direct conflicts also with #1038. That PR is getting stale, though, I recall changing the options to shorthand introduces a cascade of side effects that have to be dealt with. This ends up affecting all rendering, filtering, and callbacks. Let me circle back over there and see where this lands us. Also, if you have time, go ahead and take a look at it yourself and get up to speed on where it was left off. |
|
Codecov Report
@@ Coverage Diff @@
## master #1757 +/- ##
=========================================
Coverage ? 99.75%
=========================================
Files ? 145
Lines ? 2488
Branches ? 0
=========================================
Hits ? 2482
Misses ? 6
Partials ? 0
Continue to review full report at Codecov.
|
Sorry for my absence, i'm back and eager to continue my work
Perfectly sane, I forgot about renders and stuff
In that case it will be
I think it can be error-prone, cause linters won't complain in case of typo, but not with |
I've updated the code to |
I've marked this PR for review and will take a look as soon as I can. Would really love to get this one merged. Thanks for persisting! |
Is merge Complete? |
Hi, guys. Are we agreed on the api? I can start implementing tests and updating documentation if we are and refactor code later. |
@layershifter IMHO, the In general, I prefer code over configuration as it is more flexible. Consider this: { component: MyHOC(Dropdown.Divider) } This cannot be done with a string based configuration. |
<Dropdown.Item description='5 new' text='Discussion' /> | ||
</Dropdown.Menu> | ||
</Dropdown> | ||
<Dropdown text='Filter Tags' floating labeled button icon='filter' className='icon' options={options} /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think instead of overloading the options
here, we use a new items
prop. There is quite a bit of logic based on the options for keyboard nav and selected/active/disabled states. Options is also meant to reflect the idea of select
options.
My thinking with items
is that is reflects any valid Menu
item, including headers and dividers. This will also play well with <Menu items={} />
and <Dropdown.Menu items={} />
.
Thoughts?
@@ -1147,6 +1155,15 @@ export default class Dropdown extends Component { | |||
}) | |||
} | |||
|
|||
renderComponent = (component, props) => { | |||
switch (component) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than a method for this, we should just invoke React.createElement()
via JSX syntax. This will allow the user to pass any class or functional component. They may pass an entirely different component than Dropdown.Divider
, or one of these wrapped in a HOC which would fail the switch cases.
-this.renderComponent(component, { ...componentProps, key: i })
+<component {...componentProps} key={i} />
I think the renderComponent
method then goes away completely.
@@ -768,6 +773,9 @@ export default class Dropdown extends Component { | |||
|
|||
// filter by search query | |||
if (search && searchQuery) { | |||
// filter any component elements like Header or Divider | |||
filteredOptions = _.filter(filteredOptions, opt => !opt.component) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, this is pretty simple. Perhaps we should just keep options
as the prop for this case. For some reason, I hadn't thought of this simple fix. I believe this will work in all cases.
} | ||
|
||
const DropdownExampleHeader = () => | ||
<Dropdown text='Filter' icon='filter' floating labeled button className='icon' menu={menu} /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this API the most. This is the most consistent with where we are headed with shorthand and subcomponent alignment.
I'm a little torn on this myself, however, I think we need to abandon the The Dropdown, however, has a Final API propsal: <Select options={} /> // as it is today, no change
<Dropdown menu={} /> // Takes Dropdown.Menu shorthand It makes sense for a DropdownMenu.js DropdownMenu.create = createShorthandFactory(DropdownMenu, items => ({ items }) Dropdown.js // When rendering the menu
DropdownMenu.create(this.props.menu) This means arrays will be passed to the // Array of DropdownItem primitive values
<Dropdown menu={['First', 1, 2, 3, 'Last]} />
// Array of DropdownItem props objects
<Dropdown menu={[{ text: 'One', value: 1 }]} />
// Array of elements
<Dropdown menu={[<Dropdown.Item />, <OtherItem />]} /> Whilst props objects and elements can still be used. // DropdownMenu props
<Dropdown menu={{ items: [ ... ], visible: true }} />
// An element
<Dropdown menu={<Dropdown.Menu />} />
<Dropdown menu={<AnotherMenu />} /> Note, the |
up |
+1 |
@levithomason |
Yes, sir. Right now, the Dropdown is assuming all the functionality of the Menu as it creates and manages both. |
I started refactoring it and stumbled into a problem, for example: we have method I can see a solution, but it seems very hacky: we can get selected item by subscribing by some callback, like |
This sounds like the idiomatic React approach. Let's go with this for now. |
@levithomason as you can understand, I can't proceed with this, unfortunately (I left the project in which this feature was needed and I don't have enough willpower). Despite it's obvious, I'm still really sorry for it, guys. Let's close this PR. |
Understood, it happens :) |
fixes #1724
WIP
This pull request introduces a possibilty to set
component
shorthand inoptions
Dropdown shorthand. Use cases isHeader
andDivider
use while getting benefits of full state management.Example
Please note that that API is a subject to change (Discussion is in #1724 ), but I took the risk to start implementing it.