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

feat(modal): programmatically move to a breakpoint #24648

Open
wants to merge 19 commits into
base: feature-6.1
Choose a base branch
from

Conversation

EinfachHans
Copy link
Contributor

@EinfachHans EinfachHans commented Jan 25, 2022

Pull request checklist

Please check if your PR fulfills the following requirements:

  • Tests for the changes have been added (for bug fixes / features)
  • Docs have been reviewed and added / updated if needed (for bug fixes / features)
  • Build (npm run build) was run locally and any changes were pushed
  • Lint (npm run lint) has passed locally and any fixes were made for failures

Pull request type

Please check the type of change your PR introduces:

  • Bugfix
  • Feature
  • Code style update (formatting, renaming)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • Documentation content changes
  • Other (please describe):

What is the current behavior?

Developers cannot programmatically move a sheet modal breakpoint with an API.

Issue Number: #23917

What is the new behavior?

  • setCurrentBreakpoint(breakpoint: number) to programmatically change the breakpoint of a sheet modal.
  • getBreakpoint() to get the active breakpoint value for a sheet modal.
  • ionModalBreakpointWillChange/breakpointWillChange event when the breakpoint is about to change.
  • ionModalBreakpointDidChange/breakpointDidChange event when the breakpoint changes.
  • extract Code to animate the gesture to a specific breakpoint to be used for the new method and the existing usage of the gesture
  • after this is merged #24069 is easy as well, i can create a PR for this as well

Does this introduce a breaking change?

  • Yes
  • No

Other information

# Conflicts:
#	core/src/components/modal/gestures/sheet.ts
Copy link
Contributor

@sean-perkins sean-perkins left a comment

Have one suggested change for the public API naming for setting the breakpoint value.

Reviewed most of the changes here and they align with our internal feature design document. I would like to introduce a set of e2e tests on this new behavior, mainly to verify correct event emission and a few screenshot tests. I'll clone your fork this week and experiment with your changes to verify everything works correctly and will suggest a few tests on the new behavior.

Thanks for the great work here!

core/src/components/modal/modal.tsx Outdated Show resolved Hide resolved
@sean-perkins sean-perkins self-assigned this Mar 8, 2022
@sean-perkins sean-perkins changed the base branch from main to feature-6.1 Mar 8, 2022
core/src/components/modal/modal.tsx Outdated Show resolved Hide resolved
core/src/components/modal/modal.tsx Outdated Show resolved Hide resolved
@EinfachHans
Copy link
Contributor Author

@EinfachHans EinfachHans commented Mar 9, 2022

@sean-perkins Changes applied 😊

Copy link
Contributor

@sean-perkins sean-perkins left a comment

We are getting close! Had one question.

I need to sync with the team tomorrow, trying to figure out the best way to test/validate a breakpoint is transitioned to correctly. Currently added coverage for events emitting/breakpoint values being set correctly.

Also due to the way we overwrite the implementation of ion-modal in Angular, I need to add a small set of e2e tests to our Angular test app to validate event emissions. I should be able to finish this piece tonight.

core/src/components/modal/gestures/sheet.ts Show resolved Hide resolved
@sean-perkins sean-perkins self-requested a review Mar 11, 2022
Copy link
Contributor

@sean-perkins sean-perkins left a comment

Did a fresh review based on the current state and I do not see any outstanding changes. I am going to add the team for review. They may come back with changes or additional suggestions.

I opted for not documenting the new API extensively in our usage docs, since it's a public method API and not really a usage pattern. I'm open to ideas on how to document it, if we feel there is value in doing so. Currently I could not justify it over vs. people looking at the generated API docs and seeing getBreakpoint and setCurrentBreakpoint.

Thanks for the heavy lifting on this feature and being available for quick changes + answering questions via Discord. Really appreciate the help on this. This is such a cool feature!

@sean-perkins sean-perkins removed their assignment Mar 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

3 participants