when searching a tree, only the parent of child results show (only when app is hosted)

[yarinsn]

Describe the bug
when using the search feature, only the parent of the matching node appears (the 'HainesAttract' node has a child called 'Technology', see next screenshot)

However, when the app is running locally on my machine, everything works as expected - I type 'tech' and the relevant child node 'Technology' (and it's children) appear.

To Reproduce
the issue occurs only on a hosted environment.

Expected behavior
see above.

Screenshots
see above.

Environment (please complete the following information):

• Browser: 89.0.4389.82 (Official Build) (64-bit)
• OS: Local: Windows x64, Hosted: Azure Hosted App (Unix 4.15.0.112)
• node version: 12.16

Additional context
using react-dropdown-tree-select version 2.5.1.
It might be that the info I provided is not enough, but I'm not quite sure what to look into at this point, so any questions/requests for further into are welcome.

[mrchief]

Something tells me the issue is with the hosted environment :)

Happy to continue the discussion but I don't think this is a bug with the component.

[yarinsn]

Hey, thanks for the reply. How can we continue the discussion? here or email?

[mrchief]

We can continue here

[Kulgar]

Hello, I am actually having the exact same issue...
What could prevent the component from working properly once deployed?

My app is built using react-script and then deployed to AWS S3, so... nothing fancy here.

[Fabien-Off]

Hello,

First thanks a lot for this great component :-)

I face the same issue here. I host my app on AWS S3 using react.

Do you need more informations in order to debug?

[Kulgar]

Adding a piece of information: it does work when tags are already opened... it keeps tree open and properly shows every already displayed and filtered children

[Kulgar]

I think I found the origin of the bug.

For a (yet) unknown reason, once the code of the lib is built and on my remote env, I can see this piece of code:

(function(e,t,n){if(e.expanded)return!0;var r=e._parent&&n.get(e._parent);return!r||r.expanded})

This is the minified version of the "shouldRenderNode" method:

const shouldRenderNode = (node, searchModeOn, data) => {
  if (searchModeOn || node.expanded) return true

  const parent = node._parent && data.get(node._parent)
  // if it has a parent, then check parent's state.
  // otherwise root nodes are always rendered
  return !parent || parent.expanded
}

As you can see, the minified version is missing the "searchModeOn" in the first "if"... The minified version of the method isn't actually using the "t" argument (which is the "searchModeOn" argument).

Why would this disappear?

I'm using the very last version of that lib (2.5.1).
I cloned it and built it using that version and I do get this in the build:

{(function(e,t,n){if(t||e.expanded)return!0;var r=e._parent&&n.get(e._parent);return!r||r.expanded}

Here, we clearly see the "t" in the "if"...
Can anyone think of any good explanation?

[Kulgar]

I forgot to share a little piece of code:

(function(e,t,n){if(e.expanded)return!0;var r=e._parent&&n.get(e._parent);return!r||r.expanded})(e,0,t)

This is the not working minified version... See? It's calling the "shouldRenderNode" method with a "0" as second value, so, when the code is actually built, it is considering that "shearchModeOn" is always "0" and it automatically removes the if(t...) part.

But when I look at the code built from the lib, I get:

(function(e,t,n){if(t||e.expanded)return!0;var r=e._parent&&n.get(e._parent);return!r||r.expanded})(e,o,t)

Here, the second argument is a simple "o" char... not "0"

It's like the final build is considering "searchModeOn" as always false in the Tree component...

[mrchief]

@Kulgar this is amazing work! I'll look into this, thanks!

[Kulgar]

Thanks @mrchief ^^ indeed, finding the relevant buggy code in the minified version of my big app wasn't an easy task 😄

[mrchief]

Not only that, I wouldn't even imagine to look in such places to begin with. This casts shadows over the whole minification process which is a bigger concern.

[Kulgar]

Well, yeah... I just really wanted to understand what was going on, you know. I was like... how the hell this feature is working in dev and not in prod when they are both using a minified version of the lib. So... I studied the lib to find which methods were involved in that feature (showing tree on search). I quickly understood that my best chance was to look at the "shouldRenderNode" method.

My first guess was: maybe my prod env is using an older version of the lib... somehow. So, that is why I looked at the minified version on my prod env, to find the code related to that method to find any differences with the original method - and that is how I found the bug.

I used the "_parent" key to quickly find the method in my minified files as that key isn't a "commonly" used one. ^^

Sometimes, coding is like investigating a crime scene.

Anyway, you are right, this leverage a really weird behavior over the minification process.