search

pkamenarsky / concur-replica

Server-side VDOM UI framework for Concur
BSD 3-Clause "New" or "Revised" License
139 stars 20 forks source link

auth and bookmarkable URLs? #26

Closed mwotton closed 4 years ago

mwotton commented 4 years ago

first up, this project looks very exciting and I'm looking forward to playing with it more. Just had a couple of questions:

  1. Is there a plan for a general authentication model?
  2. any way of recovering bookmarkable URLs somehow?
pkamenarsky commented 4 years ago

Glad to hear that!

  1. Authentication as in basic HTTP auth, or something else?
  2. Yes, I've just implemented a prototype JS FFI implementation and a routing example, see here.
seagreen commented 4 years ago

I think I understand the JS FFI and hash based routing example now.

For my use case however I'd like to get concur-replica to pretend to be a traditional server app, with bookmarkable URLs same as @mwotton. @pkamenarsky interested in helping me plan that out? I haven't done anything like this before, but I can guess there would be a few considerations:

  1. The initial version can work without changing replica/concur-replica, by immediately doing an FFI call to find the URL on startup, and then updating the site once it returns. I'll also use the FFI to keep the URL updated on the client as the user moves around the site.

  2. It would probably be sweet to modify replica so that it can send an initial, fully rendered page for that correct URL to the client even if JS is disabled. Better for search engines, people using lynx etc.

  3. I'm guessing I'll also want to use the FFI to install a back/forward button listener, so that when those are hit I can send a new diff over to the client for the correct new page without them having to do a full reload.

Thoughts?

pkamenarsky commented 4 years ago

Yeah, definitely. I think it would be great to have some sort of general router for concur-replica, and the one in the examples might be a pretty good starting point.

The initial version can work without changing replica/concur-replica, by immediately doing an FFI call to find the URL on startup, and then updating the site once it returns. I'll also use the FFI to keep the URL updated on the client as the user moves around the site.

Yes - an initial call seems necessary.

I'll also use the FFI to keep the URL updated on the client as the user moves around the site.

If you use the example router there's no need to do that - the state would automatically be converted to a URL hash after each widget step and the browser bar updated.

It would probably be sweet to modify replica so that it can send an initial, fully rendered page for that correct URL to the client even if JS is disabled. Better for search engines, people using lynx etc.

There's actually support for rendering to HTML in replica - see https://github.com/pkamenarsky/replica/blob/master/src/Replica/VDOM/Render.hs. Also, I think this upstream branch implements server-side rendering and other nice things (like persistent sessions), I just haven't had the time yet to look it over and merge it back into master.

I'm guessing I'll also want to use the FFI to install a back/forward button listener, so that when those are hit I can send a new diff over to the client for the correct new page without them having to do a full reload.

The example router already does that - it listens to URL changes (which are triggered by the back/forward buttons) and rerenders the routed widget with the deserialised URL state. Maybe try it out and see if it works for you.

seagreen commented 4 years ago

Added a "website" example with an auto-updating URL and working back button, based off of @pkamenarsky's hash based routing example: https://github.com/pkamenarsky/concur-replica/blob/d282c20eeabcab4ef265f44622f784d8c50ab1f4/examples/Website/Main.hs

Also opened two issues to track adding initial page load based on URL, and server side rendering: