Prototype: Multi-stage component UI update on Action

[yznts]

Explore possibility to use server-sent events to deliver multiple UI updates.
Logic must to be similar to "flush" functionality of ORM frameworks, something like kyoto.SSAFlush(p)

Required knowledge:

• SSE API (https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events)
• SSA lifecycle theory and code (https://kyoto.codes/extended-features.html#ssa-lifecycle and https://github.com/yuriizinets/kyoto/blob/master/ext.ssa.go)
• SSA communication layer code (https://github.com/yuriizinets/kyoto/blob/master/payload/src/dynamics.ts)

Issue might be pretty hard to implement for people unfamiliar with project, but very interesting for those who want to explore project codebase.

[OpenSauce]

Good to see an explanation of issues for the newer members 😀

[yznts]

Project structure is pretty complex, I think such descriptions will be useful for external contributors :)

[yznts]

Brian Ketelsen already working on this issue, just for info

[OpenSauce]

All good!

[bketelsen]

I went about this in a different direction because SSE will require server-side state. See #67 for a much more simple solution that serves the same functionality.

[yznts]

@bketelsen
As I understood, you want to keep connection as long as client side page is opened.
My idea was to open and close SSE connection on Action start and ending. No reason to keep connection opened. In that way we can use SSE just for sending UI updates multiple times.
Regarding state. I don't fully understand what the problem is, but state is saving inside of DOM as attribute while calling {{ componentattrs . }}. On Action call we are sending this state with request to the server side, so server is not obliged to save a state. This approach has its drawbacks, like any other (I'm going to add server side state as an alternative).

Anyway thank you for polling mechanism!
I'd like to continue to explore possibility of implementing this feature as far as polling designed for another kind of things (like periodic chart or info update). Running and stopping polling process on demand will require explicit JS and knowledge of how communication layer is working under the hood. On my opinion, triggering UI update inside of action will be much easier to understand.
I have some ideas, so, I'll return to this issue soon :)

[yznts]

Playing around with SSE. The only problem that I see now is that it's not support POST parameters.

[yznts]

OK, I was able to make a small working prototype, bit it still pretty raw and need some work.

Just a few demo how it's working

https://user-images.githubusercontent.com/17050536/140584674-af99859e-002e-43de-81e1-ee955dc525f3.mp4

[bketelsen]

Very nice, clearly your kung fu is stronger than mine! That's exactly what I was hoping it would look like.

[yznts]

@bketelsen I don't think so 😄

Uploaded my prototype to 62-actions-with-sse branch, but still need improvements and tests.
Some notes:

• Replaced form data with URL parameters (SSE doesn't support POST data, at least browser's built-in EventSource). It's not a good approach, but I don't see alternatives for now.
• Need to figure out GET request limitations. As I know, browser has limit ~250 chars for address bar, but need to check is it relates only to address bar, or just all GET requests.
• Changed SSA call semantic. Now it's /SSA/<ComponentName>/<ComponentState>/<ActionName>/<ActionArgs>. This semantic is more logical on my opinion.
• Redirect inside of Action is not working. Can't read headers from EventSource, so I'll need to think a bit on alternative approach regarding such commands.

[bketelsen]

i just saw this branch and checked it out. The code is there, but when I click the start button the spinner appears on the button, it spins for a few seconds, but the UI never updates the {{ .Status }} text. I looked in the browser dev tools, and the calls are being made to the web server and it's getting a valid response, but the response isn't being applied to the dom. What am I missing?

[yznts]

Spinner is a demo for loading state, not for flush. Seems like I forgot to add needed markup for demo :) Just a sec, I'll upload update.

UPD. Ready

[bketelsen]

so much better! Works beautifully. Great job.

[yznts]

Thanks! :) Anyway, as I said before, it requires some work. Planning to finish this weekends.
If you'll notice any problems with this prototype on this period, please, write a comment here.

[yznts]

Tested large state payloads. Seems like placing state into EventSource url not causing any problems, at least in Safari.

[yznts]

@bketelsen Hey, Brian!
I've updated/fixed some things in the feature branch and fixed ssa redirect degradation. Please, can you check if it works for you?

On my opinion, switch to EventSource over fetch will give more benefits in the future :)

[bketelsen]

works great!

[yznts]

OK, that's good! I'll merge this feature into master.

With this feature I've made few important changes:

• Redirect context change. Instead of pushing just a bool flag into context, I'm pushing target url
• Redirect in case of SSA is pushed as command inside of data, instead of header. Headers are not accessable with EventSource
• SSA call signature change. Current signature is /SSA/<ComponentName>/<ComponentState:json:base64>/<Action>/<Arguments:json:base64>
• SSAHandler is responsible for state and arguments base64 decoding, not SSARender. It makes more sense
• And most important, migration to SSE instead of regular request/response

This changes may break something for people, who using library internals instead of public functions. I'll mention all that changes in release notes for 0.2.

@bketelsen if you'll notice something wrong with Actions, please, let me know

[bketelsen]

Just updated my LXD admin UI to use this and it's delightful. Works perfectly and reduced a bunch of redirecting too.

[yznts]

Awesome :) Let me know if you'll have any other ideas on lib improvement