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

LocalHistory conflicts #32

Open
iazel opened this issue Aug 30, 2023 · 0 comments
Open

LocalHistory conflicts #32

iazel opened this issue Aug 30, 2023 · 0 comments

Comments

@iazel
Copy link

iazel commented Aug 30, 2023

Hi, after trying it more and better understanding LocalHistory, I believe current implementation conflicts with what I'd like to achieve.

In my app, I have a button to enter "selection mode", that's because I decided to use longpress interaction for reordering items. The big difference is that selection mode is unrelated to how many items are selected.

I would like to use LocalHistory to exit selection mode, but this conflicts with current lib implementation: if I add a new entry, then the user should have to go back twice in case anything is selected, due to the entry created by this lib.

After some thinking, is it really a good idea to hide this LocalHistoryEntry in a widget? I'd suggest that it's best to handle LocalHistory at screen level, rather than in a widget that technically has nothing to do with navigation.

What about extracting this functionality in another widget that is separate from the main one? It should be quite straightforward to implement it using the selection controller.

As a note, for now I've just forked the lib and removed related code, thus I am not blocked or anything like that.

Let me know what you think, and if needed I can help with a PR :)

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

1 participant