search

APrioriInvestments / object_database

A distributed object model written on top of typed_python, with a reactive web framework.
Apache License 2.0
5 stars 1 forks source link

Retain session state across ODB bounces #24

Open braxtonmckee opened 5 years ago

braxtonmckee commented 5 years ago

Right now we store some session state (chosen tabs, opened treeviews for example) in Slots. If you bounce the browser, you lose this state. Similarly, if you navigate panes. We should be storing all of this in SessionState objects that are appropriately scoped (so that the same piece of UX in the hierarchy always ends up with the same identity) so that we don't lose this state.

darth-cheney commented 5 years ago

A couple of things about this:

  1. If there is some unique, persistent id for a given SessionState on the server side, we can store this in the browser's localStorage and, when a page loads/reloads, attempt to use that information to grab the initial state from the server. This is a common practice in frontend land.
  2. We should think about how we want to differentiate between single-client state (ie, things that matter for just one specific user) and "global" client state (ie where some change or event on the server side updates every client's view). We can and probably should make this a part of the WS lifecycle refactor by introducing "channels" to outbound websocket messages. One channel could be updates on the UI of specific users and another to broadcast to other users.
braxtonmckee commented 5 years ago
  1. yes, we can give a uuid to each session, no problem. Right now I have some brittle thing I put in that tries to figure out which session we were in based on the order in which we bounce, but obviously retaining it would be much much better.
  2. this is already taken care of, in the sense that we have a "SessionState" object, which acts like a 'Slot', and which can be used to store this, and then we have things in the ODB which are global. So the semantic model for this is already in place. I think the issue is that right now SessionState doesn't have a rich enough model to understand that if you have a tree view, you have scoped buttons, so how do you give a persistent name to each button so that when it goes away and then comes back it knows which session-state slot to look in?

On Fri, Jun 28, 2019 at 12:35 PM Eric Gade notifications@github.com wrote:

A couple of things about this:

  1. If there is some unique, persistent id for a given SessionState on the server side, we can store this in the browser's localStorage and, when a page loads/reloads, attempt to use that information to grab the initial state from the server. This is a common practice in frontend land.
  2. We should think about how we want to differentiate between single-client state (ie, things that matter for just one specific user) and "global" client state (ie where some change or event on the server side updates every client's view). We can and probably should make this a part of the WS lifecycle refactor by introducing "channels" to outbound websocket messages. One channel could be updates on the UI of specific users and another to broadcast to other users.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/APrioriInvestments/nativepython/issues/111?email_source=notifications&email_token=AB6OHBBQLDLUOZX6OVW7EQ3P4Y4UXA5CNFSM4H3CSHH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY2R7JI#issuecomment-506797989, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6OHBF2MBFVSCBZV6T6GBTP4Y4UXANCNFSM4H3CSHHQ .