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

Recover from exception when flushing inside android plugin #3025

Conversation

gracicot
Copy link
Contributor

Is this adding or improving a feature or fixing a bug?

Fixing a bug

What's the new behavior?

The plugin will recover its state when an exception is thrown while flushing

How does this change work?

Before, the startAction function would simply fush everything and then cleanup the state.

When an exception was thrown, the plugin would not recover correctly. When using error boundaries and then recovering, the editor would simply not flush anymore since the variable isFlushing would always be true. Adding the finally can make the editor recover from a throwing plugin or an error in the flush

Have you checked that...?

  • The new code matches the existing patterns and styles.
  • The tests pass with yarn test.
  • The linter passes with yarn lint. (Fix errors with yarn prettier.)
  • The relevant examples still work. (Run examples with yarn watch.)

Does this fix any issues or need any specific reviewers?

Reviewers: @thesunny @ianstormtaylor

@gracicot
Copy link
Contributor Author

I don't know what exception safety Slate usually ensure. I don't have a strong opinion on this one, but I think be able to recover the error here can be useful.

@thesunny
Copy link
Collaborator

Ooh nice catch. Happy to see people making improvements on the Android code.

When I get a chance, I'll test on my devices but it looks good from here. Thanks!

@ianstormtaylor
Copy link
Owner

Hey, there are lots of open Android-related issues that are out of date with the latest 0.50 release because the codebase was completely rearchitected. We'll need to figure out how to have proper support for Android going forward based on beforeinput events somehow. I'm tracking this in #3112, so I'm going to close this in favor of that one.

If it cannot be implemented simply in core with beforeinput we'll likely need to have a separate plugin for android support be created, because it's too much of a departure from all of the other simpler logic in core and very hard for me to test or respond to issues. Using a separate plugin should be possible now as the newest version simplifies a lot of the internals.

Thank you for understanding.

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

Successfully merging this pull request may close these issues.

3 participants