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

refactor(*): Remove the need of hardcoded item heights in combo #14871

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

mddragnev
Copy link
Member

@mddragnev mddragnev commented Oct 3, 2024

Closes #14285

Additional information (check all that apply):

  • Bug fix
  • New functionality
  • Documentation
  • Demos
  • CI/CD

Checklist:

  • All relevant tags have been applied to this PR
  • This PR includes unit tests covering all the new code (test guidelines)
  • This PR includes API docs for newly added methods/properties (api docs guidelines)
  • This PR includes feature/README.MD updates for the feature docs
  • This PR includes general feature table updates in the root README.MD
  • This PR includes CHANGELOG.MD updates for newly added functionality
  • This PR contains breaking changes
  • This PR includes ng update migrations for the breaking changes (migrations guidelines)
  • This PR includes behavioral changes and the feature specification has been updated with them

@mddragnev mddragnev marked this pull request as ready for review October 10, 2024 08:13
@mddragnev mddragnev changed the title refactor(*): Remove the need of hardcoded item heights refactor(*): Remove the need of hardcoded item heights in combo Oct 10, 2024
tishko0
tishko0 previously approved these changes Nov 1, 2024
@tishko0 tishko0 added ✅ status: verified Applies to PRs that have passed manual verification and removed ❌ status: awaiting-test PRs awaiting manual verification labels Nov 1, 2024
@ChronosSF ChronosSF changed the base branch from master to 19.0.x November 25, 2024 16:21
@ChronosSF ChronosSF dismissed tishko0’s stale review November 25, 2024 16:21

The base branch was changed.

chore(*): fix lint

chore(*): fix another lint

chore(*): Clean up code. Change some tests and remove some

chore(*): Some more cleanup. Fix tests
@mddragnev mddragnev force-pushed the mdragnev/combo-itemheight branch from 8d2cfb1 to 7b9d9fc Compare January 9, 2025 14:14
@mddragnev mddragnev changed the base branch from 19.0.x to master January 9, 2025 14:15
private _itemsMaxHeight = null;
private _overlaySettings: OverlaySettings;
private _groupSortingDirection: SortingDirection = SortingDirection.Asc;
private _filteringOptions: IComboFilteringOptions;
private _defaultFilteringOptions: IComboFilteringOptions = { caseSensitive: false };
private itemsInCointaner = 10;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo -> itemsInContainer :)

Comment on lines 1014 to 1023
this.dropdown?.animationStarting.subscribe((_args: ToggleViewEventArgs) => {
// calculate the container size and item size based on the sizes from the DOM
const dropdownContainerHeight = this.dropdownContainer.nativeElement.getBoundingClientRect().height;
if (dropdownContainerHeight) {
this.containerSize = parseFloat(dropdownContainerHeight);
}
if (this.dropdown.children?.first) {
this.itemSize = this.dropdown.children.first.element.nativeElement.getBoundingClientRect().height;
}
});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, so this is happening because the overlay opening is emitted before updating sizes, which I realize is likely to check for cancel and avoid doing redundant work. The issue is animationStarting is not guaranteed:

if (info.settings.positionStrategy.settings.openAnimation) {
// TODO: should we build players again. This was already done in attach!!!
// this.buildAnimationPlayers(info);
this.playOpenAnimation(info);

As we discussed, the things updateSize can probably be performed in advance without causing trouble, though I'll tag @wnvko in case he can recall reasons not to.

Alternatively, the combo itself can patch opening and force the update sooner to be able to calculate those on opening.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, it's also quite possible we could move the --ig-size transfer on attach entirely, since that doesn't change after the fact and it's applied to the content container, if the other stuff are not safe to move.
That's all to avoid both relying on animationStarting and propagating it across components :)

* Initial chunk size if no container size is passed. If container size is passed then the igxForOf calculates its chunk size
*/
@Input()
public igxForInitialChunkSize: any;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess existing combo tests somewhat cover the use of igxForInitialChunkSize but it wouldn't hurt to have at least one unit test covering this just for the for-of

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
combo simple-combo version: 19.1.x ✅ status: verified Applies to PRs that have passed manual verification
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Remove the need for the common combo to hardcode ItemHeights
5 participants