|
Ah ok the question is, what exactly is being streamed and why, given that the input state, per the todo-app AST, should not yet be transmitted? The traffic here is "program debug state" — the electric callback was called on the client, so the client informs the server of this in case the callback has server regions. As you rightfully point out, there are in fact no server regions in that callback — and this is known at compile time — so there is no need to actually send that information, it is pure overhead. The missing optimization is basically dead code elimination – we simply haven't gotten to it yet. Note that the traffic is broadcast, not request/response, which means the user experiences no latency as the client is not awaiting any response from the server, it is simply keeping the server informed. Due to this, broadcasting "program debug state" like this is basically free, which is why we consider this optimization premature. We are much more interested in visible perf issues (how fast it "feels"). FWIW we are unhappy with dom/on (used in that tutorial) and it is about to be superseded, and the chattiness you observed is derived from one of the aspects of the design that we are fixing (there should not be a callback at all, the input should return its reactive state directly.) But to be clear the pattern is perfectly functional, it doesn't have bugs, and users are succeeding with it. |