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

Column breakpoints in fast-layouts uses the default breakpoints to determine start/span values #2602

Closed
shauntc opened this issue Jan 22, 2020 · 5 comments

Comments

@shauntc
Copy link
Contributor

shauntc commented Jan 22, 2020

The fast layouts column uses the default breakpoints instead of ones set in the fast breakpoint tracker to determine what span/start value to use (though the check is triggered by the fast breakpoint tracker breakpoints).

This happens because this line uses this utility function without a second parameter, causing it to use the default value (which is the default breakpoints). The easiest solution would be to just add passing in the breakpoints here but I would suggest also removing the default value here or moving things around so that defaultBreakpoints are never exposed (and are only used by the fast breakpoint tracker)

What are the steps to reproduce the issue?

  1. Create a layout with a span/start column value defined as an array of values
  2. Set new breakpoint numbers
  3. alter the window size, notice that it will only transition when the new breakpoint number are hit but will use the defaultBreakpoints values to select which span/start value to use
@triage-new-issues triage-new-issues bot added the status:triage New Issue - needs triage label Jan 22, 2020
@triage-new-issues triage-new-issues bot removed the status:triage New Issue - needs triage label Jan 22, 2020
@chrisdholt
Copy link
Member

@shauntc would you like to send a PR for this?

@shauntc
Copy link
Contributor Author

shauntc commented Jan 23, 2020

@chrisdholt I can do a PR for this but it'll be a few days before I get to it

@chrisdholt
Copy link
Member

@chrisdholt I can do a PR for this but it'll be a few days before I get to it

That works for us - if we get additional feedback that this is higher impact from other folks we can jump on it; though, considering you filed the issue I'll trust your priority on it :).

Thanks!

@stale
Copy link

stale bot commented Apr 23, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the warning:stale No recent activity within a reasonable amount of time label Apr 23, 2020
@EisenbergEffect EisenbergEffect added area:react and removed complexity : low bug A bug warning:stale No recent activity within a reasonable amount of time labels Jul 17, 2020
@chrisdholt
Copy link
Member

closed with #3517

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants