What does "same-ish state" mean?

[callumlocke]

The blogpost and [homepage] both use the phrase "same-ish state".

Can you clarify why "ish"?

[taylorhughes]

I should write this up somewhere, but here's as good as anywhere for now.

What skit does:

skit pageload on the server

1. grab a JS context, set the global environment in it, eg. current URL and cookies
2. instantiate the controller
3. call preload on the controller
4. note the properties that were added to the controller during preload (eg. this.foo = {bar: 'baz'})
5. call load, title, body on the controller
6. serialize added properties to the bootstrapping page as JSON
7. end response

pageload in the client

1. global environment set by the browser
2. load the controller class (via client-side JS modules written to the page)
3. instantiate the controller object again
4. set the properties that were added in preload from JSON on the new client-side object
5. call load and ready

ish

So the controller is re-instantiated in the client, and the skit-based modules there work the same as they do on the client (navigation/cookies/net), and as long as anything set on this (the controller) in preload is JSON serializable, everything will just work and be there in the client environment automatically.

But here's the caveat. "ish" means that eg. if you set something during preload that is instantiated from a custom class, skit won't do the right thing yet — because it doesn't know how to call the constructor to create that object. Skit just writes JSON and reads JSON back onto the controller for now.

I think I will need to add some kind of "serializable" interface to support serializing/deserializing custom classes, but I haven't done that yet.

(Another "ish" is that if you set other state in your various JS modules, that state will not be maintained — just the controller object gets the magic state transfer mechanism, for now. This is something else I'm thinking about improving.)