We Keep Coding

Migrate from context to Redux

I want to migrate a big application from React Context API to Redux. The thing is, since is such a big task, I want to do it slowly and meanwhile be able to work on other things of the app (without adding things to the context).
Is it a good idea to migrate piece by piece and have both Redux and Context in the same app until I migrated everything? Or is it best to freeze the code and migrate it separately, and then work on new things?
I know it might depend on more variables but I want to get a general idea...

Only you would know the specifics of your app, but in general I don't think there's an issue with doing it piece by piece as you describe (migrating only some slices of state to redux to begin with.) You may find it turns out to be less of a headache to just do it all in one go though, but technically there's no reason you couldn't do this.

Obviously depends on how well you code base is currently structured.
We are about to do the same - i think our approach will be to add more tests to the context side, add redux concurrently with as flat state as possible then do one big move, the addition of redux with context could cause race conditions and other unknowns. Really big and scary change when the day comes to make the change, but hoping that we will have enough tests in place to manage. Wish we started with redux in the first place.

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

Flux with dynamic reactjs page

I have a problem with flux implementation on my app.
Heres the scenario:
We're a site builder plataform, we have pages where we don't know what will be rendering. Its completely dynamic, varying from user to user.
We have a lot of different components that may ou may not be loaded on the page and each component can have multiple instances.
What we need:
We need a FLUX structure that allows us to load only what we need from store and avoid unnecessary payload.
I have tried using Redux but the problems were:
Firstly we couldn't load all reducers at once but after a few research I built an interface capable of loading reducers on demand. But then I couldn't solve the problem with multiple instances from a component because the store file needs all states pre-refferenced :/
So, here's the question: How can I architect my app to use flux with dynamic pages and multiple instances from a component? Thanks in advance.

I think what you are trying to do is called "lazy loading". So you will just load components and pieces of javascript when they are needed.
Here you can find more information about (you need to generate more bundles of code with webpack):
https://blog.risingstack.com/react-js-best-practices-for-2016/
I will need this in a project in few months, but right now in our MVP we just need to make things run :)

Well, after a few (a lot) more research and attempts I'll implement a solution using React + Flux.Dispatcher + Backbone as suggested here:
https://www.toptal.com/front-end/simple-data-flow-in-react-applications-using-flux-and-backbone
===========================
Hope anyone has used that tip above. Worked nice for simple screens, got shit and slowly with complex pages.
Best way is to implement simple flux architecture as described in:
https://scotch.io/tutorials/getting-to-know-flux-the-react-js-architecture
https://blog.risingstack.com/the-react-js-way-flux-architecture-with-immutable-js/
Connect your components with a store via decorator and go for it, works simple majestic.
Hope it's usefull for someone.

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.