Yet another issue that comes up is that ultimately you end up wanting to persist data and or retrieve data. In server side code this is done synchronously. You query the db and wait for the return. In client side code, this is generally done via ajax. which is, as per the a, asynchronously.
This completely disrupts the flow of the app. Instead of a method calling for some data, receiving it, and then processing it, you have to create a method for processing the data, then pass that method into the call for the data ( to be used as the call back from the ajax call ). This is kind of topsy turvy and makes things more linear. Less circular. Instead of having method calls nested in other method calls walking down a chain then back up the chain and ultimately returning home to the original caller, I do a little of that but ultimately do off on a branch never to return.
I would very much like to find a way around that since it is completely counter to what I am used to, but more likely then not I will just have to create/find some patterns for understanding it and using it more efficiently.
See if I could bring it all home to the controller then I could have the controller be the only point of contact with the dom. However if there are end points all over hell then the will each have to have contact with the dom . Or perhaps I could have a “dom touching service” where I keep all my end point code. Hmmmm. again.
2 comments:
Your view, in your MVC-like approach, is your "dom touching service".
@spideyCT
Yes this makes sense. This is more of just a stream of consciousness. Thanks for wading through it and pointing that out.
Post a Comment