Prototype: Multi-stage component UI update on Action about kyoto HOT 20 CLOSED

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

from kyoto.

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.

from kyoto.

@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 :)

from kyoto.

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

from kyoto.

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

from kyoto.

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

from kyoto.

Brian Ketelsen already working on this issue, just for info

from kyoto.

All good!

from kyoto.

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.

from kyoto.

@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 :)

from kyoto.

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

from kyoto.

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

from kyoto.

@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.

from kyoto.

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?

from kyoto.

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

from kyoto.

so much better! Works beautifully. Great job.

from kyoto.

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

from kyoto.

works great!

from kyoto.

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

from kyoto.

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

from kyoto.