work

Author: dmail

dist/build/build.js

@@ -2131,6 +2131,10 @@ const createUrlInfo = (url, context) => {
     modifiedTimestamp: 0,
     descendantModifiedTimestamp: 0,
     dereferencedTimestamp: 0,
+    // when a client last fetched this url outside a hot request; in other
+    // words the last time this url entered a fresh page (see
+    // jsenv_plugin_hot_search_param)
+    servedWithoutHotTimestamp: 0,
     originalContentEtag: null,
     contentEtag: null,
     isValid: () => false,
@@ -9445,6 +9449,7 @@ const jsenvPluginHotSearchParam = () => {
         modifiedTimestamp,
         descendantModifiedTimestamp,
         dereferencedTimestamp,
+        servedWithoutHotTimestamp,
       } = referencedUrlInfo;
       if (
         !modifiedTimestamp &&
@@ -9468,6 +9473,18 @@ const jsenvPluginHotSearchParam = () => {
         descendantModifiedTimestamp,
         dereferencedTimestamp,
       );
+      // These timestamps say "this url changed at some point", not "the client
+      // is running an outdated version of it": they are never cleared, so a
+      // file modified once keeps them for the rest of the dev server's life.
+      // A client that fetched this url after that modification (a page load:
+      // see rememberServedWithoutHot in the dev server) already runs the
+      // latest content. Sending it "?hot" then makes the browser evaluate a
+      // second, identical copy of a module it already has — a second module
+      // scope for a file that never changed, which breaks everything a module
+      // holds once (registries, contexts, singletons).
+      if (latestTimestamp <= servedWithoutHotTimestamp) {
+        return null;
+      }
       return {
         hot: latestTimestamp,
       };

dist/start_dev_server/start_dev_server.js

@@ -7170,6 +7170,7 @@ const jsenvPluginHotSearchParam = () => {
         modifiedTimestamp,
         descendantModifiedTimestamp,
         dereferencedTimestamp,
+        servedWithoutHotTimestamp,
       } = referencedUrlInfo;
       if (
         !modifiedTimestamp &&
@@ -7193,6 +7194,18 @@ const jsenvPluginHotSearchParam = () => {
         descendantModifiedTimestamp,
         dereferencedTimestamp,
       );
+      // These timestamps say "this url changed at some point", not "the client
+      // is running an outdated version of it": they are never cleared, so a
+      // file modified once keeps them for the rest of the dev server's life.
+      // A client that fetched this url after that modification (a page load:
+      // see rememberServedWithoutHot in the dev server) already runs the
+      // latest content. Sending it "?hot" then makes the browser evaluate a
+      // second, identical copy of a module it already has — a second module
+      // scope for a file that never changed, which breaks everything a module
+      // holds once (registries, contexts, singletons).
+      if (latestTimestamp <= servedWithoutHotTimestamp) {
+        return null;
+      }
       return {
         hot: latestTimestamp,
       };
@@ -9675,6 +9688,10 @@ const createUrlInfo = (url, context) => {
     modifiedTimestamp: 0,
     descendantModifiedTimestamp: 0,
     dereferencedTimestamp: 0,
+    // when a client last fetched this url outside a hot request; in other
+    // words the last time this url entered a fresh page (see
+    // jsenv_plugin_hot_search_param)
+    servedWithoutHotTimestamp: 0,
     originalContentEtag: null,
     contentEtag: null,
     isValid: () => false,
@@ -11922,7 +11939,20 @@ const devServerPluginServeSourceFiles = ({
             );
             return response;
           };
+          // What the client holds for this url is what we last sent it: a
+          // request without "?hot" is a page loading this url into an empty
+          // module registry, so from here on the client runs this exact
+          // content. Remembering when that happened is what allows
+          // jsenv_plugin_hot_search_param to tell a modification the client
+          // has already received from one it must re-execute to see.
+          const rememberServedWithoutHot = () => {
+            if (request.searchParams.has("hot")) {
+              return;
+            }
+            urlInfo.servedWithoutHotTimestamp = Date.now();
+          };
           const respondWithNotModified = () => {
+            rememberServedWithoutHot();
             const headers = {
               "cache-control": `private,max-age=0,must-revalidate`,
             };
@@ -12007,6 +12037,9 @@ const devServerPluginServeSourceFiles = ({
             ) {
               return respondWithNotModified();
             }
+            if (urlInfo.status === 200) {
+              rememberServedWithoutHot();
+            }
             response = {
               url: reference.url,
               // a plugin can cook a complete response body for an url that is

package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jsenv/core",
-  "version": "41.5.14",
+  "version": "41.5.15",
   "type": "module",
   "description": "Tool to develop, test and build js projects",
   "repository": {

packages/frontend/navi/dist/dev/jsenv_navi.js.map

@@ -244,6 +244,17 @@ invisible at the call site and expensive on screen: the request then leaves with
 the gesture instead of with the screen, one waterfall behind everything else the
 address needed.
 
+**A route action is a read.** The parameter says whose data it is; it does not
+say who may ask for it. An address asks again on every arrival — a reload, a
+pasted link, a step back — which is exactly what a read is for and what a write
+cannot survive: `POST /users/:id/invitations` hung on `/users/:id` mints a token
+per reload, for ever, and nothing at the call site says so. So a run that writes
+belongs to the component that decided to write, whatever its parameter, and
+`{ run: true }` is what says it. That is the shape of a request prepared for a
+gesture — a token a share button must already hold when it is pressed, since the
+OS share sheet only opens inside the gesture and never after an `await`: it runs
+at mount because the press cannot wait for it, not because the address changed.
+
 `{ onLoad }` is what the screen does with the data **once, when it becomes
 known** — seed the fields someone is about to edit, focus something, remember
 where a list was:

packages/frontend/navi/dist/jsenv_navi.js.map

@@ -1,6 +1,6 @@
 {
   "name": "@jsenv/navi",
-  "version": "0.29.219",
+  "version": "0.29.220",
   "type": "module",
   "description": "Library of components including navigation to create frontend applications",
   "repository": {

packages/frontend/navi/docs/actions.md

@@ -87,7 +87,9 @@ import { usePromiseAsyncData } from "./use_promise_async_data.js";
  *   needs, whereas this one cannot start before the component that draws it
  *   exists — one render late, and behind whatever gesture mounted it. What is
  *   left for `run` is the parameter chosen inside the component and dying with
- *   it (see docs/actions.md and docs/popup_open.md).
+ *   it — and any run that WRITES, whatever its parameter: an address asks again
+ *   on every arrival, which is right for a read and wrong for a write (see
+ *   docs/actions.md and docs/popup_open.md).
  * @param {(data: any, context: {params: any}) => void} [options.onLoad] - what
  *   this screen does with the data ONCE, when it becomes known: seed the fields
  *   someone is about to edit, remember where a list was, focus something.

packages/frontend/navi/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jsenv/cli",
-  "version": "0.3.178",
+  "version": "0.3.179",
   "type": "module",
   "description": "Command Line Interface for jsenv",
   "repository": {

packages/frontend/navi/src/state/async/use_async_data.jsx

@@ -13,7 +13,7 @@
   },
   "devDependencies": {
     "@jsenv/assert": "4.5.7",
-    "@jsenv/core": "41.5.14",
+    "@jsenv/core": "41.5.15",
     "@jsenv/eslint-config-relax": "2.0.3",
     "@jsenv/test": "3.7.45",
     "eslint": "10.9.1",