All:
I am pretty new to React from AngularJS. In AngularJS, there is service dependency inject which can provide a service instance to do data fetching, processing, etc., other than UI operation. I wonder how to do this(or implement that injection) in React component?
Thanks
I prefer to create a service in another file that exposes the 'public' functions through module.exports.
e.g.
module.exports = {
foo: function(){ return bar; }
}
which is then referenced by Components using
import myService from './routetoservice/myService'
An Extension to Michael Dunn's Answer
This is the actual answer ,
Service pattern is not limited to any programming language or
library.
We can implement this concept in any language , Even we can
implement this in react
A tiny service can be created on server OR in ui browser in Javascript that serves some logical purpose
It gives us benefits of code availability, code management , code isolation of particular logic
Its a very native way for code availability, code management , code isolation of particular logic
If we compare redux/flux vs services ,redux/flux also serve these purpose's
Currently i am using redux and its actions , and also created my tiny services on ui when required.
No need to use OTHER NPM MODULES FOR CREATING SERVICES , Just Michael Dunn's solution is enough
In reactjs we use the flux pattern to provide data handling. Here is an example of that with reflux. React with Flux: is this the dogmatic pattern or are there equal/better options?.
React seems philosophically opposed to services in the Angular sense, apparently preferring tight coupling of UI and logic.
But I have found a react-services module, which seems to offer what you are after:
• separate your component and application state by introducing a service layer that takes care of propagating changes through your application
• manage component dependencies in an explicit, testable way
• there's no events and no lifecycle management - everything is done automatically for you
• it's tiny and easy to understand - the core is less than 100 lines of code
https://medium.com/#alshdavid/react-state-and-services-edb95be48851
Here's an article showing how to do it with nothing but React Context and rxjs
Related
TLDR; How to use a single context between react micro frontends?
The application is divided into multiple Microfrontends or react apps. Each of these is running on a different port. A container is hosting other Micrfrontends. Each one is a separate react app and it is a runtime integration. (I have used martinfowler example to implement micro frontend)
Currently passing some data via URL and browser storage (localStorage/cookies) to other Microfrontends.
I need to pass the data across these react apps (MFEs) using React Context.
I have defined ReactContext Provider in Container (ReactApp1) and stored value (say color=black). To access this color inside the lower level Microfrontend (ReactApp2) we need the context to be available from any micro frontend. How to make it available?
(NOTE: I don't want to use localStorage or cookies for global data sharing)
<Container>
<LowerLevelMFE1/>
<LowerLevelMFE2/>
...
</Container>
Webpack 5's Module Federation & ModuleFederationPlugin is the best way I've found to achieve this architectural pattern.
In essence you create a "host" application that wraps the React.context around a "remote" component. This "remote" is actually another component in a standalone application that is being exposed as a remote through its webpack config file. In this 2nd application you would consume the context as normal using React.useContext.
You can find a full example of this setup here on github.
A few things to note:
Both applications will need to consume this Context's source code so moving it into its own package is preferred.
Your Context consuming application will still need, what I call in MFEs, "developer scaffolding". In this case that would be a simple component that wraps your <ContextConsumer /> in a <ContextProvider /> that you are importing from your shared Context package I mentioned in 1.
Remember this app with scaffolding is only exposing the <ContextConsumer /> which you need to make sure to specify in the webpack config.
I think sharing context between Micro-frontends is an anti-pattern and should be avoided if you can. If you use context to share data, you will automatically couple the MFes that depend on the context, eliminating the benefits of independent deployments by introducing coordination and a dependency.
My advice is that each micro-frontend loads the data they need and if there is communication need it, you need an api or a contract to handle this communication.
I think if you need that type of comunication between the mfe's then they are splited wrong.
As Ruben says, is an anti pattern.
Summary
I am writing a React-Redux application, and would like to create a service that can be accessed across multiple components, with the following characteristics:
Singleton (just gets instantiated once across the entire
application)
Injectable (can be injected into, and used by, multiple components across the application)
Redux Connected (can access the entire Redux state tree & received updates to state changes)
Code Example
The type of solution I have in mind, would allow me to inject a service int a React Component, and use in the following way:
{ featureAvailabilityService.isAvailable('myFeature') && (<MyFeature />) }
Ideas
I have read about High Order Components, Hooks, and the Context API. There are also some interesting libraries, such as Unstated, and Redux-Logic. I feel like the best answer probably lies somewhere between these, but could use some guidance to put me on the right track.
Use Case
In this instance, I would like to create a reusable service, which has methods to determine the availability of certain features. This involves relatively complex logic based on System, Tenant, and User configuration and state. It also requires the service to have access to state from several different parts of the application. It will also be reused broadly across the application.
Why Yet Another React Service Question?
I realize there are already a lot of similar questions to this, usually from people with an Angular background, looking for the React equivalent to an Angular Service. However, I have not yet found an answer that provides for the above three criteria... or at least not one that I understood.
Thanks for any input.
Learning a little React currently. I'm finding myself confused about some of the utility here. One sticking point that seems to (for me, at least) undermine it's value is that If I want to sync my UI to data residing on the server (which can and will change), I need to manually poll the server? Aside from component-based architecture, I'm not sure how this is getting me further than well structured and logically implemented AJAX. Even in the React docs, they're using JQuery in this regard. https://facebook.github.io/react/docs/tutorial.html#updating-state
I'm sure I'm missing the forest for the trees or whatever.
Thanks!
React is (citing their page)
a javascript library for building user interfaces
The main focus is to build a view layer for your application. This means you have full freedom in choosing what to use to fetch your data. For simple uses it can be jQuery or fetch.
It's generally recommended to not fetch data directly in your components and use one of Flux pattern implementations, e.g. Redux.
If your application has to be constantly powered by new data from server you can think about using something like RethinkDB on your backend and connect it to Flux store on your frontend.
I have a service loaded into a component as a provider. This service may return data using Http or it may not, the component should not care. However, it seems that the component itself must include HTTP_PROVIDERS if the loaded service uses Http. This breaks separation of concerns. What am I misunderstanding?
This breaks separation of concerns. What am I misunderstanding?
In order to support instantiating multiple instances of a service (i.e., so all services don't have to be singletons), an Angular app needs a way to specify multiple injectors (not just one). These injectors need to be created and configured in some kind of hierarchy. The component/directive tree, since it is a tree, already has a hierarchy. So Angular uses the (existing) component tree to configure dependency injection. I like to think of it as a sparser "injector tree" that overlays the component tree.
I think it would be more work to define a separate hierarchy for services – we, as developers, would probably have to define and configure another injector tree of some sort.
So instead of thinking of it as "components need to know the dependencies of services" (which, when stated that way, it does sound like we're breaking separation of concerns), I like to think of it more like the following: "when I write an Angular app, I have to configure my providers/dependencies on the injector tree"... and since the injector tree overlays the component tree, I use components to configure it.
But this is not ideal, since if you want to reuse components in a different app, you might need to change the providers arrays (i.e., you may need to reconfigure the injector tree).
In fact, it's better to specify the HTTP_PROVIDERS when bootstrapping your application:
bootstrap(AppComponent, [ HTTP_PROVIDERS ]);
But I agree with you that there are some impacts on having configuration of providers only on components.
The previous configuration will work because of hierarchical injectors.
See this question for more details about hierarchical injectors:
What's the best way to inject one service into another in angular 2 (Beta)?
I know what angular.js is and I even had a question about it #Why use AngularJs in frontend if Laravel is already used as backend?.
but recently I started to read about React.js and from its site (its the V in the MVC) which is exactly what am after "handling the view and nothing else".
for me, I think Angular.js as an MVC framework was made to be used with something that is built with JavaScript from start to end like Node.js
and it seems like an overkill when used with something like Larval, where I simply need something to handle the frontend and nothing else + Angular have 2 main drawbacks
with the latest news about a new version that won't have back compatibility with the current version makes me even feared to start learning it just to find that more or less every project out there is using the old version which mostly is true.
angular renders the whole dom if anything got changed which again is an issue for big projects.
so based on the above, plz note that I want to learn/use JS solely to enhance the user experience not to build another Gmail or Facebook and so my question is,
could React.js be used with Laravel to handle the view and do everything Angular was going to give, or I have to use Angular liked or not?
could React.js be used with Laravel to handle the view and do everything Angular was going to give?
No
React is just for views. React components are stateful components with some really clever rendering stuff happening behind the scenes. To build a fully functional front-end app, you'd need to tie in some other code (or write it yourself).
React works well with Facebook's Flux architecture. I would suggest looking into that to learn how to manage the state of your react components.
What's key to understand here is that Flux and React are not parts of a large front-end framework. React is a library and Flux (as provided by Facebook) only provides a Dispatcher. The rest is up to you to implement. There are some pre-existing implementations you can look at if you need some help to get started.
What I like about flux is that it allows me implement things the way that fits my application best. React takes care of the heavy DOM lifting and is very easy to learn. Compared to Angular, I don't have to learn arbitrary conventions and gigantic APIs of a huge framework.