We Keep Coding

Choose the way to make App.js between using the function or using the class

I want to make some native applications with react expo. But I can't choose the way to make App.js between using the function or using the class. My friend says that it is better to use the function in the react web, but he doesn't know about react-native. Can you please give me some advice?

tl;dr Use functional components.
If you plan on using React Hooks, you must use functional components.
Furthermore, if you are using Expo SKD v38, you will find that using functional components is a lot easier because the Expo team have rewritten all their documentation to use FC.
Finally, a personal preference: you should also use TypeScript. :)

Your friend is correct, for reactjs the current recommendation is to use functional components. For react native, a lot of packages are using the class based components so I do understand where you’re coming from with this question. My advice is to use the functional based approach in both react and react native, for consistency.
If you check the expo documentation you’ll see both approaches in their examples so it’s safe to say that going for the functional based components is a good decision.

Functional components are newer and the recommended way to go. But there shouldn't be a big difference, because the new React Hooks are the replacement for Higher Order Componnents. Only disadvantage are old resources wich used class components, but thats really rare.

When ReactJs is appropriate

From what I have been researching, ReactJS is the new craze in the world of front-end development. I can find few articles that are able to provide a bias free look on ReactJS. There is only praise for it, but should it be used everywhere? I know an html.erb file with javascript can accomplish what ReactJS can do. Everything has its place. Where does ReactJS and React Native fit in? Specifically when should they be used? I know JavaScript can handle a lot, but of those things it probably shouldn't handle, or there is a better solution.
I would greatly appreciate guidance on these questions.

React has many cool features and is one of the best libraries for using for building UI apps
it utilizes something called the virtual dom to enhance performance in applications
it has a really intuitive pattern with storing state in local components which can be passed down to children components as props.
it integrates well with state management frameworks like Redux (there is a helper package called react-redux which makes the integration seamless) but it also has it's own context API which can be used for wider ranging state
it recently introduced the concept of hooks. these replaced lifecycle methods which were popular in previous versions and are now a cool way to "hook" into components and utilise functionality whilst the component mounts and unmount
of course, like with everything, there are alternatives. you can just use plain old vanilla which has it's own benefits or you can choose a popular alternative such as Vue.js.
There is no hard and fast rule specifically when it should be used. the ball is in your court

Will hooks overthrown redux?

I've been searching for a while about React's hooks now, and one question became persistent in my head. Will hooks overthrown redux? This is a fairly old discussion so first a little bit of context :
State Management with React Hooks — No Redux or Context API
What do Hooks mean for popular APIs like Redux connect() and React Router?
redux-react-hook
A lot of people (React's team included) seens to think that redux and similars will just going to adapt to the new API, turning the HOC's approach obsolete, but my question is:
With custom hooks, use reducer, and a well thought logic why do I need Redux at all? I mean, isn't just more performatic to dispatch your actions to a single reducer? I've found a lot of material about it, but none of those seems to have a definitive answer (maybe because there aren't one?), so I would like to know what do you think about Redux's future?

It's really hard to say at this time. The redux team is actively updating the product to include some nice features. However, one of the creators of redux (https://github.com/acdlite) seems to be on a path to destroy his old applications in favour of new features in react.
That being said, Redux is a tested and known library that a lot of people are comfortable with. I do not believe it a bad idea to start a new project with redux Today, tomorrow, or in a year. Tech does not die overnight. if it serves a purpose it's going to live on.
However, I do think context and hooks are a great alternative to redux, but the community simply does not know how to use it yet.

Nope, definitely not.
I addressed this in my Reactathon 2019 talk on "The State of Redux".
Summarizing: hooks mostly offer ways to do the same kinds of things you could already do, like local component state and avoiding prop-drilling via context. If that's all you were using Redux for, then you probably didn't need Redux in the first place. But, hooks have their limitations, and there's lots of additional use cases for choosing Redux.
Also, note that we are currently working on designing a public useRedux()-type hooks API for React-Redux.

More than a year has passed since this question was posted.
I want to add that in my opinion Redux has lost some relevance...
2 players in my opinion have stolen a big share of Redux's position in the React market:
People have learned how to combine useReducer with useContext to
implement a much simpler solution and without third party
dependencies. With the advantage that the React team is behind it;
which means we will get constant improvements tightly integrated
with the React framework.
MobX has been growing it's user base. Mainly because it provides an observer pattern which requires much less boiler plate code than Redux. (This could be debated).
So even though Redux remains widely used for React projects I foresee this will be gradually reduced overtime... - no pun intended... well may be a little bit ;) -
Specially for green field development!

What are Refs in React or React-Native and what is the importance of using them

While going through react documentation I came across Refs. I want to know why Refs are used, what is purpose of using them. I haven't used them before in any previous projects. Some people suggest avoid using Refs, I don't know why.

There is a good explanation here: https://facebook.github.io/react/docs/refs-and-the-dom.html
There are a few good use cases for refs:
Managing focus, text selection, or media playback.
Triggering imperative animations.
Integrating with third-party DOM libraries.
Avoid using refs for anything that can be done declaratively.

React cross-component states

I read articles criticizing React for setState being weird when instead the people criticizing it did not understand it properly.
I really like React modularity, and the more I learn it the more I find it intuitive.
Nevertheless, I ran into multiple situations in which I would have liked the states to be cross-component. What I mean is, changing a state in a component could affect another component. It is my understanding that there is no React built in solution to this problem. Of course there are ways around it but there is no fixed protocol.
My question is, why is that? what is the advantage of not providing a simple way to handle such a common scenario? Or if there is and I don't know about it, please enlighten me!

There are at least 4 out-of-the-box ways to share state between closely related (and unrelated) components: props, callbacks, refs, the ctx variable.
I simply think it's built to be as small as possible with the complete intention that if you need an app state manager for a complex project (where unrelated components need to communicate) that you will include one, and they will not force you into any one approach.
If you did want something with more substantial scaffolding to start a project, which many people do, you could refer to react-boilerplate or similar.
But having React itself limited to the minimal, I have the freedom to choose (or not) the best tool for each project without having to override one-size-fits-all defaults.