Very inconvenient to search for certain values like '100Ohm 0402 resistor'

[t123yh]

When you search for '100 0402' or '100 0402 resistor', thousands of results appearing in the result box.

However, you can get the desired result if you search with '100Ω'.

Considering the fact that most people don't have the Ω symbol on their keyboard, I think it would be nice to have some form of auto-conversion in the search box, like converting ohm to Ω.

[arturo182]

It seems LCSC is smart enough that if you use "100R" it shows 100Ω parts:

[Bouni]

Maybe we can create some kind of smart filter here.

Like writing 100 pkg:0402 will search for 0402 in the packages, mfr:xxx could be the same for manufacturers.

What do you think of this approach?

[t123yh]

Maybe we can create some kind of smart filter here.

Like writing 100 pkg:0402 will search for 0402 in the packages, mfr:xxx could be the same for manufacturers.

What do you think of this approach?

Yes, I think it will be nice. Also, I think search box content can possibly be automatically filled from the component value.

[Bouni]

Thats a nice idea, I like that!

[yaqwsx]

If you want, you can use preprocessed libraries from my project: JlcParts (https://github.com/yaqwsx/jlcparts).

All basic values like resistance, capacitance, inductance, voltage, current, etc. are normalized to SI units which allows you to, e.g., sort properly by values. The libraries are JSON files per category and are served via GH-Pages.

[Bouni]

@yaqwsx Thank you for this kind offer, I have to look into it if and how I could use your librarys.
I planned to set up a web api that makes me able to query the JLC parts in a nice way for quite a long time.
That also makes us able to query the data even when the JLC csv file is 404 again as it happened a few time the last couple of days!
I've seen that you have trouble with firefox and your plugin, this API might solve your browser issue as well!?
What do you think of a joint effort to setup such an API and use it in both projects?
I would pay for the infrastructure, I guess a small virtual server (CX21) is sufficiant for such a service.
Let me know what you think 😃

[yaqwsx]

My goal with JlcParts was to avoid a need for a custom infrastructure. That's why the current solution is quite hacky and abuses IndexedDB at the user side. If you manage to run an alternative service, I will be happy to use it! However, I cannot offer you any implementation help from my side at the moment as I have much more urgent maintenance work regarding my other projects.

[Bouni]

Ok, absolutely no preasure from my side here 😄
As soon as I find some spare time I'll try to get such a service up and running. I'll try to utilize your work to normalize the data then and let you know about my progress. Don't expect that to happen quickly 😅

[battlesnake]

I have the Greek alphabet mapped on my keyboard so I can type stuff like Ω or μ with 4 keystrokes each.

But perhaps having a simple string-replace of \R or \W to "Ω" in searches translated would be a simple way to make Ω searches easier. Likewise \u or \m for "μ". Using backslash seemed reasonable since I've never seen it in a part's description, and it could be easily escaped if needed as \\.

JLC's own search doesn't have a way to respect word boundaries (e.g. 1kΩ will match 5.1kΩ). Quotes could be useful there, e.g. "1kΩ" would only match space-delimited word 1kΩ.

[Bouni]

That sound like a good idea to me!
It will take some time to get all this up and running ....

[Bouni]

@t123yh What do you think of the new search UI, is that sufficiant or do you still think the search needs improvement as discussed above?

[t123yh]

@t123yh What do you think of the new search UI, is that sufficiant or do you still think the search needs improvement as discussed above?

Hi, @Bouni

Thanks for your great work!

The new version feels much better and smoother to use. However, there're two things I think can be improved:

1. Can you add code to remember the include basic part and extended part setting in library selector so we don't have to tick the checkbox every time we select a part?
2. I think it's possible to automatically fill Package field on common package names like 0402 or 0603 based on footprint name; likewise, component value can be put into Keyword.

[Bouni]

1. Can you add code to remember the include basic part and extended part setting in library selector so we don't have to tick the checkbox every time we select a part?

Yes, thats easy to solve, would you please open a seperate issue for that. It helps me keep track of feature requests and problems.

2. I think it's possible to automatically fill Package field on common package names like 0402 or 0603 based on footprint name; likewise, component value can be put into Keyword.

This is not that easy, because there are all sorts of names for a package on both sides, KiCAD and JLC, for example 0603 shows up in the JLC DB as 0603, C0603, 0603_x4, R0603, LED-0603 ....
and in KiCAD as R_0603_1608Metric, Crystal_SMD_0603_2Pin_6.0x3.5, D_0603_1608Metric, L_0603_1608Metric ....
So theres no easy way to get the "useful" part for filtering.

[t123yh]

This is not that easy, because there are all sorts of names for a package on both sides, KiCAD and JLC, for example 0603 shows up in the JLC DB as 0603, C0603, 0603_x4, R0603, LED-0603 .... and in KiCAD as R_0603_1608Metric, Crystal_SMD_0603_2Pin_6.0x3.5, D_0603_1608Metric, L_0603_1608Metric .... So theres no easy way to get the "useful" part for filtering.

I think we can embed some common package names like 0402, 0603, 0805. We match them in footprint names, and if matched, we fill it to the package field. The package field will then do partial matching within JLCPCB library to filter out what we want.

[Bouni]

I have to look into that, as there are a lot of common packages this list can get quite long and intensive to generate/keep up to date ...

[t123yh]

I have to look into that, as there are a lot of common packages this list can get quite long and intensive to generate/keep up to date ...

We can probably build some sort of matching table, based on what the user selected. For example, if we selected a "0402" part for "R_0402" footprint, then the tool can remember this preference, and fill in "0402" for all later "R_0402" parts.

[Martinnnnnnnnnnn]

Considering the fact that most people don't have the Ω symbol on their keyboard, I think it would be nice to have some form of auto-conversion in the search box, like converting ohm to Ω.

I'd like to vote for a small "omega" button. This would clutter the GUI some, but would avoid having to know/remember cryptic replacements like "\R" or "ohm".

[Bouni]

I thought about something like that before but I'm not sure how I can know which textfield to put the Ohm into.
If the button is clicked, I think there is no way of getting the last focused element other than keeping track of it in a variable or something like that ...

[Martinnnnnnnnnnn]

I think the Ohm would make sense in the keyword field only, so you could put it to the right of the keyword field and append to this field only.
Also, a dropdown list for the category would be nice (btw it's "resistors", not "resistor").

[Bouni]

Finally fixed by #508