Dustan Kasten

I agree with the argument presented here that the first argument should be reserved for the eventData object and the second being optional arguments. It’s clean and provides an expected...

Is that reference necessary because you’re escaping out to the raw `blessed` API regularly? I suppose the consistency is in the browser you always have access to the global `document`....

Ah cool. So you can do something like ``` jsx import myExistingBlessedApp from './app'; class ReactBlessedApp extends React.Component { /* ... */ } render(, myExistingBlessedApp.children[1][2][3]); // no idea what that...

I’m guessing something between React and React DevTools versions and/or local or global react-devtools being installed (e.g https://github.com/Yomguithereal/react-blessed/blob/master/package.json#L55)

@dandrei the JSX transform transforms lowercased `JSXIdentifiers` to strings. So that becomes `React.createElement('box', props)`

Any reason to not make them full fledged components like: ``` jsx import {ContibLine} from 'react-blessed'; ``` Rather than the magic of the generic component string implementation?

On my phone right now so I'll respond fuller later, but the general I'm doing in react hardware (and taken from RN) is havethe component constructor take a making if...

The pattern (taken shamelessly from React Native) is to have your core React{Renderer}Component, a creator for it that has a bit of sugar for declaring the valid attributes for that...

I'm curious if you would consider the target consumers of this to be react devs of blessed devs trying out react? If itis React devs I would argue in favor...

Correct. Doing something like the following quick psuedo-code would be super nice, IMO ``` jsx ``` It definitely would both increase the size of this and slow down performance, but...