Unable to resize gutter width on day/time view about react-big-calendar

[jquense]

I'm not sure what you might be doing to get a zero width gutter...The logic is that it checks the max width of the gutters after it's laid out and then uses that width to sync the various gutter cells so they don't end up with different widths.

Is your Calendar starting hidden or something?

[MattWilliamsDev]

We are creating a calendar that has a main content window with three distinct sections. There are 2 containers side-by-side. The left container has a calendar that takes up the top 60% of the container, with the bottom 40% being devoted to the "day/time" view. The "day" view part in the bottom container always ends up with a 0 width until a new date is clicked. Once a new date is clicked, the gutters appear, but only with 10px total width, and I think that is due to the padding: 0 5px;

[MattWilliamsDev]

There is nothing hidden on the page, and the calendars default to the current date.

[MattWilliamsDev]

When the page is first loaded, the left gutter shows, but only due to the padding: 0 5px. The actual width that gets set on the element is 0px:

Once you click a new date, the gutter on the right appears, but it also has a 0 width, getting its width from the padding style as well:

In addition, the gutter never shows below the "all day" row.

[jquense]

I added a check that should prevent 0 width gutters, I am hoping that it resolves your issue let me know.

[MattWilliamsDev]

Will do. Is this available now? If so, I will update immediately. Thank you very much for the prompt responses.

[MattWilliamsDev]

I have been toying with things for a little bit now, and the gutter is better, but it still doesn't seem to be completely working.

When I first open the calendar, the gutter is there, but it is uneven:

After selecting a new date the first time, the gutter adjusts to the perfect size:

However, if you select another date after that, the sizing gets jumbled again, and then stays that way:

[MattWilliamsDev]

What if you could pass gutterWidth as a prop? Would this be possible? At least then, I could override it if necessary or something.

[MattWilliamsDev]

I think it may have something to do with being initiated originally on an unselected (and therefore hidden) tab. Is there a way to account for sizing when initialized that way? For what it's worth, _adjustGutter runs again when the tab is selected and the calendar views shown.

[jquense]

so the view is hidden to begin with? The issue is you can't measure anything if its not visible, which is why this is happening, and to be honest there isn't a ton I can do to make it better I think, aside from just picking a default gutter width, since I can't detect when things become visible to correctly update the value.

perhaps some sort of prop is the best bet, but I find that API annoyingly ugly hmm.

[MattWilliamsDev]

It does get re-rendered again before becoming visible though, so shouldn't it be able to figure out any needed values for calculation consistently?

The view begins on the second of two tabs. Upon selecting the tab, the tab with the Calendars becomes active, and it triggers another run thru _adjustGutter.

[jquense]

Yeah it should if its rerendering, would you mind stepping through _adjustGutter to see why its not getting a width correctly in that instance?

[MattWilliamsDev]

No problem.

Initial Render
width is undefined, due to this._gutterWidth being undefined to that point.
gutterCells contains 3 elements, .rbc-time-gutter & 2 .rbc-gutter-cell.
The if (width) check then prevents the size from being set.
this._gutterWidth gets set to 0, as all of the items come back as 0 width.
When if (this._gutterWidth && width !== this._gutterWidth) runs, this._gutterWidth = 0, width = undefined and the resize is again prevented.

Second (and third) Try (Tab is selected)
This time, both width and this._gutterWidth come out to zero, thus skipping both of the resizes once more.
Interesting note, when I hit my breakpoint, nothing from the calendar appears to have actually rendered yet. Unsure if this is due to Chrome not displaying DOM changes at a breakpoint, but you would think that it would already be showing if it had rendered already.
This, for some reason, gets run twice upon switching to the tab (I assume this is some issue with my implementation). Either way, the result is the same and all of the gutter cells return with 0 widths once again. Despite the 0 width, each gutter cell appears to be sized according to its contents (see the first and third pictures in the above comments).

New Date Selected
Since the individual gutter cells now have individual widths but width is still 0 from this._gutterWidth being 0 in the previous render, the initial resize is skipped.
This time, this._gutterWidth has something to play with and uses the Math.max of [ 69.234375, 10, 48 ].
Since this._gutterWidth now has an actual width set to it, the next line of if (this._gutterWidth && width !== this._gutterWidth) is successful, and the new width is set on each of the gutters. This displays correctly, as in image 2 above.

Select Another Date
If you select another date after that, width has a non-zero value this time, so the initial check to reset the gutter sizes runs and does reset the sizes.
this._gutterWidth again chooses the same max value from the same array of gutterCells, that all still show the same widths as before.
In the check for if (this._gutterWidth && width !== this._gutterWidth), width & this._gutterWidth are equal, so the gutter cell sizes never get re-set back to this._gutterWidth. This is most likely the source of the "Select another date" issue, as they are reset to 0, then never subsequently re-set to the proper value.
This causes the gutter cells to appear as they did originally, with each adhering to the width of its contents, as opposed to nice and even.

Let me know if this doesn't make sense, or if you need more details. I appreciate the work you have done already, and the work you are putting in to assist with this issue.