I am doing a React app and I want to do my in memory data models with es6 modules and EventEmitter. Wondering if it is recommended to use a singleton.
Also I heard that this event emitter is the one to use.
The answer is yes! Models in a module based front end should be singletons!
Otherwise their data is not persistent across the various imports!
Related
So I use angular services declared as public to keep the state of what the service controls between differents views in the service's variables.
Example:
View 1 to scan and connect to bluetooth devices.
View 2 (view 1 already destroyed): Show device information of bluetooth device connected(in view 1).
Im just starting with NextJS and I don't see any way in the documentation to import components like public service in angular.
I do have been researching and only things similar are ContextAPI and redux, to save maybe the components variables states like that. But it isn't quite like Angular services. Is there something like angular public services or I have to use manually contextapi/redux to save the information between components
Angular and React structures are quite different things, while angular uses MVC but react uses view-model so there isn't any original service-like concept in react like angular, but you can do it in your way. you can define some classes to handle things you want like angular services or even use state managing to handle this ...
hope this can give you sight.
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)?
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
I'm currently working on a complex single page web app. It's something like a charting program: you can select or add objects on a white page. There's many types of objects. If you select some of type A objects, then it will add/remove B/C/D objects based on a complex logic. I'm currently using Backbone.Model for these objects. And Backbone.View for displaying. It's a pretty standard MVC structure, with models for objects data, controllers for managing models and views, and views for displaying. It's all using DOM elements. The views are added, removed or updated (with CSS) based on model data.
It works great and now I'm trying to add server side to save and load all data to/from the server. I planned to write a REST API server with restify for all the models.
Then I find meteor.js, the 'realtime', 'reactivity' and 'database everywhere' features intrigue me. So it will greatly simplify my app if I can save and load my models directly and let meteor to do the sync. And the real time feature can be a great plus for my future features, such as adding realtime collaboration.
But it seems meteor has a very different idea from Backbone on how a web app is structured. How can I combine meteor with my current Backbone code? Do you have any great suggestions?
Thanks.
Uh, don't. Do meteor all the way, or do backbone, but meteor is pretty much a combined full-stack solution not really intended for use with something like backbone. Meteor already provides deeply-integrated components that address all the areas that backbone addresses (data sync, DOM updates, etc).
I'm wondering how to integrate backbone js (http://backbonejs.org/) with persistence js(https://github.com/zefhemel/persistencejs).
the problem is backbone models need to be updated to use the new lib models instead of the restful one.
I tried to use:
backbone.nopersistence: but all data is saved in memory only,
backbone.localStorage: but I need to save data in websql not just localStorage
Try this adapter: https://github.com/MarrLiss/backbone-websql. It's not persistencejs, but it saves to websql at least.
Edit: you can find a better solution here: https://github.com/retrofuturistic/backbone-scaffold. It overrides the default Backbone.js sync API and provides DAO objects to access WebSQL through persistencejs.
After more investigation I found that the best solution is to use persistence models instead of backbone models because backbone models are designed to use restful apis.