0.0.2 • Published 8 years ago

@jhoguet/react-debugger v0.0.2

Weekly downloads
-
License
MIT
Repository
github
Last release
8 years ago

react-debugger

:exclamation: Use with caution, this is still in the proof of concept phase and lacks adequate testing both in automated tests and in the wild.

Getting Started

npm install @jhoguet/react-debugger

Then in your webpack config, load this file first...

entry: [
    '@jhoguet/react-debugger',
    './src/index.js'
],

Intent

The intent of this debugger is to provide runtime support for getting access to the react components given a dom node. It is inspired by Angular 1.x's angular.element($0).scope().

Api

window.$r(domNode) will get you an instance of ReactElementDebugger which wraps a ReactElement.

ReactElementDebugger

.parents() will list the DisplayName of each parent that has one

.parent(displayName) will walk to the parent with that DisplayName

.parent() will walk to the parent react element

.instance() will get the react element instance for the current ReactElement, this is useful if you have any state of functions living directly on this of your ReactElement

.props() will get you the props for your ReactElement, depending on the ReactElement this may not be very useful so it is best used after calling .parent(someDisplayName) to get to a ReactElement that has relevant props sent to it.

.displayName will get you the displayName of the current ReactElement

._raw gets you the raw ReactElement and isn't intended to be used.

Assumptions / Constraints

  • The debugger should defer as much as possible to "debug time" so that "startup" and "run time" are minimally impacted.
  • This only works with React 0.15+, the way this works in < 0.15 is much more complex and wasn't worth porting in.
  • I have only explored a couple of ways of walking the react tree, I am sure there are others to consider. see getParent() if it is missing a parent you expected it to walk through.

Similar Projects

Next Steps / How to help

  • better build system so we can have separate files
  • automated tests in a browser (real dom)
  • improve the documentation (api)
  • make it possible for the consumer to specify the global they want (if any) instead of assuming $r