@webqit/webflo 0.20.2-next.0 → 0.20.2-next.2

package/site/.vitepress/dist/assets/-__.md.wD5kDRhS.js

@@ -0,0 +1 @@
+import{_ as t,c as n,o as i,a2 as a}from"./chunks/framework.9Uv4PgnO.js";const h=JSON.parse('{"title":"","description":"","frontmatter":{},"headers":[],"relativePath":"-/_.md","filePath":"-/_.md"}'),l={name:"-/_.md"};function s(r,e,o,c,p,u){return i(),n("div",null,[...e[0]||(e[0]=[a("<pre><code>event.client.wqForwardPort(&#39;*&#39;, chatPort, { bidirectional: true });\n</code></pre><ul><li><strong>?_rid=</strong> - checked before routing happens <ul><li>assigned to the request internally as requestMeta.redirectID</li><li>Internal requestMeta.carries is populated with session[`carry-store:[requestMeta.redirectID]&#39;];</li><li>session[`carry-store:[requestMeta.redirectID]&#39;] is unset. Handlers don&#39;t see it</li></ul></li><li>route(SETUP) runs</li><li>route() runs <ul><li>Httpevent.client.wqLifecycle.messaging.then(() =&gt; { autoLiveResponse = new LiveResponse(null, { status: 202, statusText: &#39;Accepted&#39;, done: false }); resolve(autoLiveResponse); });</li><li>autoLiveResponse.replaceWith() is used later when response comes</li></ul></li><li>response obtained</li><li>user, session, cookies committed</li><li>HttpEvent.waitUntil(response.whileLive())</li><li>if (!HttpEvent.lifeCycleComplete()) <ul><li>response.headers[&#39;X-Background-Messaging-Port&#39;] is set. (Client-side: the realtime instance is set)</li><li>realtime.close() is called either: on navigate (and default not prevented) or HttpEvent.lifeCycleComplete(true)</li></ul></li><li>if (!this.isClientSide &amp;&amp; response instanceof LiveResponse) <ul><li>return response.toResponse({ clientRequestRealtime: Httpevent.client });</li></ul></li></ul><hr><ul><li>if response[Location] and is a fresh target <ul><li>Generate redirectID: randomUUID</li><li>assign carry to session[`carry-store:[redirectID]&#39;]</li></ul></li><li>if response[Location] and is a return back to a known location <ul><li>prepend carry to session[`carry-store:[redirectID]&#39;]</li></ul></li></ul><ul><li><p>event.waitUntilNavigate()</p></li><li><p>return event.poll(() =&gt; { return { value, done }; }, { interval = 3000, maxClock = -1, whileOpen = 1, cleanupCall = false });</p></li><li><p>The caller receives a generator</p></li><li><p>HttpEvent.signal aborts when</p><ul><li>parent event&#39;s signal aborts</li><li>request&#39;s signal aborts</li><li>HttpEvent.abort() is called</li><li>handler returns, plus all handlers in subtree return; i.e. all handlers complete their lifecycle</li></ul></li><li><p>root HttpEvent is aborted on any of the above or when Realtime closes</p></li><li><p>Realtime closes when</p><ul><li>is closed from client</li><li>Httpevent.client&#39;s <code>navigation</code> event fires and is not default-prevented</li><li>root event completes its lifecycle</li></ul></li><li><p>Quantum state and Generators auto end when</p><ul><li>HttpEvent.signal aborts</li></ul><p>async * poll(...args) { const callback = typeof args[0] === &#39;function&#39; ? args.shift() : () =&gt; null; let { interval = 3000, maxClock = -1, whileOpen = 1, cleanupCall = false } = args[0] || {}; if (whileOpen) { await this.realtime.wqLifecycle.open; } while (true) { const termination = maxClock === 0 || (whileOpen &amp;&amp; _wq(this.realtime, &#39;meta&#39;).get(&#39;close&#39;)) || (whileOpen === 2 &amp;&amp; this.realtime.navigatedIn()) || (whileOpen &amp;&amp; whileOpen !== 2 &amp;&amp; this.realtime.navigatedAway()); const returnValue = ((!termination || cleanupCall) &amp;&amp; await callback(termination)) ?? { done: true }; if (returnValue !== undefined &amp;&amp; (!_isObject(returnValue) || _difference(Object.keys(returnValue || {}), [&#39;value&#39;, &#39;done&#39;]).length)) { throw new Error(&#39;Callback must return an object with only &quot;value&quot; and &quot;done&quot; properties&#39;); } if (typeof returnValue?.value !== &#39;undefined&#39;) { yield returnValue.value; } if (returnValue?.done) { return; } await new Promise((resolve) =&gt; setTimeout(resolve, interval)); maxClock--; } }</p></li></ul><p>wait: a few thoughts that i&#39;ll leave to your descretion:</p><ul><li><p>for a dev coming first time to the concept of realtime, have we properly mapped to what they might know or the traditional approach outisde of webflo - so they can diff this mentially?</p></li><li><p>does it improve the language to say that a handler &quot;enters background mode&quot; - implicitly on their first interaction/push with event.client (whether directly or via the higher-level APIs)?</p></li><li><p>is it clear that what happens is: on entering background mode, the server sends a certain connection-details to the client to conncect via ws. the ws connection is tied to the actively processing request and event.client. since the client has to be told to connect and given how to connect before messaging becomes two-way, if background is triggered before first normal response is returned from handler, webflo sends an empty response (new LiveResponse(null, { status: 202, statusText: &#39;Accepted&#39;, done: false })) carrying the ws header (&#39;X-Background-Messaging-Port&#39;). communication begins and when actual responses arrive susequently, the initial liveresponse is replaced. the client, on receiving the inital status code and header and live response, knows to wait for the real responses; so enters background mode automatically. this makes it entirely seamless for the running handler: just interact while webflo fullfills the intent. up to the point that if a handler unnecessarily leaves the channel open, webflo&#39;s &quot;close on user navigation&quot; approach comes to the rescue.</p></li><li><p>maybe keep these new &quot;handshaking&quot; and transport unification details to a section of its own with appropriate diagrams. (i forgot to add that on waiting for client to connect, theres a timeout before Webflo forgets about waiting and takes it that client has no such ws capabilities.)</p></li><li><p>is it clear that handlers at all layers of the stack are who can work this way?: initiate a connection. while server-level handlers communicate with client over ws, service-worker-level handlers do so over Browser&#39;s broadcast messaging. client-level handlers do so over direct message channel. so, regardless of where a handler runs, they all behave the same. (e.g. renaming an interactive handler from handler.server.js to handler.worker.js or handler.client.js doesnt require change of code. interactivity remains in tact. only the lowlevel wiring changes - and done by webflo)</p></li><li><p>meanwhile, point of correction regarding the client side of the channel: listerning to handler-sent background messages isnt done via event.client - that&#39;s the master end of the line. so whether it is: // handler.server.js or handler.worker.js or handler.client.js export default async function(event) { event.client === master port } actually the default listener to all these handlers is the running Webflo client at the top-most level: the browser window. listens for response replacement events and updates the UI, listens for confirms and prompts and auto fires the appropriate UI model for the user and responds back to the request. (but app-level script may intercept these dialog prompts and fire custom modal and respond - then call event.preventDefault() so that Webflo client doesnt do the default action).</p></li><li><p>a client-side handler may listen to worker-side or server-side handler (the upstream), and worker-side handler may listen to server-sent events - throught the recieved response object they recieve on calling next()/fetch(): export default async function(event) { if (next.stepname) return await next(); // Handle this level&#39;s request const upstreamResponse = await next(); const liveResponse = LiveResponse.from(upstreamResponse); liveResponse.realtime.addEventListener(&#39;prompt&#39;, (e) =&gt; e.preventDefault()); // Just to illustrate. may be an actual response back to upstream // And we can be conducting our own conversation from this level in the request/response line }</p></li><li><p>also is it clear that LiveResponse is backward-compatible in API woth Response? with useful additions?</p></li><li><p>is it clear that, e.g. for returning json data, we can as well just use the constructor? new LiveResponse(data, { done: false, status: 200, headers });</p></li><li><p>lastly, is it clear that live responses arent just about the responsde body? any changes in headers or status orr statusText also gets to the client. thats why, e.g. after returning a contenful response, u could do liveResponse.replaceWith(null, { status: 203, headers: { Location } }); and the webflo client will redirect the UI</p></li></ul><p>at this point let me know what you think. will page structure need a change to properly present this story fluently and excitingly? will another approach to something on the page be needed?</p>",8)])])}const m=t(l,[["render",s]]);export{h as __pageData,m as default};

package/site/.vitepress/dist/assets/-__.md.wD5kDRhS.lean.js

@@ -0,0 +1 @@
+import{_ as t,c as n,o as i,a2 as a}from"./chunks/framework.9Uv4PgnO.js";const h=JSON.parse('{"title":"","description":"","frontmatter":{},"headers":[],"relativePath":"-/_.md","filePath":"-/_.md"}'),l={name:"-/_.md"};function s(r,e,o,c,p,u){return i(),n("div",null,[...e[0]||(e[0]=[a("",8)])])}const m=t(l,[["render",s]]);export{h as __pageData,m as default};