## understanding proxymity's render cycle
When proxymity watches a data point, all data along the path will be transformed into a getter and a setter. This allows side effects to happen when the data is via the `=` operator. When this happens, it triggers a event to be fired that will resolved on the next javascript event cycle similar to Node's process.nextTick(). This means that you are free to make as many changes to the data object without triggering a re-render of the view. This also ensures that when rendering begins, all other data changes by the client code has already concluded. 

The rendering process begins by distribution the emitted events to their listeners in order of when they were added to the queue and the input fields affected by these events are then made to match. This is also the time when any targeted {:___:}|{}| are ran as well. Any changes to the length of an array will always cause a rerender of the affected dom sections and then proceeding to updating the other parts

The final phase of the rendering process is to do any clean up related to events. An asyncend event is raised at this point always. Because the above phase can potentially alter the data again and cause a re-render, the code checks will if there are new data updates and if not, it will enter end of rendering procedures and resolve the "renderend" event.