@aha-app/react-easy-state - npm Package Compare versions

Comparing version 0.0.12-development to 0.0.13-development

dist/cjs.es5.js

@@ -310,8 +310,13 @@ 'use strict';
 function batchSetState(viewIndex, fn) {
+  // If we're in an event handler, we're already batching. Just run
+  // the function.
+  if (inEventLoop) {
+    fn();
+    return;
+  }
+
   batchesPending[viewIndex] = fn;
 
   if (!taskPending) {
-    taskPending = true; // If we're in an event handler, we'll run the batch at the end of it.
-
-    if (inEventLoop) return;
+    taskPending = true;
     queueMicrotask(function () {
@@ -382,7 +387,29 @@ runBatch();
     try {
-      fn.apply(ctx, args);
-
-      if (taskPending) {
-        runBatch();
-      }
+      // When react-easy-state changes are triggered from the main
+      // event loop, they must run inside the main event loop,
+      // instead of being batched in the microtask. Otherwise, the
+      // cursor will jump to the end of input elements, since the
+      // change can't be tied back to the action taken.
+      //
+      // React batches changes caused inside an event loop, so we
+      // can rely on the normal React setState batching for React
+      // events. However, it does its batching inside the event
+      // handler. If we then run setState again outside of the
+      // handler, it will not correctly handle the update and will
+      // put the cursor in the wrong place. This only happens in
+      // production builds of React. But since non-React event
+      // handlers don't batch, we can't assume batching will happen
+      // automatically. So we can't defer batching to the end of the
+      // handler, and can't assume batching will happen inside the
+      // handler -- at least without a way to determine if it's a
+      // React event handler, and I haven't found a way to do that.
+      //
+      // Wrapping each handler in unstable_batchedUpdates is a
+      // sledgehammer, but we don't have a better option. It's
+      // possible this could be narrowed to particular event types
+      // that show a problem. Performance is a concern, but
+      // batchedUpdates doesn't seem to do much if it's not needed.
+      reactPlatform_cjs.unstable_batchedUpdates(function () {
+        fn.apply(ctx, args);
+      });
     } finally {
@@ -389,0 +416,0 @@ inEventLoop = false;

dist/cjs.es6.js

@@ -50,8 +50,13 @@ 'use strict';
 function batchSetState(viewIndex, fn) {
+  // If we're in an event handler, we're already batching. Just run
+  // the function.
+  if (inEventLoop) {
+    fn();
+    return;
+  }
+
   batchesPending[viewIndex] = fn;
 
   if (!taskPending) {
-    taskPending = true; // If we're in an event handler, we'll run the batch at the end of it.
-
-    if (inEventLoop) return;
+    taskPending = true;
     queueMicrotask(() => {
@@ -115,7 +120,29 @@ runBatch();
     try {
-      fn.apply(ctx, args);
-
-      if (taskPending) {
-        runBatch();
-      }
+      // When react-easy-state changes are triggered from the main
+      // event loop, they must run inside the main event loop,
+      // instead of being batched in the microtask. Otherwise, the
+      // cursor will jump to the end of input elements, since the
+      // change can't be tied back to the action taken.
+      //
+      // React batches changes caused inside an event loop, so we
+      // can rely on the normal React setState batching for React
+      // events. However, it does its batching inside the event
+      // handler. If we then run setState again outside of the
+      // handler, it will not correctly handle the update and will
+      // put the cursor in the wrong place. This only happens in
+      // production builds of React. But since non-React event
+      // handlers don't batch, we can't assume batching will happen
+      // automatically. So we can't defer batching to the end of the
+      // handler, and can't assume batching will happen inside the
+      // handler -- at least without a way to determine if it's a
+      // React event handler, and I haven't found a way to do that.
+      //
+      // Wrapping each handler in unstable_batchedUpdates is a
+      // sledgehammer, but we don't have a better option. It's
+      // possible this could be narrowed to particular event types
+      // that show a problem. Performance is a concern, but
+      // batchedUpdates doesn't seem to do much if it's not needed.
+      reactPlatform_cjs.unstable_batchedUpdates(() => {
+        fn.apply(ctx, args);
+      });
     } finally {
@@ -122,0 +149,0 @@ inEventLoop = false;

dist/es.es5.js

@@ -307,8 +307,13 @@ import { useState, memo, useMemo, useEffect, Component } from 'react';
 function batchSetState(viewIndex, fn) {
+  // If we're in an event handler, we're already batching. Just run
+  // the function.
+  if (inEventLoop) {
+    fn();
+    return;
+  }
+
   batchesPending[viewIndex] = fn;
 
   if (!taskPending) {
-    taskPending = true; // If we're in an event handler, we'll run the batch at the end of it.
-
-    if (inEventLoop) return;
+    taskPending = true;
     queueMicrotask(function () {
@@ -379,7 +384,29 @@ runBatch();
     try {
-      fn.apply(ctx, args);
-
-      if (taskPending) {
-        runBatch();
-      }
+      // When react-easy-state changes are triggered from the main
+      // event loop, they must run inside the main event loop,
+      // instead of being batched in the microtask. Otherwise, the
+      // cursor will jump to the end of input elements, since the
+      // change can't be tied back to the action taken.
+      //
+      // React batches changes caused inside an event loop, so we
+      // can rely on the normal React setState batching for React
+      // events. However, it does its batching inside the event
+      // handler. If we then run setState again outside of the
+      // handler, it will not correctly handle the update and will
+      // put the cursor in the wrong place. This only happens in
+      // production builds of React. But since non-React event
+      // handlers don't batch, we can't assume batching will happen
+      // automatically. So we can't defer batching to the end of the
+      // handler, and can't assume batching will happen inside the
+      // handler -- at least without a way to determine if it's a
+      // React event handler, and I haven't found a way to do that.
+      //
+      // Wrapping each handler in unstable_batchedUpdates is a
+      // sledgehammer, but we don't have a better option. It's
+      // possible this could be narrowed to particular event types
+      // that show a problem. Performance is a concern, but
+      // batchedUpdates doesn't seem to do much if it's not needed.
+      unstable_batchedUpdates(function () {
+        fn.apply(ctx, args);
+      });
     } finally {
@@ -386,0 +413,0 @@ inEventLoop = false;

dist/es.es6.js

@@ -47,8 +47,13 @@ import { useState, memo, useMemo, useEffect, Component } from 'react';
 function batchSetState(viewIndex, fn) {
+  // If we're in an event handler, we're already batching. Just run
+  // the function.
+  if (inEventLoop) {
+    fn();
+    return;
+  }
+
   batchesPending[viewIndex] = fn;
 
   if (!taskPending) {
-    taskPending = true; // If we're in an event handler, we'll run the batch at the end of it.
-
-    if (inEventLoop) return;
+    taskPending = true;
     queueMicrotask(() => {
@@ -112,7 +117,29 @@ runBatch();
     try {
-      fn.apply(ctx, args);
-
-      if (taskPending) {
-        runBatch();
-      }
+      // When react-easy-state changes are triggered from the main
+      // event loop, they must run inside the main event loop,
+      // instead of being batched in the microtask. Otherwise, the
+      // cursor will jump to the end of input elements, since the
+      // change can't be tied back to the action taken.
+      //
+      // React batches changes caused inside an event loop, so we
+      // can rely on the normal React setState batching for React
+      // events. However, it does its batching inside the event
+      // handler. If we then run setState again outside of the
+      // handler, it will not correctly handle the update and will
+      // put the cursor in the wrong place. This only happens in
+      // production builds of React. But since non-React event
+      // handlers don't batch, we can't assume batching will happen
+      // automatically. So we can't defer batching to the end of the
+      // handler, and can't assume batching will happen inside the
+      // handler -- at least without a way to determine if it's a
+      // React event handler, and I haven't found a way to do that.
+      //
+      // Wrapping each handler in unstable_batchedUpdates is a
+      // sledgehammer, but we don't have a better option. It's
+      // possible this could be narrowed to particular event types
+      // that show a problem. Performance is a concern, but
+      // batchedUpdates doesn't seem to do much if it's not needed.
+      unstable_batchedUpdates(() => {
+        fn.apply(ctx, args);
+      });
     } finally {
@@ -119,0 +146,0 @@ inEventLoop = false;

package.json

 {
   "name": "@aha-app/react-easy-state",
-  "version": "0.0.12-development",
+  "version": "0.0.13-development",
   "description": "React state management with a minimal API. Made with ES6 Proxies.",
@@ -5,0 +5,0 @@ "main": "dist/cjs.es6.js",

No alert changes

Improved metrics

Total package byte prevSize

225297

increased by6.01%

Lines of code

2042

increased by5.8%

No dependency changes