-
Notifications
You must be signed in to change notification settings - Fork 20
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
Drive search from query string #82
Comments
you can probably do var qs = require('querystring') // (component/querystring)
// . . .
var q = qs.parse(location.search).q || '';
search.show(q); instead of |
Is Component abandoned? |
I use both component v0.19 and duo pretty regularly... |
@dandv: My understanding per componentjs/component#594, componentjs/component#601, and componentjs/component#604 is that Component is now in maintenance-only mode. Is that the correct interpretation, "maintainers" @timaschew, @netpoetica, @trevorgerhardt, @clintwood, and @jasonkuhrt? |
@stephenmathieson: Your earlier code snippet looked valid to me upon further review. I'll try to submit a PR for it later tonight. |
Component isn't dead nor in maintenance-only. Just because the original authors went bonkers this project isn't abandoned. @timaschew works on component avidly and even then, we're using it for the very fundamental build processes in our company. (disclaimer: @timaschew works there as well) |
I plan to continue both maintenance and features for component until latest browsers will support module loading and web components natively. A main feature of component is that it supports local modules/dependencies, which doesn't exist for other tools like browserify or duo. This is a reason for me to use copmonent (not only at our company) and continue development on component. I have some ideas for the next release to support |
For what its worth, maybe a second wind for component would be supporting the Concord spec. I'm putting this same question out there with duo: |
Alright, so working on the PR for this per @stephenmathieson's tip did work. However, it brings up a UI quirk that needs a design decision:
So, design-wise... maybe one of those two end results is acceptable (at least for a quick win on getting this search functionality in)? If not, then we should consider [at least] the following:
Local screenshots: |
Maybe the latter (showing the search term without a prefix label) is actually OK because the cursor is still there blinking. Thoughts? |
i'd go with the second option |
Yeah, it actually looks pretty good the more I look at it. Not sure if I did the "right" thing for it but I'll submit the PR shortly and you all can judge me there. 😉 |
PR available for review: #83 |
Thank you everyone for the guidance, correction of misinformation [on the livelihood of Component], and merging my PR. 💝 |
I know that Component is basically abandoned now but it would be really nice if someone who knows the system (and the correct "component way" to do this) could take probably ~30 minutes or less to add this....
It would be nice if the search could be driven from the query string, i.e. navigating to
http://component.github.io/?q=dialog
would trigger an automatic search fordialog
when the page is finished loading.The text was updated successfully, but these errors were encountered: