[ScrollView] Consistent .measure API for ScrollView

[JohnyDays]

I would like to allow for any renderable view to be passed in as a component type used in a module, right now the only problem with this approach is that .measure is not present in ScrollView.

I would expect .measure on the ScrollView component to redirect itself to its container, since that is just an implementation detail of the ScrollView.

My current solution is to allow for a function: reachContainer(element: view) prop that gets called and returns the actual measurable container, for this specific case, which is obviously worse than just having a consistent api.

Is .measure just an implementation detail that I shouldn't be using, or is it the defacto api for getting layout details after rendering, if so i'd argue it should be consistent.

[JohnyDays]

This appears to be even more complicated than I realized, custom components also do not have a .measure API, nor do they have a standard way of reaching the native view, so as to grab their measures. Am I missing some way to do this? I inspected the element through the dev tools and I could not find how this would be done in a standard way, and I do not want people to have to implement a custom getNativeView interface just to use their components as children in mine.

[vjeux]

@JohnyDays you can add a ref to the element you render and call measure on this. https://facebook.github.io/react/docs/more-about-refs.html

[JohnyDays]

Actually the element does not have a .measure function, I am already using refs.
A snippet of the code I am using as a temporary solution:

layouts.push(new Promise((resolve, reject) => {

  if(!view.getNodeHandle){
    if(!view.getNativeView){
      throw new Error("Non-native views must implement getNativeView")
    }
    var handle = view.getNativeView().getNodeHandle()
  }
  else{
    var handle = view.getNodeHandle()
  }

  RCTUIManager.measure(handle, (x, y, width, height, pageX, pageY) => {resolve({key, value:{x, y, width, height, pageX, pageY}})})
}))

In the above code, the variable "view" contains an element obtained through a ref
Edit: I forgot to mention, I am using this workaround because "view" may not have a .measure function obviously(if it is a scroll view or a custom component), nor is it guaranteed to have .getNodeHandle (as is the case with custom components)

[JohnyDays]

@vjeux From your comment, am I correct in assuming any rendered component grabbed from a ref should have a .measure function? If so, maybe this should be reported as a bug, because none of my custom components do, and neither does the ScrollView native component (I am using ES6 classes, maybe this is related?)

[vjeux]

Your reading of my comment is correct but i was actually wrong. We need the equivalent of React.findDOMNode() for React Native

[JohnyDays]

So in order to implement this, I would assume you would save a unique integer representation of every rendered component, and then asynchronously grab it from some kind of manager in Obj-C, and serialize it through the bridge, correct? e.g

React.findComponent(int: handle, callback: callback)

Given the performance cost this kind of communication/serializing has, I have a few proposals, tell me if I should open a new issue for these.

I think there should be either a React.findComponents(array: ids, callback) or React.findComponents(...ids, callback), so we would only have to pay the cost once.

An even better option, albeit I don't know how easy this would be to implement in obj-c, would be one where no actual serializing of components occurs through the bridge, so as to not allocate unnecessary memory and waste cpu resources, my proposed solution would be the following:

React.callNativeMethodOnComponent(int: id, string: methodName, callback(result): callback)

and an equivalent to the above

React.callNativeMethodOnComponents(array: ids, string: methodName, callback(result): callback)

This would completely remove any costs of serializing components through the bridge, since we only really care about the result of one call to a component method in some cases. An example of this would be for layout purposes, where we only care about the result of .measure() (Whatever this method is called natively) and not about the rest of the component.

Thoughts? Also, what can I do to help?

[brentvatne]

ping @vjeux

[JohnyDays]

I should close this, since the latest version of react this has been implemented. Thanks @vjeux!

[jonslenkooyala]

@JohnyDays might you know, where's the commit(s) that address this? I'd love that feature (specifically, for custom components) :-)

[JohnyDays]

Not sure what the specific commit is, but It's in these release notes https://github.com/facebook/react-native/releases/tag/v0.4.3 (the new api is React.findNodeHandle(ref))