-
Notifications
You must be signed in to change notification settings - Fork 24.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bridge] Allow RCTViewManager to define view instance methods exposed to JS #179
Comments
Seems like it can be useful to extend RCTTextField for tooltip. :) |
This is a neat idea cc @tadeuzagallo |
That's interesting, and I've talked about something similar with @nicklockwood before, but the problem that always comes up is that in most of the use cases the method would have to be sync... |
Yeah, we do this already for stuff like RCTWebView, and it's a pain doing the same lookup code every time. Makes sense to have a simple macro to wrap that logic. |
It should probaby wrap the UIBlock logic as well for view methods, to avoid accidents. Then there would be no need to dispatch to main queue inside the method. |
Who wants to take lead on this one? @ide? 😄 |
Ping on this? |
+1 |
how would one obtain the same behavior now? |
You need to pass the reactTag of the component to the native layer and look it up in a dictionary that maps tags -> views. Some of the native components in this repo do this like the focus/blurring of text inputs. |
I get |
You probably need to import the header that defines the category that adds uiManager -- RCTUIManager.h I think. |
spot on |
Hi there! This issue is being closed because it has been inactive for a while. But don't worry, it will live on with ProductPains! Check out its new home: https://productpains.com/post/react-native/bridge-allow-rctviewmanager-to-define-view-instance-methods-exposed-to-js ProductPains helps the community prioritize the most important issues thanks to its voting feature. Also, if this issue is a bug, please consider sending a PR with a fix. We rely on the community to provide |
(Related to the discussion in #114)
The gist of what I want to do is to call methods on view instances where setting a prop doesn't make sense. A common example of this is focusing/blurring a text field. The current API (
this.refs.textInput.focus()
) is right on, but the implementation is a bit roundabout going through a static method on the UIManager to look up the view and set the first responder state. It would be much better for module implementors to be able to expose methods on the view instances directly and not have to think about the node handle -> view lookup.A rough sketch of what this could look like is:
I haven't thought too much about how arguments and return values should be handled though arguments in particular seem important to support.
The text was updated successfully, but these errors were encountered: