We Keep Coding

Different ways to fetch values from web services in react redux?

Trying to find the best way to fetch values from web services in ReactJs, redux.
Found ways using useEffects, fetch, redux-thunk, redux-saga.
But which is best to be used..?

This is a bad bad question. Okay, I cannot even explain why it's bad. I'll start with this, you're talking about completely different things.
I guess you're asking about how to make network requests in react. Here's brief description of the things you're talking about and why they are used:
useEffect: It's a hook in react, with which you can run an effect(basically running a function) on every or if depending on a state, some renders.
fetch: It is a web API with which you can make ajax requests(network requests) which is based on promises. Previously, we had XHR for doing so which is event-based. It is still used because fetch doesn't allow tracking the download progress of the response download. 'Should I use fetch or XHR for making requests', now that'd be a good question.
redux-thunk && redux-saga: Now you'd wanna use this with redux. In redux, as you probably know, dispatching action is synchronous. So if you wanna do some asynchronous task and dispatch the action object after that, then look into redux-thunk or redux-saga.
So the question shouldn't be 'Which of these should you use for fetching things off the web', because they're not specifically used for that purpose.

There are many differnt ways to doing that.
Basically useEffect is a hook and can not fetch any data directly.
Then you must pay attention to your app and select one that meet the needs of you. So there is no any best. If your application ia in a larg scale, i suggest react-query, then redux saga(if api reault is needed in some places)

MVVM architectural pattern for a ReactJS application

I'm a semi-senior react and JavaScript developer, I've made several Universal react application.
Today our CTO told me: Do you use a software architectural pattern for your application?
I've no answer, He points to the Android team which use MVVM for their applications.
I'm searching greedy but not found a trend methodology or example for this situation. I've used Redux, Redux-Saga, React-Context and etc.
I don't know how to explain to our CTO or what is his answer?
Hence: Does a react app really need a software architectural pattern?

React itself is not particularly opinionated about software architecture. It is a library that facilitates the reusable component paradigm alongside guidelines for managing things like state and data sharing (props). At some point, Facebook described this as the V in MVC but have since moved away from that marketing to call it more abstractly A JavaScript library for building user interfaces.
Of course, the typical tooling associated with React apps does lend itself to something of an architecture when used together.
A couple of potential ways to think about it:
Simple React apps might be just "VVM" or "VC"
MVC is probably the better-known of the two in the development world. The key conceptual difference between a controller (C) and view-model (VM) could be boiled down into: a controller can have many diverse responsibilities, like listening for events and routing them in the right direction. It's the glue that facilitates the functionality of an entire application. A view-model, on the other hand, is simply responsible for gluing the current state of the data to the model.
So Facebook's original use of "V in MVC" could probably just as easily have been "V in MVVM" - the term controller makes more sense in backend development world.
A barebones React app, without Redux, that pulls data directly into components (e.g. fetch's in componentDidMount or leveraging GraphQL) with limited data wrangling of any kind could be called a simple "VVM" model.
View-Model (VM): Component-related code that manages simple state, passes data directly onto View, potentially passes data directly back from View
View (V): How the visuals look (JSX, CSS)
Add some complexity, and you could call it "MVVM"/"MVC"
If you toss in Redux, redux-saga, or even start doing crazy things with simple React component state, you're introducing model operations. There're at least two things this Model (M) can represent:
Actual business logic for your application
Storing and managing complex behavior in your client
Business logic is sometimes undesirable in practice: for example, if you have control over the server, it might be worth keeping all your business logic in one place (on the server) and just feed the UI what it needs to interact with the user. But if you have limited REST endpoints and need to do some wrangling (e.g. in your sagas, or within components), that'll be business logic.
Client behavior management is likely, especially in complex applications where you might be doing things like displaying different things to the user based on their session (e.g. they're an unregistered user vs. user vs. admin). You're probably doing this in any redux store interactions that are contained to use by only the client.
Disclaimer: discussing MVC, MVVM, etc. is likely to lead to many different opinions of exactly what they mean [1]. Above, I tried to draw parallels between common patterns I've seen and how they fit into MVC/MVVM, but there's so many different ways to approach it or more granular ways to think about it. I wouldn't get too hung up on putting a label on it as long as your system is easy to understand: modular, DRY, abstracted, etc. at levels that make sense for your use case and scale of development.
[1] Discussed in the some more length in answers and comments to this question

Vue 3 is MVVM:
Proxy Update
Model → ViewModel → View
Model ← ViewModel ← View
Update Event
And React:
setState Update
Model → ViewModel → View
Model ← ViewModel ← View
Update Event
The difference is only how the frameworks notify Model changes to the ViewModel.

A simple Web App does not require MVC, MVVM, does not require even React IMO.
Possible evolution of a simple ReactJS App that may see the need of MVVM/MVC/ if it tries to be PWA (Progressive Web App). In other words - if it tries to do some (application/domain) specific logic - offline and some other - online. This is natural point of thinking for mobile app development. Then, the information may be retrieved from the Local Storage or the IndexedDB (for the Web) or the Back-End/Rest/. Then, the separation of Model, Storage/Repository/Source Of INfo/ ViewModel/ or Controller/ and View will be natural and actually needed for all stuff to work correctly...

Is Redux.js a sufficient way to separate data from view in a React.js/Node.js hybrid application?

I am quite new to web programming. I've started developing a single-page web application using React.js with a Node server.
I've read the tutorial, played with boilerplates, and quickly I understood React would take care only of the view aspect. So I tried to put my data-processing functions with the export keyword in a JavaScript file so I could use them in my React components. But that way was pretty "dirty" and it didn't feel satisfying at all.
Then I looked for a way to effectively separate the model and the controller from the view, so that I could completely change the GUI with little effort, and thus allow the project to grow and multiple people to work on it at the same time.
I've came across this article explaining the Flux architecture, and I saw a major implementation to use with React.js was Redux.js. I was quite surprised that I didn't see it at first, and now I wonder how much frameworks one has to use when working with JavaScript and Web.
My question is simple : is Redux.js all I need to effectively separate data, treatments and GUI components ? Or did I miss something else ? Are there any other major architectures you would recommend ?
Many thanks,

Redux is generally used to contain all the data that your app needs. It acts like a store which can pass the required data to the components that actually needs the data. For example, if you need a particular data fetched from an ajax request to be distributed among two components, then redux is a perfect fit. Whether you need redux depends on how your app is structured. If you have an app with a large number of components and most of these require data from your server or api, I'd suggest you go with redux. Once you learn it, it's incredibly simple. And yes, redux is all you need to separate data from ui. To get a nicely formatted structure, put together all your ajax requests under a folder and export it so that you can call it from the ui component. And when you receive the data pass the payload to the redux store which will automatically pass it to all the components which are connected to that particular reducer. For details on how to connect react with redux, check out their documentation:
https://redux.js.org/basics/usage-with-react
Remember not to confuse the state mentioned in redux with the state in react. Redux state refers to the application state. Do check it out and if doesn't work for you, another alternative would be flux.

Best practice to structure service/factory in angularjs

I was studying angularJs last week and there's something I'm not sure about.
For example, in a project that has some CRUDs of Student, Teacher and Supplier. Is it a good practice split the services/factory for each models (student, teacher and supplier)? or Is it better use one generic service/factory for the same models, like "write once, and run in everywhere"?. I think the second option maybe works for big projects, because you can write less code, but I have no idea about the maintenance.
Obs: The service/factory reffered above has functions with $http to list, add, edit and delete a registry from database.
And Is there any detailed style guide with best pratices for AngularJs?
Thanks in advance!

If you can manage the API endpoints at the back-end side you can create your services based on $resource. All you need (at the front-end side) is to set the endpoint URL. By call of $resource predefined methods like get, save, delete and etc. (you can add your custom methods as well) the $resource will submit HTTP requests with particular HTTP methods (GET, PUT, POST, DELETE) to the defined API endpoint.

If you want to stick to angularJS I would advise you to check this angularjs style guide from Todd Motto, it's most likely best one online:
https://github.com/toddmotto/angularjs-styleguide
Really has best practices using component based architecture. You will improve your code drastically and even merging to Angular would be easier.

If React.js is the V, in the MVC, what are the other letters?

I'm learning React but I'm still unsure on how to grow it up into a full-fledged app.
For the M and the C, what frameworks are cool to use with it? What if I want to go functional? Should I just use jQuery?
What about Routes, Ajax and the other things that many frameworks offers us?

You can actually go simply for Flux and react-router
Flux is based on the usage of Stores, Actions, and Dispatcher (depending on the implementation of Flux you use).
The Stores will play the role of the Models in an MVC framework.
The Controller (C) part is trickier to explain in the context of Flux, but it would be probably some of your React components that could be considered controller, combined with the Stores.
React-router makes it easy to manage routing in your React apps.
My more general advice would be to not look for "cool" frameworks to make your apps, but ask yourself what is going to be the fastest to implement with, the easiest to maintain and test, and what stack is going to be the simplest to do the job. Sometimes, simpler is much better.

For the M part I think Play Framework has a very simple way to create models. Your controller implementation depends on how you want to do it but it would definitely be a mix of both front end javascript to transfer data from the view (if you plan on using ajax) and a back end component. Play would help you out with the backend part of the controller.