Ziad Beyens

Thank you for your feedback and for expressing your concerns. I understand that introducing **`| undefined`** in return types may lead to a more challenging migration process for larger projects....

@BrentFarese Sounds good, every single `throw` has been replaced by `onError` so we should be good on that point. I've also added a few `onError` calls to `apply` – this...

Thanks for your review @bryanph. This is indeed required to support `onError` handlers that are not throwing. Here is the quickest migration using non-null assertion (estimating to a couple of...

Based on the feedback we've received, we are leaning towards the idea that `onError` should throw by default, allowing the developer to override this behavior if needed. This approach should...

Here is my last update, still open to feedback. - We're keeping the current behavior as the default until the stability of the new one is assured (**`editor.strict = true`**)....

The new `onError` approach seeks to provide a granular, customizable error-handling API that extends beyond what the `ErrorBoundary` approach can provide. While an `ErrorBoundary` indeed helps capture generic errors, it...

I can understand this PR has a few risks we could optimize from Dylan’s review. I won’t have free time to split that PR for a few weeks so my...

We should check the value of all selected blocks using `getNodeEntries`, and return true only if `every` block has the same value. One different value makes it false (like marks).

Here is my workaround: ```ts export const usePRouter = () => { const router = useRouter(); const { push } = router; router.push = (href, options) => { NProgress.start(); push(href,...

@PixeledCode Forgot to mention I've forked that library