Skip to content
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

Closed
ide opened this issue Mar 22, 2015 · 14 comments
Closed
Assignees
Labels
Resolution: Locked This issue was locked by the bot.

Comments

@ide
Copy link
Contributor

ide commented Mar 22, 2015

(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:

// in RCTTextFieldManager.m
RCT_CUSTOM_VIEW_METHOD(focus, RCTTextField)
{
  // "view" is defined w/static type RCTTextField
  dispatch_async(dispatch_get_main_queue(), ^{
    [view becomeFirstResponder];
  });
}

I haven't thought too much about how arguments and return values should be handled though arguments in particular seem important to support.

@chirag04
Copy link
Contributor

Seems like it can be useful to extend RCTTextField for tooltip. :)

@brentvatne
Copy link
Collaborator

This is a neat idea cc @tadeuzagallo

@brentvatne brentvatne changed the title Allow RCTViewManager to define view instance methods exposed to JS [Bridge] Allow RCTViewManager to define view instance methods exposed to JS May 31, 2015
@tadeuzagallo
Copy link
Contributor

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...

@nicklockwood
Copy link
Contributor

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.

@nicklockwood
Copy link
Contributor

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.

@brentvatne
Copy link
Collaborator

Who wants to take lead on this one? @ide? 😄

@sahrens
Copy link
Contributor

sahrens commented Jun 12, 2015

Ping on this?

@olivierlesnicki
Copy link

+1

@olivierlesnicki
Copy link

how would one obtain the same behavior now?

@ide
Copy link
Contributor Author

ide commented Aug 22, 2015

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.

@olivierlesnicki
Copy link

I get property uiManager not found on object of type RCTBridge*

@ide
Copy link
Contributor Author

ide commented Aug 22, 2015

You probably need to import the header that defines the category that adds uiManager -- RCTUIManager.h I think.

@olivierlesnicki
Copy link

spot on

@mkonicek
Copy link
Contributor

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.
It is easy to use - just login with GitHub.

Also, if this issue is a bug, please consider sending a PR with a fix. We rely on the community to provide
bugfixes as the core team is focused on performance.

@facebook facebook locked as resolved and limited conversation to collaborators Jul 23, 2018
@react-native-bot react-native-bot added the Resolution: Locked This issue was locked by the bot. label Jul 23, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Resolution: Locked This issue was locked by the bot.
Projects
None yet
Development

No branches or pull requests

9 participants