DataTable: scroll forced to top when inside "flex-column" container with virtual scrolling enabled about primereact HOT 8 CLOSED

There are no requirements. With that second div, without flex you just broke the width/height calculation within the Virtual Scroller. Mixing never is a good thing i guess.

from primereact.

@sja-cslab thank you! Will close this as "workaround provided" as you are right this is more to do with the structure of this HTML.

from primereact.

Your second div.flex-1 is redundant and causes this.
Remove that and your Scroll will work.

If you really want that second div you've to keep flex behavior down the tree like

<div className="h-full flex">
      <div className="flex flex-auto">
        <DataTable
        className="flex-auto"
          value={DATA}
          dataKey="id"
          scrollable
          size="small"
          scrollHeight="flex"
          virtualScrollerOptions={VIRTUAL_SCROLLER_OPTIONS}
        >
          <Column field="id" header="ID" />
        </DataTable>
      </div>
</div>

from primereact.

If there are requirements for the HTML surrounding DataTable, could they be documented?

from primereact.

@inad9300 what he is saying is your HTML + CSS broke the table styling. So like anything else in HTML/CSS you would have to respect the structure of the DOM of the generated component.

from primereact.

If "without flex [I] just broke the width/height calculation within the Virtual Scroller", it follows that there is a requirement to "use HTML and CSS that does not break the width/height calculation within the Virtual Scroller", and it would be good to know what the Virtual Scroller requires.

The reproducer I provided differs from my original code, which I iteratively simplified until I couldn't reproduce the problem anymore. In order to apply the solution to my real case, I would like to have a somewhat solid understanding of the constraints imposed by Virtual Scroller over layout and styling.

Lastly, but importantly, after closer inspection of your proposed solution (other than removing the div, which I don't yet see any good reason to), it omits a crucial point from the original solution: flex-column. If you add it back, the scroll will remain broken; propagating "flex" is not the answer.

My suspicion is that the aforementioned calculations by Virtual Scroller just fail in one or a few corner cases that need to be taken into account (or documented).

from primereact.

@inad9300 I understand your point, and I apologize for not being more precise. However, in my opinion, we need a reproducer that causes your problem and closely resembles your specific case as much as possible. The workaround label is set here because you can utilize that workaround in the given reproducer.

The "good reason to" is simply that this adds one more level to the Dom-Tree, which isn't necessary here.

@melloware I've just tried to dig into this, but the calculation within scroll events in the Virtual Scroller appears to be correct. One point I couldn't figure out in those few minutes is that it seems like the whole thing is rerendered. After reaching a specific position while scrolling (when isRangeChanged is true for the first time), the scroll event triggers again with event.target.scrollTop === 0. I don't know if you or anyone else wants to dig deeper into this!?

To both:
I've just tried to reproduce that on my current project but was not able to. It has to be something with that specific dom/style combination.

from primereact.

(I agree keeping things simple is a good reason to remove the div, it just is a reason unrelated to the problem at hand.)

from primereact.