dgmcguire / texas Goto Github PK

test

Currently a new view that is broadcasted out to other clients may unintentionally remove some client side state that we didn't intend. In the case of a chatroom, for example, a different user may be typing and have a view broadcasted out to them, which would overwrite their chat input.

I think this could be best handled with either better understanding and using virtual-doms api or by looking to contribute to virtual-dom as ultimately we would want to pass some sort of options to creating a changeset such that we could tell the changeset to not create any patches that would target "dirty" elements.

So I've been speaking with @zharinov on slack and he suggested that [react-lite] might be a suitable replacement for what texas currently uses which is [virtual-dom].

He also brought up the fact that we don't even necessarily need vDom to make this work and I agree so I thought I'd start a discussion here and see if anyone wanted to contribute.

Long term goals I see texas as having many optional ways to transport data that would express view transformations - here are a few options I think could work.

1. shelling out to node and creating vDom changesets on the backend. This would require keeping a cache of what the client DOM looks like in order to compare updates and create a changeset
   • pros: less data over the wire than full html / could be serialized into an efficient format like protobuf
   • cons: seems complex enough to have some weird edge cases, like what if the client is mid-editting a field and we send a changeset up that manipulates that field? The changeset likely would just replace it entirely, but would the client be okay with that?
2. porting ratchet to javascript and keeping duplicate implementations on the back and front-end
   • pros: again, less data over the wire and could probably also be serialized into a more efficient format - this would lbe much simpler to implement
   • cons: there would be significanlty more client operatiosn happening here...the client would render out the template - use vDom to compute a changeset and then apply the changeset. If you have very weak/slow clients this could impose seriously bottlenecks for them

thoughts? comments? concerns?

Dan, I'm digging the idea here, it reminds me of action cable, but the use of Virual Dom is pretty clever.

I'm wondering though, why generate so much javascript. It seems like the majority of the generated JS is just the same thing with some variables dropped in. It seems like it could easily be a one set of javascript that is included everywhere, which takes the same things that are being generated now as variables. In which case the JS that is generated for each 'form' would be minimal, perhaps it could even be just a list of forms/sockets dropped in the header as some JSON?

I'm probably way under-thinking this.

Thoughts?

So right now a Texas.BoilerplateWriter.meta/2 needs the "scope" which is the root element that will be targeted for updates and a list of targets that are forms. We shouldn't need to specify a form for texas to write some websocket bindings for us to push updates to the "scope"