Is there a way to enforce order of execution of props on a Native Component? - react-native

I came across a bug in a React Native app that makes use of a native view component, and tracked it down to the order of execution of the property settings methods (e.g. #ReactProp methods on Android).
I found that I had to put the prop method that needed setting first as the last prop in the component's JSX declaration, which is a little counter-intuitive.
Is there a way to enforce this order?

Although this doesn't specifically answer the question, one way around this, when specific props are dependent on each other like this, is to bundle them in an object, which on Android would be passed to the native method via a ReadableMap. That way all the dependent data is in one place and can be handled in the correct order.

Related

Algolia for React Native: refine() method

I wish to use Algolia to setup InstantSearch in my React Native project. I am using this tutorial to learn the basics.
It appears in their RefinementList and InfiniteHits components there is a parameter: refine. This parameter seems to play a key role in the functionality of this tutorial's app.
Where can I get an example of how this refine() method would look like?
Please help me with some resources. An explanation of this refine() method would also help.
Thanks!
I think there's a typo in the documentation at the time of this writing (for which I opened a pull request), and the name of the actual prop is refineNext.
The documented InfiniteHits example from the React Native guide uses a connector, which is a lower-level abstraction allowing users to fully control the UI. This is what allows you to use React Native code for the UI while having access to the InfiniteHits data and logic. You can read more about the connectInfiniteHits connector in the documentation.
The provided refineNext function lets you load more results. It doesn't take any arguments, all you need to do is call it whenever you want to load more results from Algolia. In the example, it's being used in the onEndReached callback of React Native's FlatList component, whenever the hasMore provided prop is true. This allows loading more results once when the scroll position gets within onEndReachedThreshold of the rendered content.

getDerivedStateFromProps() vs componentDidUpdate()

I am using componentWillReceiveProps in many places in my application. Now, I have to replace them with either getDerivedStateFromProps() or componentDidUpdate(). First I thought of using getDerivedStateFromProps as it s alternative of componentWillReceiveProps as suggested react-native docs. But some people are highly recommending not to use this method, Instead suggesting to use componentDidUpdate. But for my requirement all new props must be set with the state before render. getDerivedStateFromProps is the best place to do so.
Hence, which one to use between getDerivedStateFromProps and componentDidUpdate?
From the React docs
https://reactjs.org/docs/react-component.html#static-getderivedstatefromprops
getDerivedStateFromProps is invoked right before calling the render method, both on the initial mount and on subsequent updates. It should return an object to update the state, or null to update nothing.
Deriving state leads to verbose code and makes your components
difficult to think about.
Make sure you’re familiar with simpler alternatives:
If you need to perform a side effect (for example, data fetching or an animation) in response to a change in props, use componentDidUpdate lifecycle instead.
If you want to re-compute some data only when a prop changes, use a memoization helper instead.
If you want to “reset” some state when a prop changes, consider either making a component fully controlled or fully uncontrolled with a key instead.

Can I use global variables in React Native to store user information?

I have an application that has hundreds of screens. I usually pass the variables from parent to child between the components with props. I find it very uncomfortable to pass the array with the user information hundreds of times.
I am testing the global variables of react native. Does it have any danger to use a global variable to save user information and modify it within the components?
I have searched for documentation and nothing is said. I know it's not correct in react, but it works wonders for me.
Any recommendation?
If that global variable is a constant or it's value doesn't effect rendering of components then you are good to use it as global variable or async storage.
But if it's value is changing and affecting the rendering of component then I highly recommend you to store that value as state and to make it global you can either use
1) Context api (https://reactjs.org/docs/context.html)
2) Or Redux

Differences between this.props.navigation.dispatch vs this.props.navigation.navigate?

I see a lot of folks in the react-navigation issues section using this.props.navigation.dispatch to programmatically navigate. Is there any specific reason or use case to use that over this.props.navigation.navigate?
It seems like you can pass more options to the dispatch function? Is there anything else? Can you use dispatch without explicitly tying react-navigation into your apps redux store? Right now I have an app that has redux, but I dont explicitly configure my redux setup to know about react-navigation (and would prefer to keep it that way if I can).
From github 👇🏻:
This is the code of navigate function which reuses navigation.dispatch.. And remember:
Code Don't Lie
Then, navigation.navigate(...args) is an alias of navigation.dispatch(NavigationActions.navigate(...args))
From the React Navigation docs The Navigation Prop chapter (https://reactnavigation.org/docs/navigators/navigation-prop#dispatch-Send-an-action-to-the-router):
...The other navigation functions use dispatch behind the scenes...
Also parameters for NavigationActions.navigate and this.props.navigation.navigate are the same. There should be no difference which one you use. In my opinion, this.props.navigation.navigate is shorter and more readable.

How do you push a new route onto a Navigator in react native from external code?

It's easy to get a reference to navigator in the renderScene function, so calling navigator.push(newRoute) is simple when responding to an event that happens from within the JSX tree.
In my case, though, I want to call navigator.push(newRoute) from an external event. My app signs the user in with Google and fires an event when the sign-in is complete, and I want to navigate to a new route in that case.
How can I get a reference to the navigator? Is there any way to get it besides as a parameter to renderScene?
You can get the navigator through refs property: https://facebook.github.io/react/docs/more-about-refs.html. It's part of react (not specific to react native). It's not obvious from the react-native docs that there is a number of 'react' features that can be used in react-native, so i'd really advise to take a close look at react in general.
Note however, there is a good reason Facebook does not mention refs explicitly and loudly. Refs is really not a "go-to" way of accessing component. Your case might be of course different, but it's likely that the Google sign-up is not in-fact "external". It might actually be part of one of the components in the hierarchy tree above the navigator (in which case you can pass the state change down the tree).
Quoting from the summary of the "More about refs" document above:
If you have not programmed several apps with React, your first
inclination is usually going to be to try to use refs to "make things
happen" in your app. If this is the case, take a moment and think more
critically about where state should be owned in the component
hierarchy. Often, it becomes clear that the proper place to "own" that
state is at a higher level in the hierarchy. Placing the state there
often eliminates any desire to use refs to "make things happen" –
instead, the data flow will usually accomplish your goal.
Again - your case might be different and using refs might be perfectly justified, but if you are tempted (for example) to separate out all the Google-related stuff to separate object and if that makes the sign-up "external" - think twice. React really encourages putting all things related to a "component" logic in one place (the component) - even if that includes various technologies and external APIs.