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

Labels in control are hidden when Select used within an expander (collapsed) with a defaultValue. #3406

Closed
alturium opened this issue Feb 4, 2019 · 6 comments
Labels
issue/bug-unconfirmed Issues that describe a bug that hasn't been confirmed by a maintainer yet issue/reviewed Issue has recently been reviewed (mid-2020)

Comments

@alturium
Copy link

alturium commented Feb 4, 2019

Description

  1. If Select component is wrapped in an expander (or collapse-like component), and a default value is set, and the expander is closed upon initial creation, then the value is not shown in the control because of the WrappedComponent has inserted a <div> with a width of 0 (width: 0px).
  2. After toggling expander to open (see below), the value is in the control but is not shown because the CSS property ‘width’ is 0px.
  3. It not possible to recover from this state by attempting to reselect items, or by clearing items in control.

Expected Behavior
There should a label in the control, but instead it is effectively hidden by a width: 0px from a wrapping <div>.

There is a similar issue: ‘Default selected items don't appear when using transitions if select is hidden #3029’. The discussion in #3029 seems to indicate that the issue has to do with the Collapse component, which stores a ‘width’ in its state (initially set to ‘auto’), but appears it does not get re-computed.

Sandbox
https://codesandbox.io/s/jz4112nvyw

Screenshot
image

@gwyneplaine
Copy link
Collaborator

@alturium thanks for this issue.
Is there any reason why you're leveraging display: "none" to hide/show children?
Generally speaking something like the pattern in the sandbox below is preferable in react
https://codesandbox.io/s/188ly2543

The reason this is happening is because Collapse uses the width of the DOM node to manage transition animations. since the is using display:none to hide its children, when measurement happens the width of the element is 0. At the moment I can't think of a simple fix for this within Collapse that wouldn't also compromise its existing functionality.

Happy to discuss this further If you do feel strongly about the pattern in your sandbox. Even better, if you have an idea of how to go about resolving the issue, a PR is always greatly appreciated :D

@alturium
Copy link
Author

alturium commented Feb 6, 2019

The example used Expander but in actuality I was using Collapse from the reactstrap library (not to be confused with the Collapse component in react-select, and discussed below) . So I don't have control over the component. But I was able to modify the Expander to accomplish the same purpose and it works! Thanks @gwyneplaine

Luckily, I was able to substitute my version of Collapse and that probably meets 99% use cases. However, there may be situations where Select is buried in a hierarchy of react components and one cannot substitute the container or parent. So this issue still remains.

In thinking about it, I can see that the react's DOM is created, and the width computed at that point in time as 0 (zero). Changing props or states themselves do not cause the re-calculation of width in Collapse (Select version), so there seems to be no way to cause the re-calculation of 'width'. This might be due to Collapse storing 'width' as a state variable and to the way or manner that React works in creating its DOM.

So essentially we are working around a React limitation, using the most essential line below, to force a re-evaluation of the react DOM tree:
{expanded && ( <div style={contentStyle}>{this.props.children}</div> )}

It may still be possible to re-write the react-select Collapse component to not store width as a state variable. This kinda has code smell since there is no provision of updating it and widths do change and assuming that width doesn't change may not be correct.

Does this sound correct?

@geochanto
Copy link

geochanto commented Dec 8, 2019

Running into the same issue. Tried the top answer here, didn't work: facebook/react#4101

I'm trying to use value instead of defaultValue, but that doesn't seem to be working either.

If I start with the open state for , defaultValue populates. But if it starts collapsed, defaultValue doesn't populate when the state is toggled on, even though I can see the defaultValue prop is passed down to react-select.

UPDATE:
Seems I found the culprit for my case. the defaultValue was actually there, but it was hidden by label having zero width via inline CSS. It seems that this was caused by using the makeAnimated component. After removing it, CSS width is back to normal and default label shows up.

@bladey bladey added the issue/bug-unconfirmed Issues that describe a bug that hasn't been confirmed by a maintainer yet label Jun 1, 2020
@muserrefakillibaykus
Copy link

Is this bug fixed? @bladey @alturium

@bladey bladey added the issue/reviewed Issue has recently been reviewed (mid-2020) label Jun 17, 2020
@arejaycola
Copy link

Thank you @geochanto! This saved me a lot of time. I guess I will just go without animation until this issue is resolved.

@ebonow
Copy link
Collaborator

ebonow commented Dec 20, 2020

@alturium @muserrefakillibaykus

I have not been able to reproduce this even in the sandbox link provided. I am uncertain what if anything has changed, but if someone can replicate this issue please provide some more information so we can reproduce the described error, reopen this issue and further troubleshoot.

In the meanwhile given that I am unable to replicate it, I will close it for time being.
Screen Shot 2020-12-19 at 9 38 23 PM

@ebonow ebonow closed this as completed Dec 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
issue/bug-unconfirmed Issues that describe a bug that hasn't been confirmed by a maintainer yet issue/reviewed Issue has recently been reviewed (mid-2020)
Projects
None yet
Development

No branches or pull requests

7 participants