doofinder / js-doofinder Goto Github PK

Uncaught DOMException: Failed to execute 'querySelectorAll' on 'Element': '[data-facet='type d'utilisation'][data-value]' is not a valid selector.
    at n (https://cdn.doofinder.com/media/js/doofinder-classic.6.latest.min.js:1:7453)
    at Object.r [as ft] (https://cdn.doofinder.com/media/js/doofinder-classic.6.latest.min.js:1:8522)
    at o (https://cdn.doofinder.com/media/js/doofinder-classic.6.latest.min.js:1:5620)
    at HTMLDivElement.a (https://cdn.doofinder.com/media/js/doofinder-classic.6.latest.min.js:1:5783)
    at HTMLDivElement.E (https://cdn.doofinder.com/media/js/doofinder-classic.6.latest.min.js:1:7755)

This works:

document.querySelectorAll('[data-facet="type d\'utilisation"][data-value]');

But this doesn't

document.querySelectorAll("[data-facet='type d\'utilisation'][data-value]");

check peillis/helpapp#3875

So we can do:

unless $(target).closest('.df-slider').length() > 0
  something()

Even if there's no match. Currently .closest() returns null and the chain is broken.

and add tests!

Implement this function in display class.

• Add a cleanValue option to the widget (true by default).
• Add a clean method that cleans the value when called only if cleanValue is true.

Cleaning the value is the natural behavior (not yet implemented) but sometimes you may need to change that behavior so the input is not cleaned.

@abellosovic, @ecoslado asked me to assign this issue to you to be done right now 😃 . Good luck!

https://doofinder.github.io/js-doofinder/

• Ensure docs are for final users, not for collaborators.
• Each class on its own file.
• Child classes refer to their parents for inherited methods, properties and behaviors, but keep docs DRY.

• Accept multiple query inputs.
• Only one can be the currentInput, so layers that position themselves can do based on the current input location.
• Think about how to attach to the actual nodes so no more than one QueryInput can be attached to the same input, forcing other controllers to be registered to a single QueryInput. This can have many caveats, think carefully and play with multiple controllers associated to different query inputs.

This would make easier to setup selectors in layers.

If you use CoffeeScript, you end using its sugar, like:

for own key, value of something

By using that construct in different modules, you end having this repeated 9 times in the current compiled code:

hasProp = {}.hasOwnProperty;

You can infer what happens with other constructs.

I'd like to compare transpiled ES6 with compiled CoffeeScript in some modules to see what happens.

just to let users know it exists for the weird case they see it :-)

Hello,
Can I use queryInput with class for multi element instead of Id?

"queryInput": ".search"

Thanks.

https://github.com/doofinder/js-doofinder/blob/master/src/widgets/facets/rangefacet.coffee#L96-L99

Use case:

1. Type a query
2. Facets are rendered
3. Use the slider, filters are added to the controller.
4. Revert handlers to the original position, values should be the same as when the widget was initially rendered.

But the filters remain in the controller when you're actually not filtering by price because those are the original values.

Why this issue? You can use this in the template to know if any filter is applied:

{{#filter}}FILTERED{{/filter}}

But with the current behavior that's not true after using and resetting the range slider.

So search is triggered in any matching element now or in the future.

If a response arrives late (a more recent one has been rendered) it gets rendered and it shouldn't.

for triggering "df:next_page" :

  nextPage: (replace = false) ->
    if @status.firstQueryTriggered and @status.currentPage > 0 and not @status.lastPageReached
      @trigger "df:next_page"   
      @status.currentPage++
      @__search(true)

that is, after it checks that in can actually do the search, it triggers the event

for "df:get_page" :

  getPage: (page) ->
    @trigger "df:get_page"
    if @status.firstQueryTriggered and @status.currentPage > 0
      @status.currentPage = page
      self = this
      @__search()

before doing the pertinent checks, the event is triggered.

which way do you prefer? Personally, I prefer to trigger the event after the checkings, but whichever is it, it should be the same for both.

Try to fix:

• Tooltips disappear when they reach the opposite side of the slider.
• Use as few CSS as possible.
• Pips are rendered in the RangeFacet widget due to a weird behavior in the current version of noUiSlider so try to get rid of that if possible and use native pips in noUiSlider 11.

Regarding the tooltips disappearing, it happens when using the slider inside a container with scroll:

overflow-x: hidden;
overflow-y: auto;

The same for the rest of methods. If I want to use the first I will call first() explicitly.

• Refactor QueryInputWidget to trigger special key events (like ENTER).

like for results widgets, write some tests for the suggestion list widget, using mocha and jsdom

as far as I know, coffeescript allows the use of things like my_function: (param1, args...)
In client.coffee variable arguments in functions are treated very crappy.
Maybe there are other places to make use of this, I didn't check it all.

@carlosescri
this is code from the queryInput widget

  setElement: (element) ->
    @element = ($ element).filter [
      'input:not([type])',
      'input[type="text"]',
      'input[type="search"]',
      'textarea'
    ].join ","

https://idoctor.es/# has a searchbox like

<input type="" name="" value="Ej: Consulta Traumatología Madrid" size="35px" style="size: 500px; float: left; height: 50px; border-radius: 5px; font-size: 18px;" onclick="if(this.value=='Ej: Consulta Traumatología Madrid') this.value=''" onblur="if(this.value=='') this.value=''">

with has an empty value as its type attribute.

Classic layer doesn't work because queryinput filters out that kind of input.

Do we want this? if so, Is it on the doc??

So the controller knows widgets but widgets only are responsible of rendering themselves and triggering events as response to user interactions.

• This doesn't work: @resultsWidget.element.find('[data-role="placeholder"]').remove(). Refactor dfdom!!! (Related: #64, 65)
• Add hasAttr to dfdom.

Maybe the solution would be:

• Those users who have mobile addon and want to use the current mobile version, just fill in the mobile version option.
• Those users who have mobile addon and want to use normal layer, do nothing.
• Those users who don't have mobile addon, they won't be able to watch layer nor current mobile version.

This would be a good option, but Android keyboard hides almost the whole layer, so we must decide what to do. Some customers ask for using the layer, because of the customizable and because you don't have to navigate to other page.

This customer have written asking for this:
[email protected]

some third party libraries are nasty enough to add extraneous attributes to arrays.
[].each(function){})

when using qs.stringify , those attribs appear in stringified version

the thing is disallow any "function like" attrib. at all

according to the doc
https://github.com/doofinder/js-doofinder/#addparam
"Adds new search parameter to the current status."

by looking at the code, addParam adds keys to the internal @status.params dictionary

But every time controller.search() is called, @status.params dict is reseted
https://github.com/doofinder/js-doofinder/blob/master/src/controller.coffee#L104

so any prior modification made to @status.params is overriden.

looks like the method is superfluous, unless it's intended for other thing

@ecoslado, please wight in.

Decide if the widget should be empty.

This function must be calling from the handleInput and resumeLayerState function

• There's a polyfill for it (even as a service).
• Callbacks are async.
• There's a good article about it.

When using the library directly from the browser, document.body could be null when the library is parsed. So make the check only once but when it's used the first time.

https://doofinder.freshdesk.com/helpdesk/tickets/6706

Hi,

if I use „closeOnClick“: true doofinder is mixing up the browser history:

1. User navigates to site
2. user is browsing (is important)
3. opens product (wich has reviews)
4. User clicks on „Bewertungen“ => below the stars upper right corner (internal named-link with #)
5. Site refreshes(!) not navigates <= bug
6. If user then clicks back (in the browser)
7. User is on main page!!!!!

It is not live in my system but you can simply reproduce.

www.marienfiguren.de

• Write a method .one for util.dfdom (bean based)
• Write a method .one for Widget (that invokes dfdom.one)
• Write a method .one for Controller (that invokes dfdom.one)

I'm also thinking about creating a mixin which manage the events thing. Widget and Controller would inherit from it the bind, unbind, one and trigger methods. I don't know how to implement multiple inheritance in coffee and it's just a suggestion

@JoeZ99 this is for layers test, maybe you could implement the easy part and we could debate after about the mixin.

• We may not need Client.__escapeChars() and use window.encodeURIComponent() instead but the way methods are called must change to avoid double escaping.
• Try to have only one method to send stats instead of N in the Client and N in the Session. Better N in the Session (if necessary) and 1 in the Client (if possible).
• Remove support for Doofinder Search API v4 from Client

mootools changes Function.prototype.bind and range-ion-slider uses that native function extensively.

mootoos 1.6.0 works fine (is the last version)

Should we warn this in the readme???

https://polymer.github.io/lit-html/

Google says it's faster than virtual dom and it actually uses ES6 tagged literal templates. But IE (and probably other old browsers) doesn't support them, so we have to analyze if we want to use it.

The thing is: increase performance but allow users to use something that looks like HTML (currently that's Mustache). Virtual DOM uses plain JS to express HTML and end users won't know what to do with that (thinking on stuff derived from the use of this library). lit-html allows to directly interpolate JS.

Well, evaluate.

So when a term looks like mouse+keyboard the search query should be like ...&filter[...]=mouse%2Bkeyboard&...

That's the default results limit in Doofinder. It should be configurable for the case we allow more than 1000 results for a customer.

So we can remove jsdom and jsdom-global and use just Karma for browser-related tests.

You can know if you're rendering the first page of a search by inspecting the response's page attribute. render and renderNext methods are very similar inside DisplayWidget.