Skip to content

Instantly share code, notes, and snippets.

@Qard
Last active August 29, 2015 14:16
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save Qard/3b92dccd79ca89a57e51 to your computer and use it in GitHub Desktop.
Save Qard/3b92dccd79ca89a57e51 to your computer and use it in GitHub Desktop.
Framework-level tracing notes

Problems

  • Input events are difficult/impossible to hook into at framework level
    • Angular uses html data-binding without user-defined interactions, or sometimes ng-click attributes (but still bound to a private scope). This logic is all lost somewhere deep in the internals, completely inaccessible to outside code.
    • Ember uses an action filter in mustache (http://emberjs.com/guides/templates/actions/). Again, inaccessible internals...
    • React uses on* attributes in JSX. It's possible to intercept them via React.createElement(...), but associating the virtual DOM representation with the corresponding real DOM element is not possible without patching the DOM itself.
  • Scope inheritance in angular makes it impossible to know what controller a given thing in the scope is coming from without modifying the core itself. (https://docs.angularjs.org/guide/controller#scope-inheritance-example)
  • MV* approach between the different frameworks varies rather drastically.
    • Angular has controllers, but the model concept is obscured into data-bindings, $scope and services.
    • Ember has controllers, but the dispatching seems to actually happen in views. It seems entirely possible that one might build an app that doesn't actually use controllers and just does all the logic in views...
    • React works similar to backbone, with controller classes that include a render() method to build the view for that controller. Models are represented within the controller as the "state", but could be backed by anything. The common pattern, called Flux, is a store and dispatcher system. Different state managers would have to each be patched in their own way.
  • Significant difference in what a "render" is.
    • Angular and Ember mostly correspond to nested html elements that re-render, cascading downward, whenever a change occurs in the data binding.
    • React, on the other hand, may or may not actually do any rendering. It applies changes to a virtual DOM and then applies the minimum required changes to make the real DOM match. This approach, while generally fast, is extremely unpredictable for the perspective of a tracer.
  • Black-box mechanics that obscure the true functionality.
    • Angular has directives, which make elements dynamically replace themselves. This behaviour is impossible to watch for unless patching the DOM directly.
    • Angular and Ember both make use of many magical html attributes that change the behaviour of the application invisibly to the actual JavaScript.
    • React classes can include various functions, like componentDidMount, that may or may not run, depending on the environment the app is being run in.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment