Skip to content
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

[New Component] Search Field #1985

Closed
wants to merge 3 commits into from
Closed

Conversation

yongxu
Copy link
Contributor

@yongxu yongxu commented Oct 25, 2015

This is an update from #1446.
Review needed.

Sorry don't have time to do the document now. Maybe someone else could help on that.

f56082d0-c6aa-4477-ae37-02dfe5e78582

@oliviertassinari @shaurya947

@@ -0,0 +1,54 @@
let React = require('react');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

const

@shaurya947
Copy link
Contributor

I agree with @oliviertassinari that this field could use a more general name like TypeAhead.

Other than that, olivier has given some good code feedback that I would encourage you to look at. And we're being careful to merge new features with documentation, so @yongxu could you please look into that when you get a chance? :-)

Great stuff, thanks @yongxu

@oliviertassinari oliviertassinari added the PR: needs revision The pull request can't be merged. More details is available on the code review or fails in the CI label Oct 26, 2015
@yongxu
Copy link
Contributor Author

yongxu commented Oct 27, 2015

Thanks @oliviertassinari , Great review.
Indeed this component is not perfect. I think there are quite a few things I could do better.
I am quite busy this week, but I will try to work this out in 2-3 days.
@shaurya947 , I was intended to create something that can be used as a search bar, TypeAhead does describe the behavior of this component, however it doesn't quite tell what this component should be used for.
I am open to new names, maybe we could come with a better name, like suggestion field?

@newoga
Copy link
Contributor

newoga commented Oct 28, 2015

What about AutoComplete?

When in doubt, we can stick to the terms used in the actual Material docs:
https://www.google.com/design/spec/components/text-fields.html#text-fields-auto-complete-text-field

@oliviertassinari
Copy link
Member

Looks like the material spec define two differents names, a SearchFilter and a AutoComplete. They both look similar. So yes, I would go for AutoComplete 👍 .

@yongxu
Copy link
Contributor Author

yongxu commented Oct 28, 2015

@newoga AutoComplete I like this name. The link is also very useful.

The next step is to make it work like this, I am going to work on it.
image

@shaurya947
Copy link
Contributor

👍 AutoComplete for the win, then!

Looking forward to it @yongxu

@vijayrawatsan
Copy link

Really need this to merge.
AutoComplete it.
👍 @yongxu

@vijayrawatsan
Copy link

@oliviertassinari @yongxu Is there an example for testing out this component. Or can you point me in the right direction?

@yongxu
Copy link
Contributor Author

yongxu commented Oct 31, 2015

@vijayrawatsan I am working on it! Should be able to work it out in the next 24 hours.

@yongxu yongxu force-pushed the new-search-field branch 2 times, most recently from a5d0926 to c15ecfa Compare October 31, 2015 23:40
@yongxu
Copy link
Contributor Author

yongxu commented Oct 31, 2015

I have made a few updates on the component, also changed its name to AutoComplete.

It should be ok to use in development, though there are few features I have in mind that I haven't had time to implement yet.

I will be really busy before Wednesday, sorry about that. I think this version should be good enough to merge. I will keep working on it after Wednesday. Feel free to make it better if you like!

@vijayrawatsan @oliviertassinari @shaurya947

Happy Halloween BTW :)

@yongxu
Copy link
Contributor Author

yongxu commented Oct 31, 2015

I did not squash these 2 commits so that you can see what has been changed, I think it is probably reasonable to kept it this way so that we can trace back if needed. If you think the rebase is needed I will be happy to do that too.

@s0meone
Copy link

s0meone commented Nov 2, 2015

Thanks for this great component. We found one issue: when using the AutoComplete with a floatingLabelText the results menu is not correctly aligned with the input field.

screen shot 2015-11-02 at 14 20 52

screen shot 2015-11-02 at 14 19 22

@shaurya947
Copy link
Contributor

Changes look good to me @yongxu. If you can address the issue pointed out by @s0meone before we merge, that would be great!

Other than that, I'll let @oliviertassinari review this too (and merge) :-)

@vijayrawatsan
Copy link

@yongxu Too god mate.
onUpdateRequests implies data to show
onNewRequest ? what does this mean. Does this mean onSuggestionSelected?

@vijayrawatsan
Copy link

By the way @yongxu this one has a very good api
https://github.com/moroshko/react-autosuggest

@oliviertassinari
Copy link
Member

By the way @yongxu this one has a very good api

I don't agree, see moroshko/react-autosuggest#71

@vijayrawatsan
Copy link

I really liked it just because of one missing feature you can't just say its bad.
It works smoothly and has most of the required callbacks. And mostly its always good to have a reference.
Anyways material ui is awesome and you guys rock. 👍

@oliviertassinari
Copy link
Member

@vijayrawatsan I not saying that their API is bad. What I mean by I don't agree is regarding the implicit meaning: I don't think that we should fully follow their API based on what the author is saying.

I'm rebuilding react-autosuggest at the moment to support
flux architectures including redux. Check out this redux example.
You are more than welcome to contribute to the design of the new API.

However, they do have IMO good properties like showWhen
On behalf of the team, Thanks.

@vijayrawatsan
Copy link

@oliviertassinari
Sorry for misunderstanding.
Peace.
And you guys are really doing a good work. 👍

@vijayrawatsan
Copy link

@yongxu @oliviertassinari
Can we auto wrap content in drop down menu?
Basically I have a very long text in dropdown. Currently it auto trims which is great but what if I want to show the complete text.
Possible options:

  • Allow to specify width of dropdown item.
  • Allow to wrap.
  • Allow to specify max cahracters after which it trims

}}>
<div
style={{
widht:'100%',
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Misspelled width.

@oliviertassinari
Copy link
Member

@yongxu What do you think about their API http://react-toolbox.com/#/components/autocomplete dataSource (as react-native ListView) and onChange? I think this is great 👍.

@yongxu
Copy link
Contributor Author

yongxu commented Nov 7, 2015

@s0meone That has been fixed
@oliviertassinari @vijayrawatsan, I added dataSource, which accepts array as auto complete result.
currently, if dataSource is defined, the return value of onUpdateRequests will be ignored.

@dlindahl Thank you for the review. problems have been fixed!

@oliviertassinari @shaurya947 I think it should be good enough to merge now!


getDefaultProps() {
return {
fullWidth: false,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we have a dataSource: [], as a default value?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If dataSource is null, then it will call onUpdateRequests. This was left uninitialized on purpose.

@yongxu
Copy link
Contributor Author

yongxu commented Nov 10, 2015

@oliviertassinari @shaurya947 I think this component should be ready to merge, what do you guys think?

@vijayrawatsan
Copy link

@yongxu thanks for the reply:
"@vijayrawatsan I was thinking about to add overflow:hidden, it can be pass as style. Make it default seems to be preferable for most cases, I will make it default in the next update."

But that will hide the extra text. What if that text is very important. And I want to wrap it instead of not showing it. Is there any hack for it. (I am not asking you to support this feature, just asking for some hack.)

@yongxu
Copy link
Contributor Author

yongxu commented Nov 13, 2015

@oliviertassinari dataSource is good for static data, but it is probably not the best way to update every time user type down a new character. I think there should be an event for every time user made one character change, and one for the user request(enter, or click on the list).
What if we change the name to

dataSource // for list proprity

/* function(searchText,prevDataSource) -> if return a list, 
   then replace dataSource with that list, 
   otherwise use the dataSource from props */
onUpdateInput 

//and
onNewRequest(searchText,index,dataSource) //if no match then index = null

Or use the nameonChange instead of onUpdateInput, Personally I think onUpdateInput is better.

@vijayrawatsan I will add that in the next pull request!

Sorry I have been too overloaded lately. I am going to make another update as soon as you guys agree on the name. So I will do it tonight or this weekend and make a nice finish. I am not sure how much time I will be able to help before Dec, but I will do my best. I know this component may not be perfect yet, but I think we should merge it so others can use it in their project or improve it when I am not available.

@oliviertassinari
Copy link
Member

onUpdateInput

Sounds good to me.

and one for the user request(enter, or click on the list)

IMHO it's not needed for the autocomplete, but why not.

Can we make those two callbacks, not expecting any returned value?
I really think that it's better to have only one point of data for the component dataSource.

I know this component may not be perfect yet, but I think we should merge it so others can use it in their project or improve it when I am not available.

We will merge as soon as the API is stable 👍. Thank for the time you spent on this!

@vijayrawatsan
Copy link

@yongxu I fixed the wrapping by adding

innerDivStyle: { overflow: 'hidden' , whiteSpace: 'normal'}

Also there is one bug I would like to report.
Lets say you type in 'h' - > 4 results
After that you type 'e' -> 1 result

No you press backspace to remove letter 'e'. Now the dropdown should show 4 results but it only show 1 result, rest is empty space in dropdown.

This is fixed when I turn animated: false while creating menu.

@yongxu
Copy link
Contributor Author

yongxu commented Nov 14, 2015

@vijayrawatsan I suspect the bug is from src/menus/menu.jsx

However I realized I should make animated a property instead of animated={true}

I will make auto-complete stable today and ready to merge today, then we can fix the animated issue in another issue report.

@yongxu
Copy link
Contributor Author

yongxu commented Nov 16, 2015

created new PR because of the component name change.
Please see
[new component] auto-complete #2187

@nslobodchuk
Copy link

How do I limit the number of results displayed in the menu? For example, I have 4000 options and I want to display only 10 in the menu.

This was referenced Dec 2, 2015
@yongxu yongxu deleted the new-search-field branch January 8, 2016 09:11
mnajdova pushed a commit to mnajdova/material-ui that referenced this pull request Nov 10, 2020
Bumps [cypress](https://github.com/cypress-io/cypress) from 4.8.0 to 4.10.0.
- [Release notes](https://github.com/cypress-io/cypress/releases)
- [Commits](cypress-io/cypress@v4.8.0...v4.10.0)

Signed-off-by: dependabot-preview[bot] <[email protected]>

Co-authored-by: dependabot-preview[bot] <27856297+dependabot-preview[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
PR: needs revision The pull request can't be merged. More details is available on the code review or fails in the CI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants